| |
| 2.56, Judge Dredd (-), 15:53, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Экзекуторы добавили!!! Класс!!
- Виновен. Ваш автомобиль будет конфискован.
(booom!)
- Приговор приведен в исполнение.
| | |
|
| 1.3, Аноним (-), 14:10, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Представленные в спецификации возможности частично уже поддерживаются в компиляторах GCC, Clang и Microsoft Visual C++.
И что характерно НИ ОДИН из компиляторов не поддерживает стандарт полностью!
library features так вообще - поддерживаемых почти сколько же сколько не поддерживаемых.
Простите, а это компилятор чего?
Точно С++26, а не какого-то сабсета недоязыка?
| | |
| |
| 2.10, Bottle (?), 14:20, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
А всё благодаря великолепным правилам из разряда "А на этой платформе можно точность другую у интов взять", "Мы будем игнорировать существование #pragma once, гнутых расширений и кланговских, давайте вместо этого ещё что-нибудь из Boost потырим в стандарт за триста франков", "плевать, что в сишке есть restrict, нам не нужна производительность и совместимость в плюсах".
| | |
| |
| 3.26, Аноним (-), 14:37, 30/03/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, то что "можно точность другую у интов взять" это еще ладно.
Если бы в стандарте были только "implementation-defined" с конечным списком вариантов, то было бы ок.
А вот то, что каждый компилятор может выкинуть какие-то фичи, это вообще бред.
Если оставить только 2-3 core language features, это всё еще С++? А если оставить одну?))
Оно ж называется CORE language features, как их можно не реализовывать?
> "плевать, что в сишке есть restrict, нам не нужна производительность и совместимость в плюсах".
СИшка это такой же кусок kalʼа)
Там точно так же не обязаны реализовывать стандарт полностью.
| | |
| |
| 4.28, oficsu (ok), 14:46, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Оно ж называется CORE language features, как их можно не реализовывать?
Core language feature означает вовсе не то, о чём вы подумали. Это лишь способ назвать категорию фич, которые (как правило) нереализуемы библиотечно. Те, которые непосредственно про языковую семантику, а не про надстройки, доступные пользователю
| | |
|
|
| 2.17, oficsu (ok), 14:27, 30/03/2026 [^] [^^] [^^^] [ответить]
| +6 +/– |
Стандарт всегда выходит раньше, чем его поддерживают реализации. Потому что прежде чем делать компилятор, нужно сначала всем собраться вместе и договориться, что делать и как именно. И эту роль как раз и выполняет стандартизация
| | |
| |
| 3.32, Аноним (32), 15:01, 30/03/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Стандарт всегда выходит раньше, чем его поддерживают реализации.
Это понятно. Плюс на имплементацию нужно время.
Но не понятно почему gcc и шланг не поддерживют фичи не то что с++23, а даже с++20.
Да и более старые тоже.
GCC не поддерживает
"Omitting/extending memory allocations" из C++14 core
[[carries_dependency]] из C++11 core
Что-то вроде есть, но partial.
Шланг - аналогично, но другие штуки.
en.cppreference.com/w/cpp/compiler_support.html
Времени не хватило? С 2011 года))
Или "стандарт" такой что на него можно класть болтяру, даже на core?
| | |
| |
| 4.54, oficsu (ok), 15:40, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
> GCC не поддерживает
> "Omitting/extending memory allocations" из C++14 core
Этот пропозал уточняет вординг стандарта и не обязывает компиляторы менять что-либо. Он расширяет свободу компиляторов, а не сужает. Так что данный пропозал не "не поддерживается", а попросту неприменим к GCC. Именно поэтому там N/A
> [[carries_dependency]] из C++11 core
Это атрибут. Атрибуты специально дизайнились как опциональные игнорируемые фичи. Атрибут допустимо объявить поддерживаемым, если компилятор его просто игнорирует. Так в этом случае поступил, например, clang — единственный, для кого есть метка о поддержке
Пользователь же никогда на него не мог завязываться, а потому и не может пострадать от отсутствия поддержки. Эта фича как раз была полностью удалена из стандарта в C++26
Да, в стандарт иногда попадают неудачные фичи, которые на деле оказываются или сложными, или непродуманными, или, как эта, бессмысленными
| | |
|
|
|
| 1.4, Аноним (4), 14:11, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
> Добавлены новые операторы "^^" для получения метаинформации о грамматической конструкции и "[:…:]"
И вот после этого кто-то будет называть раст не читаемым....
| | |
| 1.5, Аноним (5), 14:12, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Вот теперь точно пора ливать из C++. Непонятно как все это удерживать в голове и при этом решать задачу предметной области. Поскорее бы zig до ума довели, ибо zig + go хватит всем.
| | |
| |
| 2.9, Ананоним (?), 14:20, 30/03/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
Просто поинтересуйся на каком стандарте пишут компилятор сами разработчики новых компиляторов. По секрету для тебя: на очень старом, а нововведения всё для тебя, дорогой. Чтобы ты боролся с надуманными проблемами, а не использовал простой язык, на котором всё можно было писать вполне успешно и эффективно ещё 20 лет назад.
| | |
| |
| 3.14, Аноним (5), 14:26, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>поинтересуйся на каком стандарте пишут компилятор
Это уже не мои проблемы
| | |
| 3.30, Сладкая булочка (?), 14:55, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Просто поинтересуйся на каком стандарте пишут компилятор сами разработчики новых компиляторов.
llvm на 17.
> ещё 20 лет назад.
Да, с арифметикой у экспертов туго. Не удивительно, что они что-то бормочат про невозможность сложить два знаковы инта в си.
| | |
| 3.31, Аноним (32), 14:55, 30/03/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> По секрету для тебя: на очень старом, а нововведения всё для тебя, дорогой.
Вранье же!
LLVM subprojects are primarily written using C++17
И уже мигрируют на с++20
discourse.llvm.org/t/rfc-raise-the-minimum-compiler-requirements-to-move-toward-c-20/88894
Просто компилятор должен компилится компилятором, который есть в дистре.
А дистры очень часто поставляют тухляк.
Если бы дистры не тупили так сильно, то можно было бы и кодовую базу компиляторов переводить на современные стандарты.
| | |
|
| 2.45, Аноним (45), 15:22, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
Большую часть из этого вам *обычно* будет не нужна. Но *в некоторых* ситуациях это может очень даже пригодиться. Так что расслабьтесь, не надо - не пользуйтесь и не забивайте голову.
| | |
|
| 1.6, Bottle (?), 14:13, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
По классике жанра: а что там с модулями?
Что-нибудь продвинулось? Судя по табличке с cppreference.com воз и ныне там.
| | |
| |
| 2.12, Аноним (13), 14:25, 30/03/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Достаточно Страуструпа (последнее издание). Остальное от лукавого.
| | |
|
| 1.11, Ананоним (?), 14:24, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кто-нибудь здесь знает, появились ли уже трансляторы так называемых современных версий C++ в, например, C++03?
| | |
| 1.22, Аноним (22), 14:33, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Внесены изменения для усиления безопасности стандартной библиотеки, такие как проверки допустимых значений и выхода за границы буфера. Например, при доступе к элементу "constexpr reference operator[](size_type idx) const;" добавляется проверка условия "idx < size()".
Дамы и господа, свершилось!
| | |
| |
| |
| 3.35, anon5989517240 (?), 15:02, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
Затем что баги с границами контейнеров возникают систематически, а если включить проверку по-умолчанию то в худшем случае перф просядет гдет на 1%. Но обычно еще меньше
> The hardened standard library provides initial cross-platform library security guarantees, including bounds safety for dozens of the most widely used bounded operations on common standard types, including vector, span, string, string_view, and more. For details, see my February 2025 trip report and run (don’t walk) to read the November 2025 ACM Queue article “Practical Security in Production: Hardening the C++ Standard Library at Massive Scale” to learn how this is already deployed across Apple platforms and Google services, hundreds of millions of lines of code, with on average 0.3% (a fraction of 1%) performance overhead.
https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-sta
| | |
|
|
| 1.23, Аноним (23), 14:33, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Ну весь D уже перетянули к себе? Что ж, было бы неплохо, если бы плюсы каким-то уже перегруженными не были.
| | |
| 1.29, Аноним (27), 14:53, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Добавлена поддержка рефлексии (Reflection), позволяющей отслеживать и модифицировать элементы программы на стадии компиляции.
> Добавлен оператор "template for" для перебора элементов, таких как пакеты параметров, похожие на кортежи объекты и результаты рефлексии (метаобъекты), на этапе компиляции в стиле обычного цикла.
Теперь-то достаточно языковых средств, чтобы разработчики Qt могли ими заменить свой Meta-Object Compiler (moc) ?
| | |
| |
| 2.38, anon5989517240 (?), 15:10, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
На самом деле не факт - смотря как они решат реализовывать.
В рамках текущей рефлексии работает интроспекция только для структур данных и функций, но она например пока не позволяет достаточно гибко генерировать код методов (насколько я понимаю) так что если Qt и начнет перетаскивать moc туда то или не весь, или будут ждать с++29 😒
| | |
| 2.55, Аноним (45), 15:44, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Теперь-то достаточно языковых средств, чтобы разработчики Qt могли ими заменить свой Meta-Object Compiler (moc) ?
https://www.qt.io/blog/c26-reflection-qrangemodel
> The obvious question is then if and how we plan to use C++26 reflections to replace moc. I have not done a feature-by-feature comparison between the meta object data we need to generate, and what we can get out of std::meta; but it seems that we can make the C++ compiler do much of the work that moc does. The biggest challenge might be the signals: and slots: member function blocks; we might have to annotate every function separately. | | |
|
| 1.40, Аноним (40), 15:12, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Реализованы тривиальные бесконечные циклы
> без неопределенного поведения.
Ахаха! Ну надо же!
Оказывается могут когда хотят))
Всего лишь 40 лет понадобилось.
| | |
| 1.43, Христианин (?), 15:17, 30/03/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Во имя ОтцаиСынаиСвятагоДуха.
Скажите: а смысл в таких новшествах ?
Раньше вместо пре - был конструктор
вместо пост - деструктор
Но я давно не в теме.
| | |
| |
| 2.47, anon5989517240 (?), 15:25, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
Конструктор и деструктор можно только к объекту применить,
а эти проверки можно к аргументам отдельных функций привязывать - эт в других кейсах нужно.
Плюс там можно гибко вырезать из компиляции эти проверки если надо.
| | |
| |
| 3.50, Христианин (?), 15:35, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
СпасиБог что не прошли мимо.
Я это понимаю, но неужели нельзя предусмотреть в объявлении класса ?
Для каких целей нужен новый инструмент
Разрешение использования _ - действительно полезная вещь
| | |
| |
| 4.51, Христианин (?), 15:37, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
вернее в реализации класса ?
Давно отстал от темы.
Сдавал плюсы в начале нулевых на хорошо -4.
Ныне в Белоруссии 10балльная система оценок.
учителям больше чем пятибальная нравится
| | |
|
|
| 2.52, Аноним (45), 15:37, 30/03/2026 [^] [^^] [^^^] [ответить]
| +/– |
Вы путаете конструкторы/деструкторы (которые про инициализацию и освобождение ресурсов) и пре/постусловия (которые про состояние программы в данный момент времени).
| | |
|
|