Будущее g++

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

Она не просто грубая — она бессмысленная. У жавы мало компиляторов, но вваленных Sun-ом денег достаточно для того, чтобы жава жила еще несколько десятилети. Васик стар, под него есть много реализаций, но он уже совсем никому не нужен, кроме людей. поддерживающих офисный мусор на VBA. У Go один компилятор, но поддержка гугла гарантирует светлое будущее.

концентрируясь на всяких fortran и прочем говне

вот оно, «поколение Пепси»

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

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

А в C++ компилятор сам выделяет память

Что значит сам выделяет, он что от святого духа через космос получает информацию о том что надо делать делая это через особую магию компилирования и имеет сознание?

коих можно плодить бесконечное множество (по числу классов)

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

Выкидываем ртл получаем сишку. ЧТД

Компилятор не может сгенерировать код без RTL:

https://wiki.freepascal.org/Minimal_RTL

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

TIOBE Very Long Term History

Lang	2020	2015	2010	2005	2000	1995	1990	1985
Java	1	2	1	2	3	-	-	-
C	2	1	2	1	1	2	1	1
Python	3	7	6	6	21	20	-	-
C++	4	3	4	3	2	1	2	10
C#	5	5	5	9	9	-	-	-
JS	6	8	8	10	6	-	-	-
PHP	7	6	3	5	22	-	-	-
SQL	8	-	-	-	-	-	-	-
Swift	9	17	-	-	-	-	-	-
Ruby	10	11	10	24	30	-	-	-
Lisp	27	24	16	14	8	6	4	2
Fortran	31	28	23	15	16	4	3	5
Ada	33	29	24	17	14	5	6	3
Pascal	243	16	14	35	12	3	10	6

И делать проверки покрытия мне нужно руками

о мой кот. если ты заранее знаешь какого типа аргументы функции, то зачем городить огород? определяешь типы и канпелятор волшебным образом сообщит тебе где ты не прав. если же ты жаждешь полиморфизЪма - тогда через void* и проверку предусловия (соответствие типов).

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

сюрприиииз!

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

причем это про любой ЯП.

А по мере роста проекта это становится делать сложнее и сложнее.

жизнь боль

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

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

Названия функций встреоны? Встроены. Параметры функций встроены? Встроены. Вон, у C++ конструкторы самые разные можно задавать. А причина такой организации простая — выделение и высобождение данных в куче зависит от реализации динамической памяти, которая может быть разной. Можно было бы наружу высунуть только GetMem, ResizeMem, FreeMem, но высунули немного другие функции. И на то есть причина. например, WideString в винде выделяется функциями библиотеки ActiveX.

А в C++ компилятор сам выделяет память

Что значит сам выделяет, он что от святого духа через космос получает информацию о том что надо делать делая это через особую магию компилирования и имеет сознание?

Нет, он это делает в стэке или в подсунутом ему объекте. Паскаль динамическую память выделяет, как правило, в куче.

а в паскале ой ли нельзя наплодить такое же бесконечное множество вариантов, о чем вообще разговор?

В паскале конструктор и деструктор один, а вариантивность реализуется через RTTI.

определяешь типы и канпелятор волшебным образом сообщит тебе где ты не прав

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

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

Я хочу напомнить, с чего мы начинали: Си провоцирует написание необнаруживаемых ошибок. Это так? Так. Хоть как организовывай разработку, систему типов, а в итоге все равно будет написана ошибка и не замечена. И это характерная черта именно Си, это не «любой ЯП». В паскаль эту заразу занесли только авторы Free Pascal, ее там не было. Я про указатели, которые вездесущи в Си, и ошибки с ними неуловимы.

С подобный, а точнее фон-нейман подобный

Brainfuck. Лучший язык для любого проекта.

учитывая то, что g++ без шланга неполноценен

…для отдельно взятого анона, мнение которого очень важно для g++.

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

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

а про «канпелятор волшебным образом» вот тут https://godbolt.org/z/6rYEKP

Си провоцирует написание необнаруживаемых ошибок. Это так? Так. Хоть как организовывай разработку, систему типов, а в итоге все равно будет написана ошибка и не замечена. И это характерная черта именно Си, это не «любой ЯП».

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

У жавы мало компиляторов, но вваленных Sun-ом денег достаточно для того, чтобы жава жила еще несколько десятилети.

Что касается Java, то было бы справедливо писать Java + C#. Соответственно, и писать лучше сразу на C#, так как Microsoft не только вкладывал деньги в C#, но и продолжает вкладывать.

Васик стар, под него есть много реализаций, но он уже совсем никому не нужен

Это устаревшая информация. На Бейсике для .Net можно написать всё то же, что и на C#. Более того, Linq, например, более полно реализован для Бейсика. На TIOBE рейтинг Бейсика за последние годы резко вырос.

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

Поддержка корпораций ничего не гарантирует. Это могут подтвердить Borland Software Corporation, Adobe Inc и даже Microsoft Corporation (Internet Explorer).

Методика груба по другим причинам. В источнике, откуда я брал информацию, компилятором C# посчитали SharpDevelop. Скорее всего там есть другие ляпы. Кроме того, надо учитывать насколько компилятор устарел, а также его назначение. Например, SDCC вполне популярный компилятор C, но с его помощью нет смысла создавать приложения для ПК.

Названия функций встреоны? Встроены. Параметры функций встроены? Встроены. Вон, у C++ конструкторы самые разные можно задавать. А причина такой организации простая — выделение и высобождение данных в куче зависит от реализации динамической памяти, которая может быть разной. Можно было бы наружу высунуть только GetMem, ResizeMem, FreeMem, но высунули немного другие функции. И на то есть причина. например, WideString в винде выделяется функциями библиотеки ActiveX.

Так это вы говорите что там что-то встроено, а на самом деле там просто есть glue код для перехода от компилятора к pтл, встроенного там ничего нет. Если бы функционал pтл был вшит в сам язык, а не как либа сбоку, тогда о какой-то встройке можно было говорить.

По поводу выделения памяти это абсолютно та же самая ерунда и в паскале где вы там принципиальную разницу видите, показывайте код freepascal где там разница принципиальна. Там та же шляпа только в профиль тот же мемори менеджер, те же реализаци по типу malloc free в виде гет и фри мема, так же есть более высокоуровневая нашлепка в виде new и dispose как некий аналог new delete. Всякое МС-барахло всегда было специфичным и к языкам не имеет никакого отношения.

Нет, он это делает в стэке или в подсунутом ему объекте. Паскаль динамическую память выделяет, как правило, в куче.

В стеке он это сделает для определенных встроенных типов или типов на основе встроенных типов как было в примере с bounded array. А паскалек да, он настолько убогий что почти все делает через прибитый соплями ртл на динамической памяти, не могу назвать это каким-то существенным отличием или преимуществом.

В паскале конструктор и деструктор один, а вариантивность реализуется через RTTI.

Ну так о чем речь тут вообще нет никакого особо преимущества ну загнали паскалеписак в загон ограничений, как это мешает тому чтобы писать на С в таком же стиле и организовать себе такой же загон, rtti организуется и в с и в с++ есть уже, да вам не нравится система типов потому что там действительно вся система это примитивные типы стековые да указатели, ну и плюс всякие структуры, перечисления, объединения все это есть имеет свой аналог и в паскале, все что сложнее это попытка абстрагироваться от этого ну делают они это через вариант, как будто 50 лет назад тагед юниона не существовало.

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

Да, я видел эту таблицу (TIOBE Very Long Term History). Мой рейтинг лучше тем, что в нём языки для суровых мужиков (С, C++, Fortran и Scheme) далеко впереди всех остальных.

там было про то, как проверку типов сделать бесплатной для релиза, оставив ее только для дебага ( и тестов).
а про «канпелятор волшебным образом» вот тут https://godbolt.org/z/6rYEKP

Ты лукавишь, и я подозреваю, что вполне целенаправленно. В твоем примере все данные статичны. А мы о чем совсем недавно говорили? Про динамику. Гарантия корректности работы с динамическими данными во время компиляции. Си полностью отказался от любой возможности подобной проверки, таким образом застряв где-то в 1970-1975 году, где не было нужды даже в паскалевых динамически выделяемых ячейках-ссылках. Да-да, это неочевидный факт, но Си не умеет сам по себе передавать данные динамического размера — для этого нужно костылить с обоих сторон канала передачи дополнительный уровень абстракции руками. И именно поэтому в лине есть ограничение на размер имени файла — потому что буферы до сих пор фиксированы в размере.

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

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

Что касается Java, то было бы справедливо писать Java + C#. Соответственно, и писать лучше сразу на C#, так как Microsoft не только вкладывал деньги в C#, но и продолжает вкладывать

C# изначально полностью был слизан с жавы, но их пути разошлись, они занимают непересекающиеся ниши.

Гугл также поддерживает жаву, а Microsoft как раз не вкладывает в шарп деньги, а только поддерживает его на плаву. Microsoft, как и тот же Amazon, нынче перешел в онлайн сервисы, вроде облака, SaaS, сбора личных данных через все возможные каналы.

Это устаревшая информация. На Бейсике для .Net можно написать всё то же, что и на C#. Более того, Linq, например, более полно реализован для Бейсика. На TIOBE рейтинг Бейсика за последние годы резко вырос

https://www.cnews.ru/news/top/2020-03-13_zakat_epohi_visual_basic_microsoft
«Язык Visual Basic больше не будет получать новые функции, его свежие версии перестанут выходить. Его поддержка будет сохранена в .NET 5.0, дальнейшая поддержка не гарантируется. По мнению экспертов, Visual Basic проиграл конкуренцию языку C#»

Поддержка корпораций ничего не гарантирует. Это могут подтвердить Borland Software Corporation, Adobe Inc и даже Microsoft Corporation (Internet Explorer)

Ну и почему ты приводишь проприетарщину на фоне опенсорсного Go? Вон, Docker Inc. загнулся, и чо?

Если бы функционал pтл был вшит в сам язык, а не как либа сбоку, тогда о какой-то встройке можно было говорить

По-твоему, проверка области видимости, оборачивание в try..except, генерация RTTI, полиморфичный проброс простых имен функций (SetLength, Copy, Delete) в нужный тип — это ничего?

Ну так о чем речь тут вообще нет никакого особо преимущества ну загнали паскалеписак в загон ограничений, как это мешает тому чтобы писать на С в таком же стиле и организовать себе такой же загон, rtti организуется и в с и в с++ есть уже

В С++ RTTI есть, в Си нету. По крайней мере в компиляторе. В Си ты даже не можешь в макросах получить инфу о типе.

да вам не нравится система типов потому что там действительно вся система это примитивные типы стековые да указатели

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

А именованные смещения умел делать даже асм, как я уже писал ранее, так что эт оуже больше 50 лет.

А я еще с самого начала сказал что никого не агитирую писать на С, я лишь говорю что внутри любого языка все тоже самое

Где «любой язык» — это Free Pascal последних версий.

https://www.cnews.ru/news/top/2020-03-13_zakat_epohi_visual_basic_microsoft

Статья интересная. Спасибо. Полез искать источник. Нашёл тут: https://devblogs.microsoft.com/vbteam/visual-basic-support-planned-for-net-5-0/

Говорится следующее:

Future features of .NET Core that require language changes may not be supported in Visual Basic. … If you are happy with .NET Framework, you can be confident that it will remain supported as long as Windows is supported because it is shipped with the OS.

Ну да, при написании ПО под Linux могут быть проблемы. Но вроде бы Windows пока помирать не собирается. Так что это не конец, просто Бейсик не приобретёт ту кроссплатформенность, которую уже получает C#.

А если и совсем похоронят, то это только подтвердит методику выбора языка по количеству компиляторов.

C# изначально полностью был слизан с жавы, но их пути разошлись, они занимают непересекающиеся ниши.

Судя по всему, скоро их ниши пересекутся. Enterprise решения на Java обычно используют Linux-серверы. Microsoft же многие годы пытался навязывать свои сервера. На что получал ответ «Да, C# интереснее Java, но ваши сервера нас не радуют». Теперь Microsoft изменил тактику. Они создали .NET Core именно для того, чтобы перейти на Linux-сервера. Так что C# полез в нишу Java, и, думаю, ей будет непросто. Если у Microsoft получится потеснить Java в её нише, то вслед за C# и Бейсик может переползти.

Ну и почему ты приводишь проприетарщину на фоне опенсорсного Go?

Потому что разговор был не про открытые исходники, а про поддержку корпораций. Если говорить конкретно про Go, то у него тоже не один компилятор. Есть уже и gcc-шный: https://gcc.gnu.org/onlinedocs/gccgo/

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

Гарантия корректности работы с динамическими данными во время компиляции

во время компиляции ты хочешь контролировать размер данных, которые выделяются в рантайме, динамически, размер которых заранее неизвестен ? )

чота я устал догадываться что ты имеешь в виду. Talk is cheap. Show me the code.(c) чего конкретно ты хочешь сделать и что у тебя не получается.

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

java memory leak example

ну и заодно можешь рассказать о том, как вся эта ботва легко и просто выявляется «на этапе компиляции»(с)

Если у Microsoft получится потеснить Java в её нише, то вслед за C# и Бейсик может переползти

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

Потому что разговор был не про открытые исходники, а про поддержку корпораций

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

во время компиляции ты хочешь контролировать размер данных, которые выделяются в рантайме, динамически, размер которых заранее неизвестен ?

При чем тут конкретно размер? Я разве писал про размер? Я писал про то, чтобы корректно выделять и высвобождать память. Ты засунул строку в 10 символов в переменную, передал ее параметром в другую функцию, после выполнения этой функции строка стала 15 символов, мы прочитали ее значение и освободили память. Инструменты паскаля и C++ позволяют гарантировать безопасность этих операций вне зависимости от сложности производимого перевыделения памяти. То есть, это алгоритмы. которые были один раз написаны и повторно используются, экономя труд программиста. Си не позволяет делать этого и заставляет каждый раз выполнять проверки вручную, что, естественно, весьма трудоемко для сложных случаев, а для компилятора это миллисекунда работы.

procedure ReplaceSomething(var Somestr: String; Somearg: Integer);
var
  s: String;
begin
  s := 'a: ' + InToStr(Somearg) + ';';
  // или
  s := Format('a: %d;', [Somearg]);
  Somestr := StringReplace(Somestr, s, 'found it!',
                          [rfReplaceAll, rfIgnoreCase]);
end;

Как бы я не сочетал функции работы со строками — я не получу ошибок. В результате я могу заниматься построением логики работы приложения. В более поздних паскалях возникла конструкция «for C in AString do», которая позволяет еще и безопасно проходить по строке не парясь о том, что я прочитаю символ за пределами строки.

Это же относится к Variant, интерфейсам, динамическим массивам, и локальным переменным-структурам, содержащим эти структуры.

java memory leak example
ну и заодно можешь рассказать о том, как вся эта ботва легко и просто выявляется «на этапе компиляции»

Варианты «оставить переменную связанную с глобальным обЪектом» есть вполне корректная работа с памятью. Реально проблемной и бажной является реализация ThreadLocal, которая через хитрые ссылки продолжает жить вечно даже после окончания работы потока. Этот единственный баг все равно не является причиной повреждения памяти в других алгоритмах.

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

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

Инструменты паскаля и C++ позволяют гарантировать безопасность этих операций вне зависимости от сложности производимого перевыделения памяти. То есть, это алгоритмы. которые были один раз написаны и повторно используются, экономя труд программиста. Си не позволяет делать этого и заставляет каждый раз выполнять проверки вручную,

Вы опять забываете что весь этот функционал это часть ртл что С++ что Pascal, кто же вам мешает пользоваться написанным подобием для С берите любую библиотеку и пользуйтесь. Уже же 10 раз сказано что без своих ртл частей строго как язык, что с++, что pascal подозрительно похожи на С, разве что второй по дизайну очень опирается на перечисляемые загоны и вариан и без ртл превращается в то, что хаял Керниган пол века назад, на чем невозможно писать не испытывая боль.

Когда есть открытые исходники, то есть возможность в любой момент создать альтернативный проект

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

Зачем устаревший язык в новой нише с новыми костылями

Можно конкретные примеры, показывающие, что VB.Net устаревший? Примеры костылей? Если CType костыль, то чем он хуже какого-нибудь static_cast?

Ещё одно соображение на тему «устаревший». Ещё недавно разрабатывали «новейший» язык Nemerle. Толпа фанатов на RSDN была от него в большем восторге, чем многие теперь от Rust. Ну и где теперь этот «новейший»? Так что «новейшесть» и «старейшесть» на мой рейтинг не влияют. Важна живучесть.

Чудненько. Ждем больше таких стандартов.

Кстати, на тему стандартов и совместимости.

Вот что узнал(как раз Herb Sutter рассказывает, которого ты линковал из комитета):

Текущие строки С++(со small string optimization) были приняты в драфт стандарта с 2008 года, вошли в стандарт С++11 2011 года, но первый компилятор, который стал поддерживать такие строки это g++ 5.1 - 2015 года. Жесть.

https://imgur.com/a/kkFv0qG

Так что изменения ломающие ABI не любит комитет, потому что разработчики компиляторов будут игнорить такой стандарт…

С другой стороны, вот многие хотят менять ABI в плюсах, так как помешаны на скорости: https://cor3ntin.github.io/posts/abi/

Так что в комитете быть не так просто…

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

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

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

DOSBox-а нет, что ли?

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

Я не знаю, может ты не читаешь что я пишу — но я отвечал, что проблемы, действительно, были, и проблемы устранялись. Статья Кернигана наполовину составлена из «изобретено не нами», и наполовину обличает реально существовавшие проблемы, некоторые из которых были весьма острыми, вроде ввода-вывода.

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

тип перечисления приносил пользу, он приносил и вред

Ну... и в итоге все равно в Си есть «enum». Потому что это абсолютно положительная фича и нет никакого оправдания для того, чтобы ее не иметь.

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

Представь себе, то же самое было в Си и еще в целой куче языков и ОС-ей. Потому что в 70-е годы ничего лучше ассемблера создать не смогли — это было время депрессии в экономике. Вот очухались в 80-е, и началось «ой, а что у нас есть. Давайте развивать» — а ничего толком и нету. И давай Ada делать, C++, Object C, Object Pascal, и прочие мене известные.

Ассемблер вообще примитивная ерунда и не яп высокого уровня в отличии от С хоть он максимально к нему и приближен

Я не знаю, ты прочитаешь когда-нибудь доки к Midas и перестанешь писать ерунду про «ассемблер вообще примитивная ерунда и не яп высокого уровня» — или же не судьба. Те же макросы, те же выражения, те же строки, те же функции, те же доступы по указателям со смещением — в асме того времени было всё то же самое, что в Си. Не было только переносимости — всё, это вообще весь смысл создания Си. Си — это попытка обощить инструкции асма, обернуть инструкции доступа к указателям по смещениям в платформонезависимые смещения. Не в последнюю очередь поэтому были приняты нуль-терминированные строки — для них не нужно знать размера символа, транслятор Си-в-Асм проще таким образом писать.

Вы опять забываете что весь этот функционал это часть ртл что С++ что Pascal, кто же вам мешает пользоваться написанным подобием для С берите любую библиотеку и пользуйтесь

Я же уже отвечал выше, и даже с примерами. Подобную библиотеку для Си невозможно написать, потому что язык не позволяет дать даже близкие гарантии безопасности кода. Есть много проектов языкеов, которые безопасны и транслируются в Си, из которых самый известный — Cfront.

Можно конкретные примеры, показывающие, что VB.Net устаревший? Примеры костылей? Если CType костыль, то чем он хуже какого-нибудь static_cast?

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

Ещё недавно разрабатывали «новейший» язык Nemerle

Ничего не знаю про Nemerle, но F# имеет довольно значимаую нишу, пусть и не такую обширную, как C# или Java.

Текущие строки С++(со small string optimization) были приняты в драфт стандарта с 2008 года, вошли в стандарт С++11 2011 года, но первый компилятор, который стал поддерживать такие строки это g++ 5.1 - 2015 года. Жесть

Да, запрет COW — это рак, и его пытались побороть фактическим бойкотом, но в итоге поехавшие вахтеры из GCC протащили стандарт, как протаскивали strict aliasing. Потому что иначе получается, что половина компиляторов работает так, а половина — иначе. А GCC — это довольно солидный игрок. В итоге в том же QString copy-on-write инкуда не делся, и этими строками по возможности пользуются более охотно.

К слову, в паскале встроенные строки являются copy-on-write:

test.327: s1 := 'asdasd';
000000000615EBD4 488D0D8D919100   lea rcx,[rel $0091918d]
000000000615EBDB 488D15DA110000   lea rdx,[rel $000011da]
000000000615EBE2 E8495C2BFA       call @UStrAsg
test.dpr.328: s2 := s1;
000000000615EBE7 488D0D82919100   lea rcx,[rel $00919182]
000000000615EBEE 488B1573919100   mov rdx,[rel $00919173]
000000000615EBF5 E8365C2BFA       call @UStrAsg
test.dpr.329: s2[3] := 'a';
000000000615EBFA 488D0D6F919100   lea rcx,[rel $0091916f]
000000000615EC01 E83A5F2BFA       call @UniqueStringU
000000000615EC06 66C740046100     mov word ptr [rax+$04],$0061

Это как бы внезапный плюс встроенности строк, которой нету в расширяемом C++.

Так что изменения ломающие ABI не любит комитет, потому что разработчики компиляторов будут игнорить такой стандарт…
С другой стороны, вот многие хотят менять ABI в плюсах, так как помешаны на скорости: https://cor3ntin.github.io/posts/abi/
Так что в комитете быть не так просто…

Embarcadero сломало ABI, но получило рост популярности — и где твой бог теперь? Просто, комитет — это такое болото, которое не сможет ни одно смелое решение утвердить, каким бы полезным оно не было. Они примут лучшее из худших решений, но никогда не примут по-настоящему хорошее решение. Я уверен, что стороны, которым выгодно сохранение ABI, можно пересчитать по пальцам — что-то типа гугла. Но есть огромное число игроков, которые при изменении ABI в крайнем случае обойдутся минимальными правками — да какие поехавшие вообще что-то базируют на ABI крестов, когда весь язык построен на макросах?

Сам язык собственных фичей не приобретает

Как шутил Александреску в своей книге про D: «На самом деле большинство языков обязаны своим стилем Lisp’у, просто некоторые не хотят этого признавать.» А в моём рейтинге диалект Лиспа впереди Бейсика. Если сложить диалекты Лиспа, то он даже войдёт в тройку лидеров.

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

F# имеет довольно значимаю нишу

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

Блин

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

учитывая то, что что g++ без шланга неполноценен.

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

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

Что же будет дальше? Видимо появятся пользователи, жалующиеся на то что почему существуют и пилятся какие-то другие проекты, потому что появилась нейросеть которая транслирует в код идею которую диктует ей «программист» :)

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

Как шутил Александреску в своей книге про D: «На самом деле большинство языков обязаны своим стилем Lisp’у, просто некоторые не хотят этого признавать

Не было там такого. Lisp был самым старым, и далеко не самым лучшим. Даже фичу лиспа «код=данные» довольно тяжело признать как успешную, потому что операции над кодом во время выполнения хоронят производительность, из-за чего та же Clojure полностью отказалась от макросов в рантайме — там макросы вычисляются только при компиляции кода.

Если сложить диалекты Лиспа, то он даже войдёт в тройку лидеров

Знаешь, я когда смотрю на сайт Hacker News, который написан на диалекте лиспа Arc, и я чот не вижу супер-пупер преимуществ лиспа, а из всех production-ready диалектов можно назвать разве что Clojure, и фсё. Есть какой-нибудь F#, но это уже чисто статический язык, без характерной лисповой динамики, потому является наследником ML, а никак не лиспа — эти два древних протоязыка разошлись еще в 1973 году и более не пересекались. Так что даже у Васика пожирнее наследие будет, потому что он недавно был мейнстримом и до сих пор поддерживается гигантом.

Но я этого делать не стал, чтобы у тебя была возможность рассказать о главной особенности Бейсика: невозможности «выстрелить себе в ногу»

Это общее свойство .NET, а не Васика. Как раз старые диалекты были очень опасны.

Гарантии заканчиваются на указателях, если они есть - гарантий нет

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

Embarcadero сломало ABI, но получило рост популярности — и где твой бог теперь?

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

комитетчики исходят из позиции, что нет нужды тянуть в язык то, что реализуется как библиотека, qt справилось, в чем проблема?

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

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

Про раст, время жизни и мутабельность сделали синтаксическим сахаром, а точнее квалификаторы для работы с ними, борроучекер засунули как часть языка, но если честно я не смотрел как конкретно он туда засунут учитывая что это фронт для llvm, засунут он туда явно не сильно глубоко.

Да, потому в паскале, C++, Rust предпочитают использовать ссылки вместо указателей.

так ссылки это и есть огороженные указатели

в большинстве случаев в зависимости от того чего вы желаете, достаточно

U bar (const T* const foo) и можно и без ссылок обойтись.

Я же совсем недавно приводил пример динамических строк паскаля.

Динамические строки паскаля на проверку оказались сишкой под пудрой, такие же реализуются на С.

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

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

U bar (const T* const foo) и можно и без ссылок обойтись.

Писанины больше. Надо писать много const, писать & перед аргументами и обращаться через ->.

Динамические строки паскаля на проверку оказались сишкой под пудрой, такие же реализуются на С.

В чистом Си принципиально нельзя нормально реализовать строки хотя бы потому, что там нет RAII. Есть __attribute__((cleanup (cleanup_function))), но это не часть стандарта. При ручном удалении высока вероятность забыть его написать и получить утечку памяти.

как минимум ещё добавить:

__attribute__((nonnull))
U bar (const T* const foo) 

тогда при Wall будет ругаться на такое:

bar(NULL);

warning: null argument where non-null required (argument 1) [-Wnonnull]

   line_num |     bar(NULL);
            |             ^

__attribute__((nonnull))

Тоже нестандартное GCC расширение.

В чистом Си принципиально нельзя нормально реализовать строки хотя бы потому, что там нет RAII

RAII в С:

почти в точности соотвествует тому как происходит работа с ресурсами в C# c using, или в python c with и в других языках без деструкторов…

#define USING(a, b, c)  \
     for (bool _flag = true; _flag; _flag = false) \
     for (a; _flag && (b); c, _flag = false)

int fun(size_t m) 
{
    int result = -1;
    USING(int* f1 = (int*)malloc(sizeof(*f1)), (NULL != f1), free(f1)) 
    {
       // делаем работу, и сохраняем результат
    } // ресурс освобождается, вызывается free.
    return result;
}

Тоже нестандартное GCC расширение.

добавляем ifdef и код компилируется везде

#ifndef __GNUC__
#define __attribute__(a, ...)
#endif

нам важно лишь что компилятор проверяет немного во время компиляции.

Выше по всем претензиям к С уже в принципе ответили… Писанины да больше получается, и да ANSI С такой себе, GNU реализация конечно лучше и только на ней можно что-то приличное писать. Ну может еще у МС есть какие-то нестандартные расширения, но по сути МС всегда делали в первую очередь компилятор С++, а не С, С там в нагрузку.

Не понимаю зачем извращаться, если можно использовать C++.

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

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

Не понимаю зачем извращаться, если можно использовать C++.

Я и пишу на С++, это так просто.

Да, в реальности выбирать С вместо С++ смысла нет.

В теории есть платформы где есть С, но нет С++. Например, не под все платформы которые поддерживают эти два компилятора, есть С++ компилятор:

http://sdcc.sourceforge.net/

https://cc65.github.io/

В теории есть платформы где есть С, но нет С++. Например, не под все платформы которые поддерживают эти два компилятора, есть С++ компилятор:

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