LINUX.ORG.RU

новости про C23

 ,


0

3

Как-то я пропустил эту статью от 28 февраля: https://thephd.dev/ever-closer-c23-improvements

Кратко о том что приняли нового в С23, и какие предложения отвергли. (в статье расписано более подробно)

Приняли:

  • N2935 Make false and true first-class language features
  • N2927 typeof
  • N2653 N2828 char8_t and Unicode Improvements!
  • N2900 Consistent, Warningless, and Intuitive Initialization with = {}
  • N2826 unreachable()
  • N2829 Make assert() macro user friendly for C and C++
  • N2432 N2841 K&R Function Declaration AND Definitions are 🪦
  • N2808 allow 16-bit ptrdiff_t again
  • N2778 Separating Variably-Modified Types from Variable Length Arrays
  • N2775 Literal Suffixes for _BitInt(N) types
  • N2701 @, $, and backtick are added to the source character set
  • N2764 [[_Noreturn]]
  • N2840 Make call_once mandatory

К сожалению часть предложений была отклонена от включения в С23:

  • N2896 #once and #once YOUR_GUARD_ID_HERE, to reduce include guard spam
  • N2895 N2892 defer, Lambdas
  • N2859 break break;, break continue;, break break continue;
  • N2917 constexpr

Также хочу скопировать из статьи пояснения по поводу defer и constexpr

defer, Lambdas, and similar were voted down, but still have consensus to proceed for a timeline beyond/after C23. I’ve personally volunteered to direct and maybe even steer the effort for Lambdas. defer might come along for the ride since it’s basically in the same vein when it comes to what variables are available for defer. Spoiler: we’re going to be pursuing barebones, simple defer that is block-scoped (to the nearest braces, or conditional/etc. if the braces are omitted). This is mostly to save us from making the same design mistake Go did, where they have a defer that may dynamically allocate (?! Jesus Christ!) or other complete nonsense.

other complete nonsense - ссылка на твит с таким текстом:

And this blocks

  for i := 0; i < 100000; i++ {
    mutex.Lock()
    defer mutex.Unlock()
    *counter += 1
  }

Is there anything in Go that is not broken?

constexpr - an extremely watered down version compared to C++ that is super simple and deliberately intended not to be much more than updated ways of handling constants in C - did not die. There is strong support to work on it, albeit it might not make C23. Which is perfectly okay, as long as it stays alive!

★★★★★

Мне кажется, что, если бы у разработчиков стандарта не были так связаны руки, в смысле обратной совместимости, то язык бы преобразился, а вот в хорошую или плохую сторону – уже другой вопрос, а если получилось плохо, то никто не забирает возможность оставаться на ламповом C99). Все всё равно сидят на одном стандарте (чаще всего C99) и никуда не переходят.

В этом смысле мне нравится раст: они ввели «эпохи» в рамках которой твой код 100% соберется, а в другой уже не факт.

snake266 ★★★
()

N2432 N2841 K&R Function Declaration AND Definitions are 🪦

Ушла эпоха, помянем:

int main(argc, argv)
int argc, char **argv;
{
    return 0;
}
EXL ★★★★★
()
Ответ на: комментарий от snake266

они ввели «эпохи» в рамках которой твой код 100% соберется

Ну или не соберется, потому что есть зависимости от библиотек на реальных языках (С, C++, итд) а они могут устареть, а что бы подключить новые биндинги, нужно обновить версию языка.

И как там с ABI дела? Это тоже влияет на стандарт.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
// identifier list definition , not a prototype
long maxl (a, b)
long a, b;
{
return a > b ? a: b;
}

Что за ересь? Чё бы не третий раз список аргументов повторить, раз такая пьянка?

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

А сделано так было раньше, насколько я помню потому, что можно было писать:

func(a, b, c) 
{
    return a + b + c;
}

Подразумевая, что a, b, c – являются int, а вот другие типы (отличные от int) нужно было указывать явно в таком определении.

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

Ну или не соберется, потому что есть зависимости от библиотек на реальных языках (С, C++, итд) а они могут устареть, а что бы подключить новые биндинги, нужно обновить версию языка.

В чем проблема подтянуть старую версию библиотеки, с которой проект собирался?

И как там с ABI дела? Это тоже влияет на стандарт.

В расте? Бог его знает – я его привел, потому что «эпоха» (или редакция), на первый взгляд, не такая уж и плохая концепция в языке.

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

В чем проблема подтянуть старую версию библиотеки, с которой проект собирался?

Она уже не работает на современной системе.

MOPKOBKA ★★★★★
()

Make false and true first-class language features

Джва тысячелетия ждал. То что в stdbool.h - это другое.

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

Чистота помыслов и последовательность спрямления береговых линий, конешшшно, а ты что подумал? :)

slackwarrior ★★★★★
()

we’re going to be pursuing barebones, simple defer that is block-scoped (to the nearest braces, or conditional/etc. if the braces are omitted)

Охренеть, как же можно было сделать defer, который работает не на уровне областей видимости. Был уверен, что оно работает как атрибут cleanup, но даже при копировании существующей функциональности налажали…

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

В этом смысле мне нравится раст: они ввели «эпохи»

И каждый новый релиз компилятора поддерживает все предыдущие «эпохи»?

В плюсах версионирование синтаксиста тоже как-то обсуждалось.

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

Современный стиль

В контексте сишки «современный» это где-то в середине восьмидесятых?

Старый стиль

Профит слабо ощущается. Вот если бы так:

func(RandomLongType a, b, c)
{
  return 0;
}

Но деды не осилили, потому и выпилили.

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

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

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

Не знаю, я привел раст, только для примера, да и не углублялся я в такие тонкости про abi.

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

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

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

Концепция не плохая, но сам факт того что в биндингах требуется другая версия языка и нет явно определённого подмножества совместимого со всеми версиями всё портитэ как должно быть - чётко определённое подможество не привязанное к эпохе, ему должны соответствовать все интерфейсы, биндинги, и тогда не будет вопроса о поломке в пределах одного ABI.
Как в си - есои ты определил интерфейс состоящий из базовых типов - он не сломается, будет работать и в си, и в C++ и биндинги легко будет написать. Если же интерфейс написан на c++ и из него торчит STL, то код, собранный с другими -std даже если и соберётся, то модет не слинковаться. Но реально почти все интерфейсы стараются писать так, чтобы они инимально были привязаны к компилятору. Исключение пожалуй - wxwidgets, который как раз таки будучи собранный другим компилятором даже линкуется, но роняет процесс при запуске. Но это скорее пример, как делать не надо

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

Да, потому что libcdependency-0.1.0-dev уже выкинули из всех дистрибутивов.

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

Если же интерфейс написан на c++ и из него торчит STL, то код, собранный с другими -std даже если и соберётся, то модет не слинковаться.

STL имеет стабильный ABI. (и MS STL, и libc++ и libstdc++)

Так что можно линковаться не просто код с разными стандартами одного компилятора, а с разными стандартами разных версий одного компилятора.

поэтому появляются такие заметки,

https://ztdidk.readthedocs.io/en/latest/benchmarks/bit.html#details

https://cor3ntin.github.io/posts/abi/

и всякие майданутые от этого горят: https://twitter.com/vzverovich/status/1487080205399302152

Но ABI замораживается не сразу. В Visual C++ если ты собираешь код с флагами с конкретными числами: /std:c++14, /std:c++17, /std:c++20, то тогда ты используешь то что уже стабилизированно. /std:c++latest - это самые новые возможности, но у разработчиков ещё есть право что-то поменять и поломать ABI.

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

Вот разработчик gcc это подтверждает: https://www.reddit.com/r/cpp/comments/ubs8fc/comment/i6b3u88/?utm_source=share&utm_medium=web2x&context=1

Наверное поэтому ты думал, что у стандартной библиотеки С++ нестабильный ABI.

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

STL имеет стабильный ABI. (и MS STL, и libc++ и libstdc++)

При всём уважении - Вас серьёзно обманули. Стабильностью там и не пахнет. Скажем так - совместимость ломали, и неоднократно.

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

Вас серьёзно обманули. Стабильностью там и не пахнет. Скажем так - совместимость ломали, и неоднократно.

Тем не менее libstdc++.so.6

GCC 3.4.0: libstdc++.so.6.0.0 (Incompatible with previous)

То есть с версии 3.4.0(April 18, 2004) до сегодняшнего дня мажорную версию не увеличивали.

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

То есть с версии 3.4.0 до сегодняшнего дня мажорную версию не увеличивали.

Это ничего не гарантирует, к сожалению.

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

Теперь авторам zlib придётся новую версию выпускать ещё раз. Причём с кучей дополнительных ifdef-ов т.к. терять совместимость с компиляторами из 80-х они тоже не хотят.

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

То не stl
Несовместимости появляются даже при изменении -std на одном компиляторе, не говоря уже о коде, где стандарт не указан и после обновления компилятора изменился и стандарт.
в чём это прояаляется? У того же std::string появился аллокатор и этот аллокатор всплывает при линковке с кодом другого стандарта.
Появился так же new/delete с дополнительным аргументом

mittorn ★★★★★
()

К сожалению часть предложений была отклонена от включения в С23:

Всё, кроме constexpr - Эталонное нинужно.

Иногда приводящее к необходимости жирного рантайма.

Вместо лямбд предложили бы локальные функции, как в Python (тот же статик, вид сбоку, сильнее ограниченный).

shkolnick-kun ★★★★★
()

K&R Function Declaration AND Definitions are 🪦

И слава Б-гу!

shkolnick-kun ★★★★★
()

И вообще! Даёшь* Тюринг-полный препроцессор!

А то вон как извращаться приходится: https://github.com/Hirrolot/metalang99

Так можно функциональщиком стать в конце концов!

* - нет

shkolnick-kun ★★★★★
()
Последнее исправление: shkolnick-kun (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.