LINUX.ORG.RU

Герб Саттер — отчёт о встрече по стандартам ISO C++ в июне 2026 года

 ,


2

3

https://herbsutter.com/2026/06/13/brno-trip-report.

Несколько минут назад (прим.: 13 июня 2026 г.) комитет ISO по C++ завершил первое заседание по C++29 в прекрасном городе Брно, Чехия (в гибридном формате с онлайн-участием через Zoom).

Организатором этой встречи выступил Университет имени Менделя в Брно. Благодарим всех, кто принимал участие в её проведении, и в особенности Хану Дусикову, которая возглавила работу по подготовке мероприятия! Наши хозяева обеспечили нам высококачественные условия для проведения шестидневной встречи с понедельника по субботу.

В мероприятии приняли участие около 200 человек, из которых примерно 55% присутствовали на месте, а 45% — онлайн; они официально представляли 28 стран. На каждой встрече у нас регулярно появляются новые гости, которые никогда раньше не участвовали в мероприятии, и на этот раз, помимо новых участников, являющихся официальными представителями национальных организаций, было 25 новых гостей, в основном присутствовавших на месте. Ещё раз приветствуем всех!

В настоящее время в составе комитета действуют 22 подгруппы, 11 из которых в течение недели проводили заседания в рамках 6 параллельных сессий. Некоторые группы работали всю неделю, а другие — несколько дней или часть дня, в зависимости от объёма работы. Краткое изложение процедур ISO можно найти здесь.

Принято для C++29: Изменения и новые возможности ядра языка

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

  • P3596R3 «Неопределённое поведение и приложения IFNDR» (авторы: Joshua Berne, Timur Doumler, Jens Maurer и Shafik Yaghmour). Данная статья дополняет стандарт C++ двумя приложениями, в которых подробно каталогизированы и задокументированы все случаи неопределённого поведения (UB) в C++, включая случаи, помеченные как «некорректная форма, диагностика не требуется» (IFNDR). Данный каталог предназначен для содействия смягчению или устранению случаев UB, в том числе с помощью профилей. Это была, простите за мой французский, целая «[метрическая] тонна» работы, проделанной на протяжении нескольких лет. Спасибо Shafik, Joshua, Timur, Jens и всем, кто помог им составить этот подробный каталог, благодаря чему теперь мы сможем систематически заняться этими случаями неопределённости (UB)! Следующим шагом станет рассмотрение каждого случая в отдельности, которое начнётся в следующем месяце с целью систематического решения этих проблем к C++29, возможно, уже в течение следующего года (подробнее об этом ниже). Здесь, в C++, мы смотрим в глаза реальности без страха и пристрастий. На случай, если это нужно повторить: «Да, Вирджиния, существует динамичный, живой и современный язык программирования под названием C++». (Только, в отличие от оригинала, эта версия — правда для взрослых).

  • P3097R3 «Контракты в C++: виртуальные функции» (авторы: Timur Doumler, Joshua Berne и Gašper Ažman). Цитата из статьи:

    «Утверждения переопределяющей функции не зависят от утверждений в переопределяемой функции. При вызове виртуальной функции оцениваются утверждения о предварительных и конечных условиях как статически выбранной функции, так и конечной переопределяющей функции. Данный подход развивает ранее предложенные решения, поддерживая более широкий спектр сценариев использования, встречающихся в существующем коде, более естественно интегрируясь с семантикой оценки контрактов и обработкой нарушений контрактов в C++26, а также лучше подходя для языка C++, чем более ограничительные модели в таких языках, как Eiffel и D».

    Добавление этой функции устраняет одну из основных претензий к контрактам в C++26, а именно то, что первоначальная версия контрактов не поддерживала виртуальные функции. Теперь, менее чем через три месяца после технического завершения работы над C++26, в проекте стандарта C++29 контракты уже поддерживают виртуальные функции. Это свидетельствует о том, что комитет серьёзно настроен на развитие контрактов C++26 в рамках C++29. Спасибо, Timur, Joshua and Gašper!

  • P3668R4 «Операции инкремента и декремента в постфиксной нотации по умолчанию» (авторы: Matthew Taylor и Alex). В данной статье добавляется поддержка =default для операторов инкремента и декремента в постфиксной нотации, что позволяет использовать каноническое определение, отсылающее к префиксным версиям, без необходимости вручную писать шаблонный код (и, возможно, допускать ошибки). Спасибо, Matthew и Alex! Например, приведённый в статье пример теперь допустим в проекте C++29:

class foo{
    int member;
public:
    constexpr foo& operator++(){
        ++member;
        return *this;
    }
    constexpr foo operator++(int) = default;
};
struct A { int a; };

struct B : A { int b; };

B{{1}, 2}         // уже допустимо в C++17
B{1, 2}           // уже допустимо в C++17

B{.a=1, .b=2}     // теперь допустимо в C++29
B{{.a=1}, .b=2}   // теперь допустимо в C++29
B{.a{1}, .b{2}}   // теперь допустимо в C++29

B{.b=2, .a=1}     // остаётся недопустимым

Кроме того, мы добавили ещё целый ряд языковых расширений и улучшений.

Принято для C++29: Изменения и новые возможности стандартной библиотеки

Помимо устранения ряда проблем, в стандартную библиотеку были включены 18 статей, в том числе следующие:

  • P3091 «Улучшенные операции поиска для map, unordered_map и flat_map» (автор: Pablo Halpern). Этот документ добавляет в C++29 поддержку вызова .lookup(key) в стиле Python для map, unordered_map и flat_map. Эта функция, возвращающая опциональный параметр, открывает возможности, недоступные сегодня с помощью оператора [], который всегда вставляет элемент, если его нет, и find, который находит только те элементы, которые присутствуют. Спасибо, Pablo! Вот пример из статьи:
constexpr double inf = std::numeric_limits<double>::infinity();

double largest = -inf;

for (int i = 1; i <= 100; ++i) {
  largest = std::max(largest, theMap.lookup(i).value_or(-inf));
}
  • P3125R6 «Маркировка указателей constexpr» (автор: Hana Dusíková, известная как «королева constexpr»). Представленный в этой статье тип указателя с тегом pointer_tag_pair<Pointer, BitsRequested = /* доступные младшие биты */, Tag = unsigned> обеспечивает переносимую поддержку хранения информации в младших битах указателей. Это библиотека низкого уровня, полезная для решения многих задач, включая обеспечение безопасности памяти и усиление защиты. Спасибо, Hana!
  • P3248 «Сделать [u]intptr_t обязательными» (автор: Gonzalo Brito Gadeschi). Формально в C и C++ до сих пор типы intptr_t и uintptr_t были «необязательными», поэтому реализация на C++ могла не поддерживать их. Поскольку они полезны для низкоуровневого кода и уже широко поддерживаются, теперь стандарт C++ будет требовать их наличия. Спасибо, Gonzalo!
    Мы также добавили ряд других расширений и улучшений библиотеки.
Другие достижения, в частности в области обеспечения безопасности работы с памятью

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

  • Систематическое решение проблемы неопределённого поведения (UB) в C++ для стандарта C++29. Подгруппа по развитию языка (EWG) также одобрила выделение значительного времени этим летом и осенью на построчное рассмотрение в режиме телеконференции документа P3100 «Концептуальная основа для систематического решения проблемы неопределённого поведения в стандарте C++» (авторы: Timur Doumler and Joshua Berne), с целью включения его в стандарт C++29. Отличное краткое изложение можно найти в аннотации к документу.
  • Спецификация профилей для C++29. Подгруппа по безопасности и защите (SG23) приняла решение разработать спецификацию профилей, которая позволит использовать правила статического и иного анализа, ограничивающие набор функций C++, с целью обеспечения того, чтобы в коде не использовались нежелательные (например, небезопасные с точки зрения памяти) операции, и тем самым усилить безопасность кода C++ определёнными способами. Эта спецификация будет включена в C++29, если она будет готова вовремя, как ожидается; в противном случае она может быть опубликована в виде технического документа одновременно с C++29.
  • Профиль инициализации. Группа SG23 также рассмотрела текущий проект документа P4222 «Профиль инициализации» (автор: Bjarne Stroustrup), и мы рассчитываем добиться дальнейшего прогресса в этой работе в течение этого года, в том числе с учётом опыта реализации по крайней мере в одной крупной кодовой базе компилятора.

Как я уже упоминал в своих предыдущих отчетах о поездках, среди других документов по профилям, над которыми я ранее работал, можно назвать P3984 «Профиль безопасности типов» (автор: Bjarne Stroustrup) и P3589R2 «Профили C++: инфраструктура» (автор: Gabriel Dos Reis), а также ряд других дополняющих их документов с предложениями по профилям.

Сказать, что это были бы чрезвычайно важные и исторические достижения — значит сильно преуменьшить их значение:

  • предоставляется способ систематически решать проблемы, связанные с неопределённым поведением (UB) в C++, и
  • предоставляется способ гарантировать, что программа на C++ обладает определёнными свойствами, например, отсутствие ошибок, связанных с безопасностью работы с памятью.

Мы ещё не достигли этой цели, но обе задачи теперь явно выходят за рамки простого желания; это серьёзные рабочие задачи, по которым комитет намерен добиться значительного прогресса в ближайшем будущем. Я буду продолжать освещать эти усилия в будущих отчётах о поездках по мере продвижения работы.

Напоминание для тех, кто по-прежнему скептически относится к тому, что реализация UB на C++ когда-нибудь станет возможной: помните, что мы уже этим занимаемся. Не живите прошлым… «Уже не 2021 год». BeCPP, YouTube.

  • Код constexpr C++, который в настоящее время охватывает практически весь язык C++ и стандартную библиотеку, уже гарантированно не вызывает неопределённого поведения при выполнении на этапе компиляции.
  • В C++26 были устранены ещё два основных источника неопределённого поведения (UB): использование неинициализированных переменных стека больше не приводит к UB, а в упрочнённой стандартной библиотеке C++ добавлена защита от выхода за пределы для десятков наиболее распространённых операций с границами (эта функция уже широко внедрена для упрочнения платформ Apple и Google; подробнее об этом см. в моём предыдущем отчёте о поездке).
В заключение

Еще раз благодарим около 200 экспертов, которые приняли участие в заседании на этой неделе как очно, так и в режиме онлайн, а также всех тех, кто участвует в работе по стандартизации через свои национальные органы!

Но мы не собираемся сбавлять обороты… Мы продолжим проводить заседания подгрупп в Zoom, а наше следующее полное заседание состоится в ноябре в Армасан-дус-Бузиус, недалеко от Рио-де-Жанейро (Бразилия), где мы продолжим работу над добавлением новых возможностей в C++29. Надеюсь увидеть многих из вас там.

Спасибо всем, кто читает это сообщение, за ваш интерес и поддержку C++ и его стандартизации.

★★★★★
Ответ на: комментарий от lolkasosaka

Лапша она в головах, а не в C++ Эти разные вещи предназначены для разных задач. Единого решения для всего быть не может

Reset ★★★★★
()

вообще, в С++ где-то в начале очень сильно обделались пытаясь сделать полностью машинонезависимый язык. чего делать было категорически нельзя. есть такой флажок в любом процессоре, кроме наверно эзотерических - но им брейнфак в самый раз - carry flag.

что мешало ввести в стандарт этот самый carry flag, плюс есть overflow как комбинация CF+SF.

можно было бы нагрузить эти флажки смыслом, например:

int a = ...;
int b = ...;
int c = a+b;
bool f1 = overflow(c);

uint x = ...;
uint y = ...;
uint z = x+y;//на выходе z + carry flag
bool f2 = carry(z); 
// результат: uint z это пара {uint,bool}
uint w = x-y;
// uint w в процессе анализа находим что перенос не пригодился и отбрасываем его.

но одновременно:

int foo() {
   throw 5;
   //mov rax, &exception_int5 // для более сложных типов туда можно адрес исключения положить
   //setc
   //ret
}

//пример 1:
int a = foo();
//не забираем перенос, значит это исключение.
int b = foo();
if (e = fail(b)) { //поймали исключение e
  ... 
}
int с = fail(foo(),100);
//поймали исключение и заменили 
int d = fail(foo(),100);
if (e = fail(d)) {
}
//поймали исключение и заменили и еще и обработали

это упростило бы исключения которые сейчас полагаются на потетень типа __cxa_throw, раскрутку стека и отдельную секцию в файле. а тут можно jc в зону где вызываются деструкторы, там pushfd, всех вызвать, popfd и снова jc в зону деструкторов scopа повыше. lookup(key) мог бы кидать int например.

формат функции fail можно под другому сделать - это только для примера.

но маемо что маемо, и вместо дешевого в вычислительном плане способа вооот такие фортели приходится выдумывать.

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

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

А знаешь, почему так? ПОТОМУ ЧТО ТЫ СТАРЫЙ.

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

Интересная идея, можно и в Си использовать.

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

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

Машинонезависимости это всё никак не повредит, на процах без поддержки флага переноса (если такие найдутся) можно его эмулировать. Если найду время доделать свой компилятор, реализую наверно это в нём.

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

Т.е. в вашей вселенной std::format/std::print нужно было делать вместо std::cout уже в 1985-ом году?

А хер-ли нет-то? printf() тогда уже был.

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

А хер-ли нет-то? printf() тогда уже был.

printf как небезопасное Си-шное наследие без возможности адаптации под вывод своих типов был, а шаблонов и constexpr не было.

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

Подумаешь. В парламентах каждый

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

Если честно, то именно это я считаю главной причиной появления языков альтернативных Си++, а не сказки про «надёжность, шелковистость, молодёжность». Развитие Си++ захватила мафия профессиональных разработчиков стандарта и разбираться с этой мафией непродуктивно. Продуктивно просто создать новый язык.

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

что мешало ввести в стандарт этот самый carry flag, плюс есть overflow как комбинация CF+SF.

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

Это так не сработает:

int a = ...;
int b = ...;
int c = a+b;
bool f1 = overflow(c);

В int нет нужной разрядности.

Вот так должно быть синтаксически:

int a = ...;
int b = ...;
(int c, bool ov) = add_w_ov(a, b);
wandrien ★★★★
()
Ответ на: комментарий от firkax

Я это к тому что создатели с++ как правильно сказал VIT не пишут код. Они не понимают во что обходятся исключения, не понимают как сделать переносимо и дёшево. Отсюда же и совершенно отгороженная рефлексия. Как это сделано в Qt они посмотреть не могут походу. Там вопрос буквально одного нового ключевого слова. Нет, нагородили упыриных конструкций.

И сейчас мы видим то же самое. Вместо того чтоб четко сказать: тут ub и надо писать ворнинг, а больше нигде его нет, начинается цирк с конями, какая то категоризация.

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

Не надо возвращать в int. Можно неявно признать int структурой содержащей дополнительные рациональные поля. Если поле не используется оно удаляется. Через аргументы функций и ссылки для простоты использование не передается. Через возврат передается, это дёшево.

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

Это всё синтаксические детали. По мне так конструкция с carry(x) выглядит приятнее. То что оно явно не упомянуто в виде отдельной переменной и соответственно не занимает ни запись в пространстве имён, ни место на экране - только плюс. Ну и то что сложение обозначается символом «+», а не функцией с длинным названием и скобками - тоже красивее.

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

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

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

Или проще говоря, если ты не один из них, то предложение внести не сможешь.

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

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

Прикол в том что это можно легко добавить в llvm в режиме «на дурака». CSE и удаление неиспользуемых выражений все потом отлично порежет.

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

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

Если хочется краткости, нужно придумать синтаксическую конструкцию, которая это завернёт. Например так:

int c = checked(a + b) else {
  return false;
};

Такого пока нет.

В современном C++ ты можешь делать так:

auto [c, ov] = add_with_overflow(a, b);
wandrien ★★★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от ckotctvo

Да, и ещё дополню, что в RISC-V и MIPS нет регистра арифметических флагов.

Это не какие-то «эзотерические процессоры», MIPS в своё время был одной из самых массовых архитектур, а RISC-V развивается Китаем как потенциальный конкурент ARM.

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

В таких архитектурах можно использовать дополнительный регистр. В х86 внезапно тоже выгодно вытащить значение через setc в регистр.

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

У меня есть чувство прекрасного. А системно сочинять мерзость много ума не надо. Ну подумаешь язык выглядит как говно, зато как академично, как системно.

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

Ага, по чувству прекрасного напоминает PHP…

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

Нужна фича - просто реализуешь её сам.

Отличная идея! Не знаю, зачем люди стандарты напридумывали? Просто берёшь и реализуешь в своём внутреннем компиляторе всё, что тебе надо и проблем не знаешь. Гениально!

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

Не знаю, зачем люди стандарты напридумывали?

Очевидно ж зачем - можно не работать на основном месте работы.

А если твоя фича реально полезна другим - делишься ей (опенсорсно) и все тоже начинают использовать. Вот gcc, не знаю как сейчас (уже сомнения), но раньше просто реализовывали всё то, что считали полезным, и хорошо всё получалось.

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

В приличных местах за использование gcc могут очень расстроить как раз по причине, только что вами озвученной - очень плохое следование стандартам и большое количество расширений. Для бизнеса это плохо. Очень плохо.

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

А если твоя фича реально полезна другим - делишься ей (опенсорсно) и все тоже начинают использовать.

Это называется ёмким словом «базар». Базар - проблема поддержки проекта. Опять же, лучше в эти игры не играть. На раннем этапе проекта, когда нет людей и денег, для стартапа это может и подходящая стратегия, нужно выжить, а для стабильного проекта путь к развалу.

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

Смехопанорама. printf и std::format ну совсем для разного! Одно для графики в игорях, наверно, а другое для сортировки.

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

Ну в C додумались до printf как-то сразу

Эта фраза напомнила мне интересный факт - в Фортран 77 зачем-то завезли WRITE, в то время как уже существовал оператор PRINT. зачем? А ведь Фортран тоже не пальцем делали, в IBM дураков тогда не держали.

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

Ну в C додумались до printf как-то сразу, а тут сложна!

Вы будете смеяться, но да, чтобы пройти от сишного printf к безопасному C++ному std::print пришлось проделать очень и очень длинный путь. Например, от появления самых примитивных шаблонов до их нынешнего состояния.

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

printf как небезопасное Си-шное наследие без возможности адаптации под вывод своих типов был, а шаблонов и constexpr не было.

В чём проблема сделать аналогичный интерфейс, но при этом относительно безопасный? В минимальном варианте для этого не требуются ни шаблоны, ни constexpr.

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

В чём проблема сделать аналогичный интерфейс, но при этом относительно безопасный? В минимальном варианте для этого не требуются ни шаблоны, ни constexpr.

Проблема в том, что есть фантазии умников на форуме, вооруженных послезнанием, и есть реальный мир, в котором сложные вещи развиваются причудливым эволюционным путем.

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

и есть реальный мир, в котором

куча языков программирования, разных, на любой вкус. И такого бардака как в С++ там нету. Этот факт требует осмысления.

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

куча языков программирования, разных, на любой вкус

Но весь массово тиражируемый промышленный код - от ОС и библиотек для работы с графикой, сетью и пр. до баз данных написан на си / спп. Максимум - java / dotnet.

Этот факт требует осмысления.

Верно.

Моя рабочая гипотеза - бардак в си / си++ лучше справляется с бардаком в реальном мире, чем "куча языков программирования, разных, на любой вкус", которые жидко пукнув обмякли где-то в районе студентческих лаб и хобби-проектов.

Что совсем характерно, из "не си / с++" единственным худо бедно взлетевшим языком оказался пистон, бардаку в котором может позавидовать любой с++.

(Вебню с js и go пока вынесем за скобки.)

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

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

Написан на java, go и typescript. Я, конечно, слегка преувеличиваю. Но вы ведь первый начали.

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

java, go и typescript.

Где я могу увидеть комплиятор шейдеров на этих языках? Компрессор текстур? TCP-стэк?

Если кто-то не понимает слово "тиражируемый", то я подсказываю - нет, это не тиражируемое на три с половиной сервера in house solution "Horns & Hooves" Ltd. по жысоноукладке в бд.

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

на этих языках? Компрессор текстур? TCP-стэк?

Cherry picking, suppressing evidence, or the fallacy of incomplete evidence is the act of pointing to individual cases or data that seem to confirm a particular position while ignoring a significant portion of related and similar cases or data that may contradict that position. Cherry picking may be committed intentionally or unintentionally.

P.S. Если вы троллите, вам должно быть стыдно, а если вы это всерьёз, то всё вообще печально. Полное игнорирование последних 15 (а то и 20) лет развития индустрии.

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

suppressing evidence,

Какой evidence-то, прости господи? Ты пока ни одного не привёл.

Полное игнорирование последних 15 (а то и 20) лет развития индустрии.

По замене PHP на go? Оно-то тут при чём?

У тебя по существу тезиса:

весь массово тиражируемый промышленный код - от ОС и библиотек для работы с графикой, сетью и пр. до баз данных написан на си / спп. Максимум - java / dotnet.

Какие-то конкретные возражения есть? Ну, кроме ухода в отрицание, плача, истерик и рандомной копипасты на английском?

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

Ты пока ни одного не привёл.

Так мне и не нужно играть в идиотские игры и выигрывать идиотские призы. Я тоже могу надёргать частных случаев и это будет та же самая логическая ошибка. А зачем не ошибаться? Предоставим это дело вам.

По замене PHP на go?

По замене С++ на java/c#/go/typscript/python/rust и другие более востребованные языки.

Какие-то конкретные возражения есть?

Ваша исходная посылка ложна, поэтому все выводы из неё ложны тоже. Соответственно и конкретные возражения не нужны.

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

И такого бардака как в С++ там нету.

Что именно подразумевается под бардаком?

Сколько языков программирования развиваются таким же по размеру комитетом, как C++? (Это я не пытаюсь сказать, что разработка комитетом – это хорошо, но сам факт разработки комитетом имеет свои э… особенности, скажем так).

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

Ваша исходная посылка ложна,

Прекрасно. Опровергни её простым фактом. Приведи тот код на lisp’е, который развёрнут и ежедневно эксплуатируется миллионными инсталляциями.

Максимум - java / dotnet.

java/c#

Ты точно споришь со мной, а не с голосами в своей голове?

java/c#/go/typscript/python/rust

  1. Как у тебя питон-то попал в этот список?

  2. В каком месте typscript заменил C++?

Ты вообще себя нормально чувствуешь? Такое ощущение, что ты просто щитпостишь рандомный набор баззвордов не приходя в сознание.

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

Опровергни её простым фактом.

Дорогой коллега, я не знаю как ещё яснее объяснить, что анекдотические свидетельства не работают там, где нужна статистика. Может быть другие лоровцы справятся лучше. Пожелаем им удачи в этом нелёгком деле.

Как у тебя питон-то попал в этот список?

Действительно, как один из самых популярных языков современности попал в список популярных языков программирования? Наверное ветром надуло.

В каком месте typscript заменил C++?

В индустрии. От кровавого интерпрайза до хипстерских стартапов.

Ты вообще себя нормально чувствуешь?

Спасибо, что спросили. Хоть кто-то обо мне заботится.

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

По замене С++ на java/c#/go/typscript/python/rust и другие более востребованные языки.

Та замена, которую я видел, массово происходила в конце 1990-х и начале 2000-х. Она была вполне себе оправдана тем что: мощность компьютеров выросла настолько, что «Java перестала тормозить» (с), что привело к тому, что стало можно оказаться от нативных небезопасных языков вроде Си и C++ в пользу чего-то более подходящего для прикладного программирования.

Благодаря чему C++ вернулся в ту нишу, для которой он изначально и предназначался (сложное ПО с высокими требованиями к производительности и ресурсоемкости). Просто в 1980-х и первой половине 1990-х чуть ли не все ПО оказывалось в этой нише из-за слабости тогдашних компьютеров, что и вынуждало использовать C++, а не условный SmallTalk или Lisp.

Сейчас же если где-то замена и происходит, то разве что на Rust. Ну так Rust специально на замену и создавался, да еще и с учетом набранного за 30 лет опыта использования C++.

Естественный процесс.

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

анекдотические свидетельства не работают там, где нужна статистика.

То есть, у тебя вообще никаких свидетельств нет и "Ваша исходная посылка ложна," не потому, что у тебя есть опровергающие её факты, а потому что её истинность не вмещается в череп?

В каком месте typscript заменил C++?

В индустрии.

Я могу увидеть переписанный на typscript компилятор шейдеров или компрессор данных? Я даже поставлю вопрос шире - я могу увидеть хоть что-то, что изначально было на C++, а потом было переписано на typscript? Я, конечно, надеюсь, но есть у меня ощущение, что вопрос окажется риторическим.

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

Та замена, которую я видел,

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

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