А почему из c11 выкинули complex.h?

Почитатай: https://groups.google.com/g/comp.std.c/c/AoB6LFHcd88

Complex - мало кому нужны.

VLA - дыра и уязвимость + мало кому нужны.

WG14 немного более открытая, чем другие рабочие группы ISO, так что документацию можно найти. Конкретно эти изменения внесены N1443. MISRA C рекомендует не использовать комплексные числа и VLA. Разработчики компиляторов для всякого эмбеддеда хотят чтобы их компиляторы формально соответствовали стандарту, но не хотят реализовывать хлам, который им никогда не понадобится.

Потому что для комплексных чисел есть C++. Пишете на Си? ССЗБ.

Complex - мало кому нужны.

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

VLA - дыра и уязвимость + мало кому нужны.

Про мало кому нужны сильно, сильно не уверен.

Понятно, то есть это «заговор продавцов фитнесс-тренажёров» ☺ Хотя казалось бы для встроенных реализаций свой стандарт есть…

Про мало кому нужны сильно, сильно не уверен.

По моей ссылке:

True. Here are some of the known problems with VLAs:

- Putting arbitrarily large arrays on the stack causes trouble
in multithreaded programs in implementations where stack growth
is bounded.

- There's no way to recover from an out-of-memory condition when
allocating a VLA.

- Microsoft declines to support them.

- VLAs aren't used much. There appear to be only three in
Google Code, and no VLA parameters. The Linux kernel had one,
but it was taken out because there was no way to handle an
out of space condition. (If anyone can find an example of
a VLA parameter in publicly visible production code, please
let me know.)

- The semantics of VLA parameters is painful. They're
automatically reduced to pointers, with the length information
lost. "sizeof" returns the size of a pointer.

- Prototypes of functions with VLA parameters do not have
to exactly match the function definition. This is
incompatible with C++ style linkage and C++ function
overloading, preventing the extension of this feature
into C++.

John Nagle 

Тут перечислены причины почему это «сложно сделать», а не почему это «мало кому нужно» кроме 4 пункта, с которым как бы далее по треду спорят с некоторым количеством примеров.

Причина почему это не широко используется вызвано разнобоем среди компиляторов вида gcc поддерживает, а clang болт забивает, а не тем, что это «мало кому нужно».

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

Вообще-то для этого есть Fortran 77. Ха-ха-ха

Щас сишка из плюсов много тянет, можно глянуть что там в 23 стандарте будет.

Вот пока неполный список того что будет в С23: https://en.cppreference.com/w/c/23

Проблема не в том, что в стандарте, а что имплементируется.

Вот, например, я столкнулся на уроке информатике: один юный питонист написал программу с VLA один в один из примеров стандарта c99 (не специально, в смысле я говорил ранее что так делать не стоит, но он не слушал), а при сборке с помощью clang программа пухла и дохла (с gcc таких проблем нет).

Ну и complex.h это не из плюсов, а из Fortran 77.

Да что угодно кроме копролита Си.

Ну что же тут поделать, когда всё доброе и вечное в качестве основы имеет копролит ибо всё остальное уж очень жидкое по своей субстанции…

Что, шланг не может в 99 стандарт? Надо им накатать тогда.

Оффтоп: что, в ФМШ Паскаль теперь не в моде?

Скорее всего «может C11», где на это можно болт положить.

Мы там поговорили и решили: ну этот Паскаль нафиг…

Да тот же Fortran 77 куда удобнее для работы с комплексными числами, он древнее Си. Си – это историческое недоразумение, наспех сделанная замена ассемблера для UNIX в 1972 году всё ещё используется.

Я посмотрел описание complex.h и не вижу чем оно хуже, чем то, что есть в Fortran 77. IMHO в данном случае наличие лучше, чем отсутствие.

Ну и вы говорите так, как будто портабельная замена ассемблеру это что-то плохое. Как минимум оно хорошо тем, что Ритчи смог продолжить играть на PDP-11 в Астероиды без необходимости писать новую ОС на ассемблере.

Space Travel вроде, классная игра кстати, можно озадачить школьников

Что? Сишники пользуются чем-то кроме ANSI C?

Хорошая идея. Я подумаю, но это в любом случае не ранее следующего полугодия, а там я скорее всего отойду от этих дел.

Это школьники выискивают пути обхода учительских заданий через использование новых стандартов.

Сишники случается используют gcc вообще-то.

Да нет. Они ничего про эти стандарты не знают (в этом конкретном случае точно), просто пишут как им говорили в своё время на Python. То, что оно совпало с примером из C99 не более чем случайность вызванная аналогией.

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

никогда не понадобится

очень громко сказано.

Все правильно сделали.

Аналогично были выкинуты Variable length arrays

туда им и дорога. Нужны динамические массивы - используй malloc/realloc

На самом деле не так, если нужны complex и нормальные динамические массивы, то надо использовать Fortran 95.

Я же не против, мне как раз Fortran95 очень нравился в университете, но где компиляторы под DSP TI или Analog?

Си – это историческое недоразумение, наспех сделанная замена ассемблера для UNIX

А если не наспех, то как нужно было делать?

Очевидно же: всё написать на лиспе!

Очевидно же: всё написать на лиспе!

UNIX на лиспе?

На Паскале например.

Очевидно же: всё написать на лиспе!

Скобочек не хватит.

https://www.lysator.liu.se/c/bwk-on-pascal.html

А почему нет? Emacs же существует. Чем он хуже Unix?

лисп-машинам это не мешало…

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

Покажите Emacs на голом железе. Паскаль/Оберон – запросто.

Это да, но чтобы их изжить коммерческим компиляторам Паскаль потребовалось 10+ лет, а к тому времени C уже заховал весь мир и тоже поменялся.

лисп-машины были задолго до x86

Покажите на них Emacs.

Он там был ажно в 1975 году, что неудивительно, так как эти проекты имеют общие корни.

А почему нет? Emacs же существует. Чем он хуже Unix?

Он не является операционной системой.

На Паскале например.

Язык для обучения студентов, появился в 1970, то есть в самом начале разработки UNIX. По моему тогда там ещё не было указателей. Даже Никлаус Вирт использовал Оберон для написания ОС, но это было гораздо позже.

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

Не даром, до сих пор Fortran существует в современности в том числе и потому, что комплексные числа там из коробки от рождения.

В стародавние времена ещё была изкоробочная реализация XSC Languages (C-XSC, PASCAL-XSC) ©.

или сделать новый, язык простой

Ну так версия K&R языка C была довольно простой. Что действительно становилось источником сложности, так это макросы препроцессора, а в дальнейшем и все эти auto tools. Типичный системный код на C - это заросли всего этого малопонятного мусора, поверх основного не сложного кода. Ну и ещё ограничения памяти и прочие ограничения железа провоцировали прочие нечитабельные конвенции, как например слишком короткие названия переменных, длина строки не больше перфокарты (80 символов) и прочее.

Паскаль, мой первый ЯП, безвозвратно устарел. Одно лишь требование объявлять все переменные в начале выглядит сейчас анахронизмом.

Да ну? Ты уверен?

Нет цели изучать информатику. Есть цель изучать элементы информатики полезные при работе по предметной области. Паскаль в таком разрезе не нужен.