LINUX.ORG.RU

Утверждён стандарт C++26

 ,


3

7

Комитет ISO по стандартизации языка C++ утвердил финальный вариант спецификации, образующей международный стандарт «C++26». Представленные в спецификации возможности частично уже поддерживаются в компиляторах GCC (gnu.org), Clang и Microsoft Visual C++. Поддерживающие C++26 стандартные библиотеки реализованы в рамках проекта Boost.

В следующие два месяца утверждённая спецификация будет находиться на стадии подготовки документа к публикации, на которой будет проведена работа по редакторской правке орфографических ошибок и опечаток. В начале ноября результирующий вариант документа будет направлен в ISO для публикации под формальным именем ISO/IEC 14882:2026.

Основные особенности C++26:

  • Реализованы элементы контрактного программирования (Contracts), позволяющие определять формальные спецификации интерфейсов при помощи трёх новых операторов: pre (предусловие), post (постусловие) и contract_assert (проверка утверждения). Оператор pre определяет предварительные условия, которые должны быть выполнены перед вызовом (проверка входных данных); post – условия, которые должны соблюдаться после выполнения (требования к выходным данным); contract_assert – условия возникновения исключений. Возможность появится в GCC 16.
       int f(const int x)
          pre (x != 1) // требования ко входным данным
          post (r : r == x && r != 2) // требования к результату; r - значение с результатом
       {
          contract_assert (x != 3);
          return x;
       }
  • Добавлена поддержка рефлексии (Reflection), позволяющей отслеживать и модифицировать элементы программы на стадии компиляции. Добавлены новые операторы «^^ (open-std.org)» для получения метаинформации о грамматической конструкции и «[:…:]» для выполнения обратного преобразования. Для преобразования и обработки полученной в ходе инспектирования информации предложена библиотека std::meta и доступны такие возможности, как вычисления с константами. Поддержка рефлексии будет добавлена в GCC 16.
       constexpr int i = 42, j = 42;
    
       constexpr std::meta::info r = ^^i, s = ^^i;
       static_assert(r == r && r == s);
    
       static_assert(^^i != ^^j);  // 'i' и 'j' имеют различные значения.
       static_assert(constant_of(^^i) == constant_of(^^j));    // 'i' и 'j'  одинаковы
       static_assert(^^i != std::meta::reflect_constant(42));  // отличается от значения 42
  • Добавлен оператор «template for» для перебора элементов, таких как пакеты параметров, похожие на кортежи объекты и результаты рефлексии (метаобъекты), на этапе компиляции в стиле обычного цикла. При выполнении template for тело цикла раскрывается для каждого элемента и каждая итерация обрабатывается в отдельной области видимости, в которой меняющаяся в цикле переменная является константой. В контексте рефлексии template for может применяться для обхода свойств классов или перечислений. Возможность появится в GCC 16.
       void f() {
         template for (constexpr int I : std::array{1, 2, 3}) {
           static_assert(I < 4);
         }
       }
будет раскрыто в:
       void f() {
       {
           constexpr auto&& __range = std::array{1, 2, 3};
           constexpr auto __begin = __range.begin();
           constexpr auto __expansion-size = __range.end() - __begin; // 3
    
           {
             constexpr int I = *(__begin + 0);
             static_assert(I < 4);
           }
    
           {
             constexpr int I = *(__begin + 1);
             static_assert(I < 4);
           }
    
           {
             constexpr int I = *(__begin + 2);
             static_assert(I < 4);
           }
         }
       }
  • Добавлен фреймворк std::execution для асинхронного и параллельного выполнения кода. Предоставляются объекты scheduler, определяющий планировщик выполнения работ (поток, пул потоков, GPU, event loop), sender, определяющий выполняемую работу, и receiver – обработчик результата.
       using namespace std::execution;
       scheduler auto sch = thread_pool.scheduler();
       sender auto begin = schedule(sch);
       sender auto hi = then(begin, []{
          std::cout < "Hello world! Have an int.";
          return 13;
       }); 
    
       sender auto add_42 = then(hi, [](int arg) { return arg + 42; });
    
       auto [i] = this_thread::sync_wait(add_42).value();
  • Добавлена библиотека std::simd для распараллеливания выполнения операций над данными при помощи наборов инструкций SIMD, таких как AVX-512 и NEON, с использованием стандартной системы типов C++.
        std::simd<float> a = {1.0f, 2.0f, 3.0f, 4.0f};
        std::simd<float> b = {5.0f, 6.0f, 7.0f, 8.0f};
    
        std::simd result = a + b;
  • Предложена реализация вектора (массива) переменного размера std::inplace_vector, размещаемого в стеке, размер которого определяется на этапе компиляции. API близок к std::vector, но элементы массива хранятся не в «куче», а внутри объекта.
       inplace_vector a(10);
       inplace_vector b(std::move(a));
       assert(a.size() == 10); 
  • Добавлена директива «#embed», предназначенная для встраивания в код бинарных ресурсов.
       const unsigned char icon_display_data[] = {
           #embed "art.png"
       };
  • Добавлена поддержка генерации и обработки исключений на этапе компиляции при ошибках в контексте constexpr.
       constexpr std::optional<unsigned> checked_divide(unsigned n, unsigned d) {
    	try {
    		return divide(n, d);
    	} catch (...) {
    		return std::nullopt;
    	}
       }
    
       constexpr date parse_date(std::string_view input) {
    	auto [correct, year, month, day] = ctre::match<"([0-9]{4})-([0-9]{1,2})-([0-9]{1,2})">(input);
    	
    	if (!correct) {
    		throw incorrect_date{input};
    	}
    	
    	return build_date(year, month, day);
       }
  • Реализована структура данных std::hive для неупорядоченного хранения данных и обеспечения повторного использования памяти, освободившейся после удалённых элементов. Структура оптимизирована для нагрузок с высокой интенсивностью добавления и удаления элементов в произвольном порядке. В отличие от массивов, удаление элемента в std::hive не вызывает сдвига других элементов, а приводит к пометке удалённого элемента пустым с последующим заполнением освободившейся позиции при добавлении нового элемента.
  • Добавлена библиотека std::linalg c API для линейной алгебры, основанный на BLAS.
  • Добавлена поддержка механизма синхронизации Hazard pointer, позволяющего без выставления блокировок предотвратить освобождение памяти объектов, с которыми продолжается работа в других потоках. При удалении объекта, он лишь помечается удалённым, но занимаемая объектом память освобождается только когда все потоки снимут hazard-указатель, выставляемый во время работы с объектом.
  • Добавлена поддержка механизма синхронизации RCU (open-std.org) («read-copy update») – при операциях записи создаётся новый экземпляр объекта, а операции чтения не блокируются, а продолжают работать со старым экземпляром. После завершения изменения новый экземпляр становится активным и новые операции чтения уже производятся с ним, а старый экземпляр удаляется после завершения читающих его потоков.
  • Внесены изменения для усиления безопасности стандартной библиотеки, такие как проверки допустимых значений и выхода за границы буфера. Например, при доступе к элементу constexpr reference operator[](size_type idx) const; добавляется проверка условия idx < size().
  • Предоставлена возможность использования ключевого слова constexpr с разновидностью оператора new («placement new») для размещения объекта в заранее выделенной памяти во время компиляции.
  • Добавлена поддержка структурированных привязок («structured binding») в контексте constexpr, т. е. ссылки на константные выражения теперь сами могут быть константными выражениями. Поддержка реализована для массивов и простых структур.
       constexpr int arr[] = {1, 2};
       constexpr auto [x, y] = arr; 
  • В структурированные привязки добавлена возможность использования синтаксиса ... для указания пакетов (pack), захватывающих оставшееся число элементов из присваиваемой последовательности.
       auto [x,y,z] = f();         // в переменные  x, y, z будут записаны  три элемента, возвращённые f().
       auto [...xs] = f();         // в пакет xs будут записаны все элементы, возвращённые f().
       auto [x, ...rest] = f();    // В x будет записан первый элемент, а в rest - остальные.
       auto [x, y, ...rest] = f(); // В x будет записан первый элемент, в y - второй, а в rest - третий.
       auto [x, ...rest, z] = f(); // в x - первый, в rest - второй, в z - третий.
  • Добавлена поддержка «тривиальной перемещаемости» типов («trivial relocatability»), позволяющей оптимизировать перемещения объектов заданного типа через их клонирование в памяти без вызова конструкторов или деструкторов. Для классов реализованы свойства memberwise_trivially_relocatable и memberwise_replaceable, а для низкоуровневого перемещения одного или нескольких объектов добавлены функции trivially_relocate_at и trivially_relocate.
  • Реализована поддержка прикрепления функции main() к глобальному модулю и определения функции main() в именованных модулях.
  • Добавлен вариативный оператор friend (friend Ts...).
  • Реализованы атрибуты для структурированных привязок;
  • Добавлен синтаксис ‘= delete(«причина»)’.
  • В базовый набор символов включены «@», «$» и «`».
  • Предоставлена возможность применения структурированного связывания («structured binding») в качестве условия в операторах if и switch.
  • Добавлена возможность использования сразу нескольких переменных-заполнителей с именем _ в одной области видимости, например, теперь являются корректными конструкции:
        struct S {
          int _, _; 
        };
        void func() {
          int _, _;
        }
        void other() {
          int _; // ранее выводилось предупреждение в режиме -Wunused
        }
  • Предоставлена возможность использования строковых литералов в контексте, в котором они не используются для инициализации массива символов и не попадают в результирующий код, а применяются только во время компиляции для диагностических сообщений и препроцессинга, например, в качестве параметров директив и атрибутов _Pragma, asm, extern, static_assert, [[deprecated]] и [[nodiscard]].
  • Добавлены встроенные функции: __builtin_is_within_lifetime для проверки активности альтернативы в объединениях («union») и __builtin_is_virtual_base_of для проверки является ли базовый класс виртуальным.
  • Реализованы тривиальные бесконечные циклы без неопределенного поведения.
  • Обеспечен вывод ошибки при удалении указателя на неполный тип.
  • Объявлен устаревшим синтаксис определения вариативных параметров с многоточием без предшествующей запятой (например, когда указывается void e(int...) вместо void e(int, ...)).
  • Запрещено использование макросов для объявления модулей.
  • Переведено в разряд устаревших выполнение неявных преобразований перечисляемых значений в арифметических вычислениях.
       int main() {
          enum E1 { e };
          enum E2 { f };
          bool b = e <= 3.7; // устарело
          int k = f - e; // устарело
          int x = +f - e; // OK
       }
  • Прекращена поддержка прямого сравнения массивов.
       int arr1[5]; 
       int arr2[5]; 
       bool same = arr1 == arr2;

>>> Источник: OpenNET

★★★★★

Проверено: Dimez ()
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от sunjob

Здрасьте, С++ с самого своего начала был набором хаков и костылей, прикрученным к С соплями и скотчем, для добавления новых возможностей. Вот, с тех пор ничего не поменялось.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

это ваше мнение.

по мне плюсы были вполне «рабочим» инструментом (до сих пор являются, только не вот это вот «нечитаемое болото» с наворотами). читать старый код - одно удовольствие, все в меру локонично и понятно.

sunjob ★★★★★
()
Ответ на: комментарий от sunjob

Это факт из истории языка. А вот «тут читаемо, тут нет, тут, похоже, рыбу заворачивали» уже вкусовщина. В общем, связались с плюсами — терпите.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

скажете тоже

уже вкусовщина

это как сравнивать «удобно/понятно - не удобно/не понятно» - читай как «работает - не работает».

спорить не буду: потому как прекрасно помню как оно было и как оно стало. имхо.

sunjob ★★★★★
()
Ответ на: комментарий от sunjob

раньше (когда изучал его) - все было пристойно, со вкусом, чуством, расстановкой :о)

Тебе показалось ;)

CrX ★★★★★
()
Ответ на: комментарий от sunjob

это действительно нужно или …

Обычно в C++ добавляют то, что действительно нужно. Особенно много этого добавили в диапазоне от С++11 до C++17. Потом началось что-то специфическое: вроде бы добавляют нужное, но в таком виде, что невольно задаешься вопросом «вы ща серьезно вааще?»

Например, в C++20 добавили модули, которые до сих пор не могут полноценно реализовать в компиляторах. Но при этом подосрали всем, у кого были свои велосипеды для сборки и кто не хотел без нужды связываться с CMake. При этом разделили С++ на C++ до модулей и C++ после модулей по аналогии с Python2 и Python3.

В C++26 сделали рефлексию, но с таким всратым синтаксисом, что просто ой.

В С++26 добавлили контракты (что хорошо, давно ждал), но недоделанные :(

У меня уже несколько лет есть убеждение, что 30 лет назад коммитетчики делали C++ для обычных людей, вроде меня. А сейчас коммитетчики делают C++ для таких как они сами. Собралась сотня умок с IQ за 170 со всего мира и делают инструмент под таких же нердов, как они сами. А вот я, обычный деревенский увалень, смотрю на то, что у них получается, и афигеваю.

eao197 ★★★★★
()
Ответ на: комментарий от CrX

да... деревья, трава, солнушка жОлтое улыбается! все именно так и было!!!

sunjob ★★★★★
()
Ответ на: комментарий от eao197

Они просто делают то, что уже работает у других языков. Модули, рефлексия в яве давно есть. Контракты в Скале, Ада, кложе. А если что-то не работает, сделают в конце-концов. Это вопрос к разработчикам компилятора, а не к комитету.

Lusine
()
Ответ на: комментарий от Lusine

Они просто делают то, что уже работает у других языков.

Моя претензия не в том, что они делают что-то ненужное (хотя иногда делают и такое), а в том, что эргономика у того, что делается, оказывается ну такая себе.

Модули, рефлексия в яве давно есть.

Модули в языках программирования были задолго до Java.

Но есть большие сомнения в том, что в язык с 40-летней истории, одной из ключевых особенностей которого было паразитирование на совместимости с Си (отсюда и Си-шная модель компиляции с заголовочными файлами) нужно было втаскивать модули. 40 лет без них прожили, еще столько же можно прожить.

Да, я знаю, что есть куча фанатов современного C++, которые ждут модулей как манны небесной. Но вот у меня есть некоторый объем унаследованного C++ного кода и меньше всего мне хочется тратить время на его адаптацию под модули. А ведь придется :(

Контракты в Скале, Ада, кложе.

Задолго до Scala и пр. Design By Contract себя показал в Eiffel. Почему бы не взять и не сделать как в Eiffel? Но нет, нужно опять идти своим путем и забыть про такую штуку, как old из Eiffel-евских постусловий.

А если что-то не работает, сделают в конце-концов. Это вопрос к разработчикам компилятора, а не к комитету.

А вот меня запарило то, что есть «C++ в стандарте» и есть отдельно «C++ в компиляторах». И разница между этими C++ами измеряется годами.

Хотя коммитет мог бы взять другую модель формирования стандарта:

  • когда пропозал признают достойным включения в язык его не добавляют в очередной стандарт сразу, вместо этого переводят пропозал в категорию, например, technical specification;
  • компиляторостроители реализуют technical specifications по мере своих возможностей;
  • когда TS реализован и опробирован хотя бы в большой тройке компиляторов, тогда его включают в стандарт.

Вот тогда получится, что то, что есть в условном C++29, то есть в мейнстримовых компиляторах на основных платформах. А не так, что в C++29 есть, а в компиляторах появится в 2032-ом году.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Тут вопрос, кто оплачивает разработку gcc. Если это IBM, Intel и т.п. у них могут быть совсем другие приоритеты, чем у комитета. Например в сторону оптимизации кода для их железа, а не поддержка нового стандарта.

Lusine
()
Ответ на: комментарий от eao197

Но есть большие сомнения в том, что в язык с 40-летней истории, одной из ключевых особенностей которого было паразитирование на совместимости с Си (отсюда и Си-шная модель компиляции с заголовочными файлами) нужно было втаскивать модули. 40 лет без них прожили, еще столько же можно прожить. Да, я знаю, что есть куча фанатов современного C++, которые ждут модулей как манны небесной. Но вот у меня есть некоторый объем унаследованного C++ного кода и меньше всего мне хочется тратить время на его адаптацию под модули. А ведь придется :(

Зачем переписывать что-то на модули? Модули вообще не отменяют cpp/hpp. Есть куча цпп/хпп они упаковываются в более крупную логическую единицу - модуль, из которого не торчит ничего лишнего/подробностей, несколько модулей - elf. Модули вполне красиво встраиваются и ничего не ломают. Вот какая боль постоянно писать include <vector> <string> <...>, гораздо логичнее и удобнее один раз сделать import std без лишних деталей что и в каком там хидере лежит

Вот то что их все никак до конца доделать не могут - вот это да печаль, сколько можно, шесть лет уже …

kvpfs_2
()
Последнее исправление: kvpfs_2 (всего исправлений: 2)

На верхнем фото верхний ряд второй справа - Саттер. Слева от него, если я не ошибаюсь - Gasper. Еще нескольких человек узнаю по London C++ Meetup, но имен их не помню.

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от kvpfs_2

Зачем переписывать что-то на модули?

Затем, что совсем скоро наличие модулей будет являться одним из критериев «хорошести» проекта. Собственно, первые шаги к цветовой дифференциации штанов уже сделаны: https://arewemodulesyet.org/

Вот то что их все никак до конца доделать не могут - вот это да печаль, сколько можно, шесть лет уже …

На мой рабоче-крестьянский взгляд – это прямое следствие пагубной практики процесса стандартизации: сперва в стандарт включают описание того, что еще никто не сделал и не опробовал на практике, а потом компиляторостроители пыхтят в попытках все эти благие намерения реализовать.

Так уже было в прошлом с export template. Только одна команда компиляторщиков справилась, остальные – нет. Поэтому из стандарта эту фичу в итоге удалили.

Урок в прок не пошел, наступили на те же грабли с модулями.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

В С++26 добавлили контракты (что хорошо, давно ждал), но недоделанные :(

А можно раскрыть? Я могу и погуглить, но… :)

hatred ★★★★
()
Ответ на: комментарий от hatred

А можно раскрыть?

Насколько я понял, в C++ных контрактах в постусловиях нет специальной конструкции old. Поэтому нельзя написать вот такой контракт, например:

void push_back(T v) post(this->size() == old this->size() + 1)
{...}

Тогда как в Eiffel old является специальной фичей в секции ensure.

Кроме того, опять же как я понял после беглого знакомства с C++ными контрактами, в C++ нет секции invariant для класса. В Eiffel она есть и автоматически проверяется.

Upd. Еще в C++ не стали делать пред-/постусловия для виртуальных методов. Тогда как в Eiffel есть специальные конструкции require else и ensure then, которые специально предназначены для случаев переопределения метода в наследнике. В общем, жалкое подобие :(

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 2)
Ответ на: комментарий от eao197

Затем, что совсем скоро наличие модулей будет являться одним из критериев «хорошести» проекта. Собственно, первые шаги к цветовой дифференциации штанов уже сделаны

Кто-там чего-то считает, и вот список из «передовых» проектов. Да большая часть - нечитаемое говно, где нет разделения на человекопонятная декларация/реализация. Для них модуль - это такой хидер онли подход, который компилиться благодаря модуля должен быстрее. Там хорошим стилем вообще не пахнет.

Модули не заменяют хидеры и тем более файлы реализации. Заменить хидер на модуль ибо модно - не от большого ума, видимо, чтобы писать дополнительное слово export

kvpfs_2
()
Ответ на: комментарий от Reset

Ну, естественно, boost — не единственный источник. fmtlib тоже сама по себе развивалась, прежде чем стать std::print & Co. Да и сейчас развивается, коммиты идут, в том числе, от Зверовича.

Зачем тянуть в стандарт всякое разное — ну, это открытый вопрос, вчера с коллегами дискутировали на этот счёт. Где проходит граница разумности — я не знаю. Главное, чтобы не мешало (например, увеличением размера бинарника/контейнера) для тех, кто не использует, и не увеличивало хрупкость ПО для тех, кто воспользовался.

AlexM ★★★★★
()
Ответ на: комментарий от Neresar

мешают употреблять и писать стандарт

x905 ★★★★★
()
Ответ на: комментарий от AlexM

Главное, чтобы не мешало (например, увеличением размера бинарника/контейнера)

Как аккуратно ты обошел вопрос по времени компилляции.

sarumeister
()
Ответ на: комментарий от Stanson

Если ты делаешь компилятор ЯП настолько сложным, что отдельно взятый человек уже не способен разобраться в его коде за разумное время, то ты де-факто обладаешь полным контролем над всем что написанно на этом ЯП. :)

А на кой простому человеку программисту разбираться в исходном коде компилятора??..

Somebody ★★★★
()
Ответ на: комментарий от AlexM

Недавно в одной из используемых мной библиотек авторы подняли требуемую версию до c++20, и в нескольких местах задействовали <format>. В итоге - опа, и +300Кб к размеру прошивки, она перестала помещаться во флеш-память. А если бы этот формат оставался сторонней библиотекой, то, думаю, вряд ли бы на неё переключились.

Beewek ★★★
()
Ответ на: комментарий от sunjob

старый код можно просто беглым взглядом сканировать, а этот уже ... простите-увольте, я столько не авыкурю

Старость настигла... :))

Somebody ★★★★
()
Ответ на: комментарий от Neresar

Не уважают старперские плюсы и убежали на модно-молодежную растишку.

Lusine
()

Слава Богу я ушёл на Rust 4 года назад. Жаль только, что эту плюсовую херобору читать всё ещё приходится =(

v_0ver
()
Ответ на: комментарий от ugoday

Здрасьте, С++ с самого своего начала был набором хаков и костылей, прикрученным к С соплями и скотчем, для добавления новых возможностей. Вот, с тех пор ничего не поменялось.

Неверное утверждение. Например, базовая фича C++ - деструктор, никак не связана с си и реализована с нуля.

lesopilorama
()
Ответ на: комментарий от AlexM

Зачем тянуть в стандарт всякое разное

Так это не стандарт, это «стандартная библиотека». Её можно не юзать как любую другую библиотеку.

lesopilorama
()
Ответ на: комментарий от eao197

дной из ключевых особенностей которого было паразитирование на совместимости с Си

Откуда вы берётесь? С чего это «ключевая»? Ты мог спокойно писать на C++ никак не полагаясь на си, на сишные макросы и прочую сишную жопу. В каких-то местах может быть си пролезал, но так это скорее зло от которого пытаются избавиться. А как язык си пролезает вообще везде, ибо повлиял на всё синтаксически.

lesopilorama
()
Ответ на: комментарий от eao197

Например, в C++20 добавили модули, которые до сих пор не могут полноценно реализовать в компиляторах. Но при этом подосрали всем, у кого были свои велосипеды для сборки и кто не хотел без нужды связываться с CMake. При этом разделили С++ на C++ до модулей и C++ после модулей по аналогии с Python2 и Python3.

Всмысле. Ты просто можешь не пользоваться этими модулями как не пользовался до этого и ничего не изменится. Основная фича C++20 всё же скорее корутины, которые позволяют порешать многие вопросики с написанием многопоточного кода в одном потоке без жонглирования указателями на функции и процедурно.

lesopilorama
()
Ответ на: комментарий от eao197

Да, я знаю, что есть куча фанатов современного C++, которые ждут модулей как манны небесной. Но вот у меня есть некоторый объем унаследованного C++ного кода и меньше всего мне хочется тратить время на его адаптацию под модули. А ведь придется :(

Не придётся, забей хрен ты уже на модули.

lesopilorama
()
Ответ на: комментарий от eao197

У меня уже несколько лет есть убеждение, что 30 лет назад коммитетчики делали C++ для обычных людей, вроде меня. А сейчас коммитетчики делают C++ для таких как они сами. Собралась сотня умок с IQ за 170 со всего мира и делают инструмент под таких же нердов, как они сами. А вот я, обычный деревенский увалень, смотрю на то, что у них получается, и афигеваю.

Очень странное высказывание, потому что жопу рвало от C++ ещё в 2010 году от обычных шаблонов и книжек Александреску. И рвало просто ядерно. А тут добавили каких-то заковычек - это вообще несерьёзный детский уровень в плане IQ

lesopilorama
()
Ответ на: комментарий от eao197

Моя претензия не в том, что они делают что-то ненужное (хотя иногда делают и такое), а в том, что эргономика у того, что делается, оказывается ну такая себе.

Это претензия уровня: «я сплю на потолке, но почему-то дует». Ты уже занялся каким-то ковырянием в вычислительных устройствах, где пёс ногу сломит, а не стал обычным понятным строителем домов из кирпича. К C++ приделали очередную неудобную фигню - да хоспаде, всем нассать - к какой-то хрени приделали какую-то хрень. Как было далеко от природы и спокойствия, так и осталось. После синтаксиса указателей на функции в языке «си» уже пофиг. При том были в истории языков вещи и пожощще.

lesopilorama
()
Ответ на: комментарий от lesopilorama

С чего это «ключевая»?

С того, что ключевая. Почитайте Страуструпа, он сам писал, что это было принципиальная штука – переиспользование уже готовых С-шных библиотек, компиляторов и линкеров. Первая версия C++а от Страуструпа вообще была транспилером: С++ный код переводился в чисто Си-шный, который потом скармливался обычному Си-шному компилятору, а получившиеся объектники – обычному линкеру.

Ты мог спокойно писать на C++ никак не полагаясь на си

Когда я начал использовать C++, то не мог не полагаться на Си, т.к. в «стандартной» С++ной библиотеке тогда были разве что iostream-ы. Никаких std::string, std::vector и пр.

eao197 ★★★★★
()
Ответ на: комментарий от lesopilorama

Всмысле.

В прямом.

Ты просто можешь не пользоваться этими модулями как не пользовался до этого и ничего не изменится.

Да, на Python2 тоже можно было пользоваться какое-то время не обращая внимания на Python3.

Основная фича C++20 всё же скорее корутины, которые позволяют порешать многие вопросики с написанием многопоточного кода в одном потоке без жонглирования указателями на функции и процедурно.

В C++20 добавили еще и концепты, и operator<=>, и это применяется гораздо активнее, чем короутины. Но речь о том, что наряду с реально нужными и полезными вещами добавляют еще и упомянутые модули, без которых вполне можно было бы и обойтись.

eao197 ★★★★★
()
Ответ на: комментарий от lesopilorama

Очень странное высказывание, потому что жопу рвало от C++ ещё в 2010 году от обычных шаблонов и книжек Александреску.

Отучаемся говорить за всех (с).

Шаблоны – это как раз то, что удержало меня в C++ в конце нулевых. И как раз с шаблонами в языке было более-менее нормально все. Особенно после C++11.

А тут добавили каких-то заковычек - это вообще несерьёзный детский уровень в плане IQ

Ну хз, у меня, например, от изучения тех же короутин из C++20 крышу сносит.

К закорючкам претензии не в их сложности, а в том, что код с ними выглядит как трудночитаемое говно.

eao197 ★★★★★
()
Ответ на: комментарий от lesopilorama

К C++ приделали очередную неудобную фигню - да хоспаде, всем нассать

Еще раз: отучаемся говорить за всех.

Если вы собираетесь программировать на C++ без использования завезенной в C++26 рефлексии и/или контрактов, то это ваши личные сложности. Вы вот, судя по тому как и что пишете в комментариях, и без головного мозга вполне себе обходитесь.

А вот я вполне себе планирую и рефлексию использовать (как только представится возможность), и контракты. И если у рефлексии встратый (на мой взгляд) синтаксис, то мне, блин, с этим придется как-то жить. Хотя, если бы коммитетчики относились к своей работе тщательнее, то жить с рефлексией было бы проще и удобнее.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Почитайте Страуструпа, он сам писал, что это было принципиальная штука – переиспользование уже готовых С-шных библиотек, компиляторов и линкеров. Первая версия C++а от Страуструпа вообще была транспилером: С++ный код переводился в чисто Си-шный, который потом скармливался обычному Си-шному компилятору, а получившиеся объектники – обычному линкеру.

Так это в начале. Если rust использует libc, то чё, он тоже сишное говно? И какая разница как работала первая костыльная версия, вы и программу на Rust можете транслировать в Си без проблем и скомпилять её.

lesopilorama
()
Ответ на: комментарий от eao197

Когда я начал использовать C++, то не мог не полагаться на Си, т.к. в «стандартной» С++ной библиотеке тогда были разве что iostream-ы. Никаких std::string, std::vector и пр.

Так C++ это прежде всего изобретение деструктора. Функция, которая вызывается в конце скоупа. Ещё может быть, шаблоны. std::что-то-там уже само по себе поделки на этом языке написанные, а не сам язык. И какая разница чего там не было раньше, если сейчас всего жопой жуй.

lesopilorama
()
Ответ на: комментарий от eao197

без которых вполне можно было бы и обойтись.

Так без них ты и так можешь обойтись. Забей на них хрен да и всё. Если ты говоришь, что кто-то напишет что-то, где будут модули и ты будешь вынужден это подерживать - так если ты зависим от чего-то, что «пишут какие-то другие люди», то тебе и на Golang могут с тем же успехом напейсать и на JS.

lesopilorama
()
Ответ на: комментарий от eao197

Шаблоны – это как раз то, что удержало меня в C++ в конце нулевых. И как раз с шаблонами в языке было более-менее нормально все. Особенно после C++11.

Так если почитать интернеты, то среднестатистическое высказывание про шаблоны - это «ошибка компилятора на 10 экранов». Типа там Boost.Spirit поюзать можно для примера, но может я неверно вспомнил, но короче это была боль. Если шаблон написан тобой, то ещё ладно - можно прикинуть где бы он мог сдохнуть, а если он чужой и сдох с 3 экранами ошибок, то проще из профессии пойти в проститутки.

lesopilorama
()
Ответ на: комментарий от eao197

Ну хз, у меня, например, от изучения тех же короутин из C++20 крышу сносит.

По разным высказываниям в интернетах, они сделаны через джёппу. Эти высказывания похожи на прочие «очередная новая фича в крестах - сделали пьяные дауны».

Но смысл не в этом, а в том как это работает: пишешь последовательный код вызывая друг за другом функции, а на самом деле он параллельный и его много, а поток один. Но под капотом придётся испытать шок и трудности, но это один раз.

lesopilorama
()
Ответ на: комментарий от eao197

Если вы собираетесь программировать на C++ без использования завезенной в C++26 рефлексии и/или контрактов, то это ваши личные сложности. Вы вот, судя по тому как и что пишете в комментариях, и без головного мозга вполне себе обходитесь.

А вот я вполне себе планирую и рефлексию использовать (как только представится возможность), и контракты. И если у рефлексии встратый (на мой взгляд) синтаксис, то мне, блин, с этим придется как-то жить. Хотя, если бы коммитетчики относились к своей работе тщательнее, то жить с рефлексией было бы проще и удобнее.

Они сделали говно, но ты не встал с дивана и не помог им сделать лучше. Видимо тебе было норм, что они сделают говно. Ты же наверное знал, что они что-то там собрились делать, но проявил равнодушие? Жри теперь, так получается.

lesopilorama
()
Ответ на: комментарий от lesopilorama

Так это в начале.

Так в начале эту особенность заложили и дальше эксплуатировали (и эксплуатируют до сих пор). Нравится вам это или нет, но хорошая совместимости с Си до сих пор для С++ ключевой фактор. Как в плане использования готовых Си-шных библиотек (ffmpeg, к примеру), так и в плане выставления наружу Си-шного интерфейса без каких-либо дополнительных приседаний.

И какая разница как работала первая костыльная версия

Она была не костыльной. За ее счет С++ в мейнстрим и проник.

вы и программу на Rust можете транслировать в Си без проблем и скомпилять её.

Интересно как.

eao197 ★★★★★
()
Ответ на: комментарий от lesopilorama

Так C++ это прежде всего изобретение деструктора.

Да что вы говорите? А еще что скажите?

eao197 ★★★★★
()
Ответ на: комментарий от lesopilorama

Забей на них хрен да и всё.

Проще всего забить на ваши высказывания. Да и на вас вообще.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Так в начале эту особенность заложили и дальше эксплуатировали (и эксплуатируют до сих пор). Нравится вам это или нет, но хорошая совместимости с Си до сих пор для С++ ключевой фактор. Как в плане использования готовых Си-шных библиотек (ffmpeg, к примеру), так и в плане выставления наружу Си-шного интерфейса без каких-либо дополнительных приседаний.

Так и не увидел этим утверждениям каких-то пруфов, из которых было бы видно, что оно «ключевое». Вот это вот хождение вокруг слова «ключевое» выглядит очень эмоционально и без пруфов. Что в классической плюсовой конструкции

template <typename T>
class Skotina {
T a;
T b;
T c;
public:
~ Skotina() {
  a(b(c()));
}
};

является ключевым сишным - невозможно понять.

lesopilorama
()
Ответ на: комментарий от eao197

Как в плане использования готовых Си-шных библиотек (ffmpeg, к примеру), так и в плане выставления наружу Си-шного интерфейса без каких-либо дополнительных приседаний.

Што, карл? Если я в Rust заиспользую какую-то сишную библиотеку, раст сразу вступает с си в отношения «ключевое»? Что такое «выставление наружу сишного интерфейса»? Где там у крестов «Интерфейс»?

lesopilorama
()
Ответ на: комментарий от lesopilorama

Што, карл?

Разговаривать можно с вменяемым человеком. Но пока что я не вижу причин считать вас таковым.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Разговаривать можно с вменяемым человеком. Но пока что я не вижу причин считать вас таковым.

Всё это время я справлялся и без этого требования, как видишь! Ты там поднатужься, тряпка.

lesopilorama
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.