Сейчас ведётся много споров и дискуссий о будущем C++.
Не только на Reddit и одном оранжевом веб-сайте, но и совершенно точно на официальных заседаниях комитета по стандарту C++.
Похоже, мы находимся в следующей ситуации:
Evolution Working Group (EWG) языка C++ как раз достигла консенсуса по внедрению Читать полностью »
Тем не менее, иногда до нас доносятся слухи.
Написанные в древних томах, подслушанные в тайных покоях, начертанные на стенах разрушенных храмов, упоминаемые в загадочных текстах, они рисуют чёткую картину:
Компиляторы плохо справляются с генерацией кода для интерпретаторов, и можно превзойти их, написав интерпретатор на языке ассемблера.
На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять. Аплодисментов в зале слышно не было.
Я думаю, мы не осознавали полностью те последствия, которое повлечет за собой данное решение, и я не верю, что оно в принципе может положительно сказаться на развитии языка.
На днях в Праге прошла встреча международного комитета по стандартизации C++. И-и-и-и…
C++20 готов! Осталось поставить штампик от ISO, но это чисто формальный шаг, с которым не должно быть проблем.
Поздравляю всех с этим замечательным событием! Concepts, Coroutines, Modules, Ranges, std::format, constexpr new и constexpr алгоритмы+vector+string, datetime, jthread, span, bit_cast и многие другие мелкие и большие нововведения.
Что успели добавить и поправить в последний момент, что предложили разломать и что все хотят видеть в C++23 — обо всём этом под катом.
Читать полностью »
Перевод публикации Тита Винтерса в рабочей группе 21 (WG21) — комитета по стандартизации языка C++. Автор обсуждает важный вопрос: поддержку обратной бинарной совместимости или ABI (application binary interface).
В течение последних лет в WG21 я активно пропагандировал то, что прогресс важнее обратной совместимости. Но я сам перестаю в это верить, особенно в отношении поддержания бинарной совместимости (ABI). Читать полностью »
Большинство компиляторов C позволяют получить доступ к массиву extern с неопределёнными границами, например:
extern int external_array[];
int
array_get (long int index)
{
return external_array[index];
}Определение external_array может находиться в другой единице трансляции и выглядеть так:
int external_array[3] = { 1, 2, 3 };Вопрос в том, что произойдет, если это отдельное определение изменится так:
int external_array[4] = { 1, 2, 3, 4 };Или так:
int external_array[2] = { 1, 2 };Не так давно у меня произошёл очередной разговор с коллегой на извечную тему: "по ссылке, или по значению". В результате возникла данная статья. В ней я хочу изложить результаты моего исследования по этой и смежным темам. Далее будут рассмотрены:
Осторожно! Статья содержит большое количество кода на C++ и ассемблере (с комментариями), а также множество таблиц с оценками производительности.
Вдохновение на написание данной статьи было получено после прочтения похожей публикации для архитектуры x86 [1].
Данный материал поможет тем, кто хочет понять, как устроены программы изнутри, что происходит до входа в main и для чего всё это делается. Также я покажу как можно использовать некоторые особенности библиотеки glibc. И в конце, как и в оригинальной статье [1] будет визуально представлен пройденный путь. В большинстве своём статья представляет собой разбор библиотеки glibc.
Итак, начнём наш поход. Будем использовать Linux x86-64, а в качестве инструмента отладки — lldb. Также иногда будем дизассемблировать программу при помощи objdump.
Исходным текстом будет обычный Hello, world (hello.cpp):
#include <iostream>
int main()
{
std::cout << "Hello, world!" << std::endl;
}