Будущее g++

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

??? За базар ответишь?

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

type
  CharArray = array [0..MaxShort] of AnsiChar;
  PCharArray = ^CharArray;
var
  s: PAnsiChar;
  s2: PAnsiChar;
  p: Pointer;
  p2: Pointer;
  d: array of AnsiChar;
  d2: array of AnsiChar;
  a: PCharArray;
  a2: PCharArray;
begin
  GetMem(s, 14 * sizeof(Char));
  s2 := s + 2; // Ok
  GetMem(p, 14 * sizeof(Char));
  p2 := p + 2; // E2015 Operator not applicable to this operand type
  SetLength(d, 14);
  d2 := d + 2; // E2008 Incompatible types
  GetMem(a, 14 * sizeof(Char));
  a2 := a^ + 2; // E2010 Incompatible types: 'PCharArray' and 'PAnsiChar'
  a2 := a + 2; // E2015 Operator not applicable to this operand type
  a2 := @a[2]; // Ok
  a2 := @a[2] + 2; // E2015 Operator not applicable to this operand type

Я особое внимание уделил «array [0..MaxShort] of AnsiChar», потому что именно так работали с указателями в древнем паскале, именно этот тип хорошо защищен от ошибок. Арифметика с указателями — это довольно недавнее нововведение, в Turbo Pascal этого еще не было, и даже в седьмом Delphi единственный тип, с которым возможна эта арифметика — это PChar, который здесь называется PAnsiChar. То есть, даже с PByte нельзя было заниматься арифметикой.

Конечно же это не соответствует действительности, это не константы, и в таком виде это как раз то, как работает препроцессор

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

И константы введены в язык именно для того, чтобы делать данные константными, а уж от реализации зависит будут ли они константными только на этапе компиляции, или же будут таковыми и на этапе исполнения в ро загоне ОС

И ты хочешь сказать, что констант в Си не было? Строковые и массивные константы были в асме MACRO-10, 3-1 в руководстве:

https://www.livingcomputers.org/UI/UserDocs/Tops-10-v7-04/4_Macro_Assembler_R...

Они же фактически были в Си в виде «копипастим значение в каждом выражении», пример с массивом есть в K&R «The C Programming Language» за 1978 год на 109 странице.

Так что отмазы «какие-то машины что-то не поддерживали» не засчитана, та или иная форма константности была везде — K&R просто поленились добавлять поддержку нормальных констант в язык, потому тот Си в отдельных моментах не дорос даже до хорошо спроектированных асмов того времени.

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

А тебе не приходит в голову, что классы и шаблоны C++ — это совершенно иной дизайн, не имеющий ничего общего со старыми структурами языка Си? Это и был изначально полностью изолированный транслятор, примерно как Cython. И что, теперь будем говорить, что Cython = C?

Хорошо, если тебе не нравится так — покажи мне проверку long на попадание в рамки 2^32 на любой платформе, в том числе той, где long 64 бита

Очевидно, что вы просто тратите мое время, сходите на godbolt.org да сами проверьте на тех вариантах платформ и ос что там предоставлены (я проверил на 5 случайных с разной ос и разной разрядностью, везде вы получаете ворнинг), на любой требовать вы не можете, потому что на любой и ваш паскаль не работает. Т.е. по сути эту претензию тоже отбили

ARM gcc 9.2.1

<source>:1:10: warning: overflow in conversion from 'long long int' to 'long int' changes value from '17592186044415' to '-1' [-Woverflow]

    1 | long a = 0xFFFFFFFFFFF;

AVR gcc 9.2.0

<source>:1:10: warning: overflow in conversion from 'long long int' to 'long int' changes value from '17592186044415' to '-1' [-Woverflow]

    1 | long a = 0xFFFFFFFFFFF;

x86-64 clang 10.0.0

Compiler returned: 0

x86-64 gcc 10.1

Compiler returned: 0

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

https://github.com/antirez/sds - динамические строки с проверкой границ массива. никто не мешает реализовать и свое что-нибудь эдакое. код прост как прикроватная тумбочка. чистый С

sds s = sdsnew("Hello World!");
s++;

и ты по уши в дерьме. Мне нужно объяснять что ссылка на внутренний элемент строки — это вообще весь смысл существования «char *», который «typedef char *sds»?

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

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

Поэтому в норм языках проверка для статических типов данных делается во время компиляции.

s++ и ты по уши в дерьме.

а еще ножом можно ухо отрезать, и будешь как Винсент ван Гог. ну, почти.

Си заставляет кодера делать ошибки

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

Я особое внимание уделил «array [0..MaxShort] of AnsiChar», потому что именно так работали с указателями в древнем паскале, именно этот тип хорошо защищен от ошибок. Арифметика с указателями — это довольно недавнее нововведение, в Turbo Pascal этого еще не было, и даже в седьмом Delphi единственный тип, с которым возможна эта арифметика — это PChar, который здесь называется PAnsiChar. То есть, даже с PByte нельзя было заниматься арифметикой.

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

Даже если ваш код просто скопировать дописав нужный контекст и просто запустить половина ошибок которые вы откуда-то нашли не воспроизводятся на FPC который есть у меня. Со всем ворохом директив компилятора. Так что рассказывайте где вы его писали и как проверяли. Вторая половина это следствие банального тайп мисмача, и того факта что напрямую оператор арифметики не определен на любые «алиасы» которые вы раздаете в type (наверное это называется в рамках паскаля как-то иначе, но мне лень искать какова правильная терминология для этого) и к возможности вертеть указателями и заползать за границы массива прямо как в С, ниже будет мой корявенький код (потому что это паскаль против шерсти, и я не пишу на паскале, наверное весь вывод и заполнение массива можно было сделать красивше) того как легко это обойти.

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

В общем-то варианты безопасного написания K&R кода были тогда, а сейчас и подавно при желании С можно сделать достаточно безопасным.

Ну и возвращаясь к вашей претензии, вы привели различные примеры того, что можно сделать (при том половина из них вообще мимо кассы беседы, достаточно было всего ^variable указателя, его разыменования variable^ и оператора или функции взятия адреса addr(variable) или @variable, а Pointer по сути что-то типа аналога void*, дальше вы начали вообще заниматься тайп мисмачем, и откровенными попытками применить адресную арифметику к вещам которые ничего о ней не знают, это сродни попыткам обращаться к не существующим методам объекта или требовать работу определенного оператора не перегружая его), но по сути претензии вашей же просто проскипали пример кода, где это?

«getdata(cell+2)» вместо «getdata(cell)+2» — и привет, ты даже в рантайме скорее всего не получишь ошибку сразу.

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

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

// FPC 3.0.4, x86_64

program Project1;

{$mode objfpc}{$H+}{$T+}{$R+}{$S+}{$D+}{$WARNINGS ON}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes;

type
  originalArrayOfAnsiChar = array[Low(Byte) .. High(Byte)] of AnsiChar;
  originalPArrayOfAnsiChar = ^originalArrayOfAnsiChar;

var
  ArrayOfAnsiChar : array[Low(Byte) .. High(Byte)] of AnsiChar;
  pArrayOfAnsiChar : PAnsiChar;
  opArrayOfAnsiChar : originalPArrayOfAnsiChar;
  p{, p2} : Pointer;
  ChrVal : AnsiChar;

begin

 // without type declration

  for ChrVal := Chr(low(ArrayOfAnsiChar))
      to Chr(High(ArrayOfAnsiChar))
         do
             ArrayOfAnsiChar[Ord(ChrVal)] := ChrVal;
             Write(ChrVal);

  Write(#10);

  pArrayOfAnsiChar:= PAnsiChar(ArrayOfAnsiChar);

  p := @ArrayOfAnsiChar;

  WriteLn('Static array, PAnsiChar test: ' + #10 + (pArrayOfAnsiChar + 48));

  WriteLn('Static array, "Pointer" test: ' + #10 +  PAnsiChar(p + 58));

  WriteLn('Static array, PAnsiChar test overflow: '
                  + #10 + (pArrayOfAnsiChar + 258));

  WriteLn('Static array, "Pointer" test overflow: '
                  + #10 +  PAnsiChar(p + 512));

  WriteLn('$$$$$$$$$$$$$$$$$$$$$$ ORIGINAL SAMPLE $$$$$$$$$$$$$$$$$$$$$$$$$$$$');

  GetMem(opArrayOfAnsiChar, 255 * SizeOf(AnsiChar));

    for ChrVal := Chr(low(originalArrayOfAnsiChar))
      to Chr(High(originalArrayOfAnsiChar))
         do
             opArrayOfAnsiChar^[Ord(ChrVal)] := ChrVal;
             Write(ChrVal);

  Write(#10);

  {
  // You code work without error
  GetMem(p, 14 * sizeof(Char));
  p2 := p + 256; // E2015 Operator not applicable to this operand type
  }

  WriteLn('Dynamic array, opArrayOfAnsiChar test: '
                  + #10 + (opArrayOfAnsiChar^ + 65));

  p := opArrayOfAnsiChar;
  //p := p - 150; // IDE SEGMENTATION_FAULT :)
  p := p + 75;

  {
   Need casting because operator '+' not overloaded
   for "AnsiString" + "untyped"
  }
  WriteLn('Dynamic array, opArrayOfAnsiChar2Pointer test: '
                  + #10 + originalPArrayOfAnsiChar(p)^);

  // the same overflow will occur, code ommited


end.

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

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

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

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

«копипастим значение в каждом выражении»

Этот подход я вам и описал выше и мне даже надо было смотреть что там в букварях по K&R написано, достаточно просто было логически поразмышлять, удивительно то, что вы сами решиться не можете были ли в K&R константы или нет. Некоторым количеством сообщений назад вы твердо утверждали что константности там не было и быть не могло, теперь нарыли немножко информации в старых фолиантах и теперь меня же пытаетесь вопрошать по поводу ваших слов, тут я вынужден задаваться вопросами, а вы точно не спорите просто ради споров и зачем вы по сути спорите сами с собой?

Так что отмазы «какие-то машины что-то не поддерживали» не засчитана, та или иная форма константности была везде — K&R просто поленились добавлять поддержку нормальных констант в язык, потому тот Си в отдельных моментах не дорос даже до хорошо спроектированных асмов того времени.

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

Еще раз повторю вы сравниваете несравнимое, ассемблер не универсален, он не язык по большому счету даже, это просто представление машинных команд в тексте + макротня в каких-то ассемблерах которые хоть как-то пытаются сделать работу на них удобной. Дам процентов 90% что никакого внутреннего представления у программы переводящей ассемблерные листинги того времени не было, это был почти чистый перегон в машкоды по мнемоникам, о каком языке вы говорите, о каких преимуществах ассемблера как «языка».

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

А тебе не приходит в голову, что классы и шаблоны C++ — это совершенно иной дизайн, не имеющий ничего общего со старыми структурами языка Си? Это и был изначально полностью изолированный транслятор, примерно как Cython. И что, теперь будем говорить, что Cython = C?

Замените классы на ADT. Ну и по поводу классов, в том виде что они есть в С++ там половину можно выкинуть (да и ооп вообще спорный подход до некоторой степени) т.к. этот функционал только мешает программировать и создает больше проблем чем решений, а учитывая что С++ сам убогий и хромой костыль над С это проблемы на стероидах. Кстати ничего другого там нет, есть искусственно созданный и введенный механизм уровня компиляции и втейбл уровня рантайма, которая наша монаршая особо хейтит пуще чем вы сишку. И это ООП еще и обходится как делать нечего, никаких классов в рантайме нет. Но вы это все должны и так сами знать.

Конечно будем, Питон никак не базируется на синтаксисе и семантике С, а С++ это нашлепка на С, на этом разговор можно закончить относительно Питона.

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

Так если бы это аргументы были, а не претензии с вашей стороны, к тому же необоснованные и да, вас все еще не устраивает качество предупреждений от компилятора? Кстати если вы посмотрите код который я скинул вы увидите что я просто обошел все возможные дикективы паскаля и там ни одного ворнинга или иррора не сыпет. А вот -Wall -pedantic -Werror попробуйте так просто обскакать.

Строки, проверки на переполнение - это всё мелочи. Сейчас будет шах и мат. С помощью стандартной библиотеки Turbo Pascal 7 можно было нарисовать эллипс с заданными параметрами. А в C++? Ну хотя бы круг? Квадрат? Ну хотя бы линию? Ну хорошо, хорошо, понятно с графикой. Проиграть звук с заданной частотой? Задать цвет фона в консоли? Цвет шрифта в консоли? Что, в C++ нет даже отдельной функции для очистки экрана в консоли?

Понятно, что есть Qt, SDL, ncurses и т.д. Но эти батарейки не включены.

Кстати если вы посмотрите код который я скинул вы увидите что я просто обошел все возможные дикективы паскаля и там ни одного ворнинга или иррора не сыпет.

Эта да, но valgrind это отлавливает…

https://pastebin.com/WsKnnGBs

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

батарейки как киллерфича, ну… у всех свои ориентиры добра и зла )

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

В любом случае, не ясно что мешает хотя бы ncurses включить в стандартную библиотеку.

а еще ножом можно ухо отрезать, и будешь как Винсент ван Гог. ну, почти

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

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

Ну, так а за чем дело стало? Тебе нужно исходные текста древнего паскаля — скачай текста древнего паскаля и убедись, чего ты мне пишешь так, будто это я всё спрятал и не показываю?

http://tpdn.ru/files/turbo-pascal-download/

Например, к первому паскалю предлагается простая реализация электронной таблицы (spreadsheet) чуть больше тысячи строк, которая выполнена без единого указателя (нет «@» или «New» в коде), поскольку оперирует фиксированным размером таблицы 7х21. Вместо указателей для работы применялись комбинации ссылка-индекс, где ссылка является безопасной формой указателя, поскольку сам указатель скрыт компилятором.

А если тебя вдруг беспокоит ограничение размера данных из-за фиксированных буферов, то предлагаю вспомнить, почему в линуксе в 2020 году есть ограничение в 255 символов на имя файла, и что в начале 80-х годов объем памяти на целевых устройствах измерялся едиинцами и десятками килобайт.

Даже если ваш код просто скопировать дописав нужный контекст и просто запустить половина ошибок которые вы откуда-то нашли не воспроизводятся на FPC который есть у меня. Со всем ворохом директив компилятора

program first;

type
  CharArray = array [0..High(Smallint)] of AnsiChar;
  PCharArray = ^CharArray;
var
  s: PAnsiChar;
  s2: PAnsiChar;
  p: Pointer;
  p2: Pointer;
  d: array of AnsiChar;
  d2: array of AnsiChar;
  a: PCharArray;
  a2: PCharArray;
begin
  GetMem(s, 14 * sizeof(Char));
  s2 := s + 2;
  GetMem(p, 14 * sizeof(Char));
  p2 := p + 2;
  SetLength(d, 14);
  d2 := d + 2;
  GetMem(a, 14 * sizeof(Char));
  a2 := a^ + 2;
  a2 := a + 2;
  a2 := @a[2];
  a2 := @a[2] + 2;
end.

$ fpc first.pas
Free Pascal Compiler version 3.0.4 [2020/07/09] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: FreeBSD for x86-64
Compiling first.pas
first.pas(21,11) Error: Operator is not overloaded: "{Dynamic} Array Of Char" + "ShortInt"
first.pas(23,12) Error: Incompatible types: got "^Char" expected "PCharArray"
first.pas(26,15) Warning: Arithmetic "+" on untyped pointer is unportable to {$T+}, suggest typecast
first.pas(27,4) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/local/bin/ppcx64 returned an error exitcode

Компиляция в предыдущем моем сообщения была сделана борландовским компилятором под оффтопом:
https://www.google.com/search?q=E2015 Operator not applicable to this operand...
Ей богу, такое ощущение, будто тебя в гугле забанили.

Всего того же самого вы добиваетесь в С просто используя квалификатор const, которого в старом С естественно нет

Нельзя:

#include <stdio.h>

int main()
{
	int i = 2;
	const int * const pntr = &i;
	printf("%d\n", *(pntr+1));
}

$ clang pointer.c && ./a.out
-5264
$ clang --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

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

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

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

Не понял фразы.

«getdata(cell+2)» вместо «getdata(cell)+2» — и привет, ты даже в рантайме скорее всего не получишь ошибку сразу.

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

Современный FPC с указателями, действительно, допускает некоторые вольности, которые лично я не одобряю, особенно с нетипизированными указателями. Turbo Pascal и Delphi беспечной работы с указателями не прощают. Разрабы FPC вполне прямо ссылаются на то, что скопировали это поведение с Си — это не паскалевый стиль.

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

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

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

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

Наверное, я тебя огорчу, но первый Си был транслятором в ассемблер:

https://github.com/mortdeus/legacy-cc/blob/master/prestruct/c02.c

printf(".globl	%p\n", cs);
...
if ((type&030)==020) {		/* a function */
	printf(".text\n%p:\nmov r5,-(sp); mov sp,r5\n", cs);
...
printf(".comm	%p,%o\n", &defsym[4], nel*width);
...
if (width==4) {
	sf = fcval;
	printf("%o;%o\n", sf);
	break;
}
if (width==8) {
	printf("%o;%o;%o;%o\n", fcval);
	break;
}

Я подозреваю, что K&R вообще не думали о том, чтобы заменить асм на Си — скорее они использовали его как транслятор выражений в асемблерный код, из-за чего они и прибегли к максимально приближенным к асму интерфейсам. Многие высокоуровневые языки гнули асм под себя, для них создавали специальные асмовые функции, которые оперировали структурами данных этого языка — в Си ситуация складывалась ровно наоборот. То есть, Си — это не язык для системного программирования, это язык для программирования на ассемблере. Вроде библиотеки-кодгенератора. А ассемблер уже, в свою очередь, был для системного программирования. Вот это и есть настоящий смысл фразы «переносимый ассемблер».

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

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

Этот подход я вам и описал выше и мне даже надо было смотреть что там в букварях по K&R написано, достаточно просто было логически поразмышлять, удивительно то, что вы сами решиться не можете были ли в K&R константы или нет. Некоторым количеством сообщений назад вы твердо утверждали что константности там не было и быть не могло, теперь нарыли немножко информации в старых фолиантах и теперь меня же пытаетесь вопрошать по поводу ваших слов, тут я вынужден задаваться вопросами, а вы точно не спорите просто ради споров и зачем вы по сути спорите сами с собой?

Я советую рассматривать мою позицию в контексте обсуждения препроцессора и конкретных языков, поскольку у понятия «константа» может быть больше чем одна интерпретация. Например, выражение «2+2», которое, очевидно, вычисляется в «4», может быть именованной константой в паскале или современном си. В Си K&R мы получаем:

#include <stdio.h>
#define SOME_CONST 2+2

int main()
{
	printf("%d\n", SOME_CONST);
	printf("%d\n", SOME_CONST*2);
	printf("%d\n", (SOME_CONST)*2);
	return 0;
}

$ clang macro.c && ./a.out
4
6
8

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

В мидасе были и макросы-выражения с подстановкой заменой текста, и именованные константы, которые безо всяких выражений. К слову, последние были и в PL/M. В Си можно записать макрос-выражение с константой, но нельзя записать просто константу.

К чести Midas-а, разрабы этого языка предсмотрели проблему подстановки текста макроса при помощи специальных ключевых слов начала и завершения макроса — K&R на этом фоне еще раз демонстрируют хроническую неспособность принимать архитектурные решения. Особенно остро проблема стоит в языке, где есть типы данных, поскольку этот макрос не позволяет учесть разницы при работе с разными типами (например, я применяю один и тот же макрос к строке и числу). Это еще один указатель на то, что в Си не должно было быть типов, им там нет места. И еще копеечка в копилку хронического отсутствия архитектуры. Как и в случае с PHP, когда чел просто хотел сделать себе домашнюю страничку, он вообще не собирался делать никакой язык, а недоязык внезапно подхватили. Находчивость K&R здесь заключается разве что в том, что они не признались, а подхватили волну и сказали «мы обосрались, но это был точно расчитанный серок на десятилетия вперед».

Еще раз повторю вы сравниваете несравнимое, ассемблер не универсален, он не язык по большому счету даже, это просто представление машинных команд в тексте + макротня в каких-то ассемблерах которые хоть как-то пытаются сделать работу на них удобной. Дам процентов 90% что никакого внутреннего представления у программы переводящей ассемблерные листинги того времени не было, это был почти чистый перегон в машкоды по мнемоникам, о каком языке вы говорите, о каких преимуществах ассемблера как «языка»

Ага, мне кажется, что ты просто не в курсе, какие мощные тогда были ассемблеры - там «чистого перегона» не больше, чем в Си:
http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/01/info/midas.info.html — искать страницу по заголовку «MIDAS Macros».
Midas по фичам весьма близок к Си, но у него есть очевидный и хорошо нам известный недостаток — это отсутствие переносимости. По крайней мере простой. Да, тот же MS-DOS на чистом асме переносили между платформами, поскольку целевые платформы были очень близкими, но во времена K&R так легко было не отделаться. То есть, по фичам Си не опережал ассемблер, и единственным реальным прорывом была кроссплатформенность. Таким образом на тот момент это был транслятор кроссплатформенных выражений в ассемблер целевой машины (как я уже писал выше). Со временем метапрограммирование из ассемблера полностью перекочевало в Си, с тех пор прошло уже много лет, и люди уже совсем забыли, какими мощными были ассемблеры. Так что на этом фоне заявление

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

выглядит как минимум самоуверенно.

Замените классы на ADT

И каким макаром ты собрался работать с ADT в Си, где нет возможности специализировать макросы? Я настаиваю на включение в достижения C++ не только и не столько классов, сколько шаблонов и перегрузки операторов, которым нет аналогов в Си.

Питон никак не базируется на синтаксисе и семантике С

Надо Гвидо рассказать, а то он не в курсе и считает, что создавал свой язык в том числе на базе Си:
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.2023

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

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

Меня не устраивает, что проверка типов в Си выполнена в стиле «отстаньте от нас уже», и это уже до гроба, это никогда не будет исправлено. Да, люди пытаются хоть как-то проверять корректность работы с числами, но язык просто не дает достаточно ограничений, чтобы проверки можно было эффективно выполнять, а не через раз, как сейчас. Результат не заставил себя ждать — это тренд отказа от Си во всех сферах, где требуется хоть какая-то надежность выполнения.

С помощью стандартной библиотеки Turbo Pascal 7 можно было нарисовать эллипс с заданными параметрами. А в C++? Ну хотя бы круг? Квадрат?

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

в том что как оказалось паскаль такая же сишка

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

по факту это кажется последняя контора которая серьезно разрабатывает решения на паскале

Кажется:
https://en.wikipedia.org/wiki/Oxygene_(programming_language)
http://www.modernpascal.com/

В GNUC макросы почти шаблоны на минималках:

https://gcc.gnu.org/onlinedocs/cpp/Duplication-of-Side-Effects.html#Duplication-of-Side-Effects

Просто пользуйся GNUC макросами, typeof и compound statement это потрясающие возможности.

для перегрузки есть _Generic

Ещё этим _Generic можно бороться с неявными преобразованиями типов.

https://gcc.godbolt.org/z/bor5dh

Просто не ошибайся, и всё будет хорошо.

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

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

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

Просто пользуйся GNUC макросами, typeof и compound statement это потрясающие возможности
для перегрузки есть _Generic
Ещё этим _Generic можно бороться с неявными преобразованиями типов

Да, это шаги к тому направлению, которого очень не хватало. Проблема в том, что форма результата настолько отвратительна, что встает вопрос «чем это лучше копипасты функций с разными типами?». Мы наслоили целый ряд изначально чуждого Си синтаксиса-семантики — так любят делать крестовики, и я так понимаю, что GCC пошел по тому же пути. Ну то есть не «мы будем делать новые макросы, которые лишены недостатков старых, оставляя старые подыхать в режиме совместимости», а «мы добавим compound statement, чтобы попытаться подпереть костылем проблемы существующих макросов». Это делали и через блоки с «do {} while(0)», и через вызовы функций — а макросы остаются всё таким же убогим и чуждым компилятору языком.

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

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

Даже не так, давай начнем с азов: как ты сможешь гарантировать, что sdsfree не будет вызвана дважды/не будет вызвана для тухлого указателя? Конечно, вопрос риторический — ты никак не сможешь этого гарантировать, ты просто будешь получать эти ошибки в разных количествах в зависимости от размера проекта и квалификации кодеров. Более насущный вопрос: как ты собрался отлаживать эти проблемы? Да, valgrind словит самые простые и хорошо воспроизводимые ошибки — и оставит более сложные. Тестирование позволяет определить наличие ошибок, но не позволяет определить их отсутствия.

К слову, про

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

как раз эта ошибка будет очень легко выявлена valgrind при первом же проходе по этой функции.

Есть system()!

Как ты можешь гарантировать, что никто нигде

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

int int_value_preconditions_check(int *value_ptr, int value){
    // check any preconditions
}
...
int value;
int error = int_value_preconditions_check(&value, 301);
handle_error(error);
... 

не хочется чтобы к value был прямой доступ? спрячь его, для получения значения назначь getter, пусть он возвращает const

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

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

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

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

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

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

Хорошо пишешь, чертяка, и даже аргументация на высшем уровне... Прям мои мысли, которые не могу выразить в эпистолярном жанре...

Предлагаю собрать все рассуждения по поводу убогости C в одну статью и опубликовать её где-нибудь на просторах Инета, буду давать на неё ссылку молодым некорепшим умом студентам :)

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

Надо смотреть шире. Для микроконтроллеров типа 8051 или PIC, а может и более продвинутых не имеют смысла операции работы с файлами, работа с консолью. Даже выделять память в куче не рекомендуют. Значит ли это, что все вышеперечисленные вещи должны быть убраны из стандартной библиотеки C или C++?

Ок, мы договорились, что паскаль был полноценным инструментом для создания прикладных программ, а си - некий абстрактный, ни к чему не привязанный язык, так? Тогда зачем си и си++ стандартные библиотеки (в том числе и для работы со «строками»), и по какому принципу они делаются? Например, потоки есть и в Qt, и в wxWidgets, и даже в SDL. Зачем надо было вводить потоки в стандартную библиотеку C++? Все разработчики на Qt теперь перешли на стандартные потоки? Кроме того, в Qt и в wxWidgets есть свои строки и другие контейнеры. Зачем вообще создали stl?

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

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

Единственная стоящая контора это эмбаркадеро как приемник борланда.

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

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

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

В С++23 будет и Audio и Video и всё что угодно:

Вот можешь демки посмотреть:

https://www.youtube.com/watch?v=jNSiZqSQis4

https://www.youtube.com/watch?v=7Jk1a4cnukQ

Кстати, паскалисты не используют graph, и на форуме fpc говорят, ты что с дуба рухнул, используй сишный SDL2, в fpc к нему биндинги есть…

Писал на Паскале и радовался. Перешёл на C и стал плеваться... Да даже Фортран удобнее! (с прикладной точки зрения :)

А насчёт аргументации: вполне резонно написано. Я тоже без слёз не могу смотреть на макросы в C... И развлекалово с #include'ами та ещё катавасия, особенно когда они вложенные и самопересекающиеся...

Предлагаю собрать все рассуждения по поводу убогости C в одну статью и опубликовать её где-нибудь на просторах Инета

Уже сделали - www.linux.org.ru/forum/development/

Таких тонн простыней нытья от неосиляторов нигде в инете больше нет - я гарантирую это.

Это не нытьё, это правда жизни... (посмотрел на ник) но тебе этого не понять, LamerOk :)

В С++23 будет и Audio и Video и всё что угодно

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

Кстати, паскалисты не используют graph

Да это понятно. Я пытаюсь донести следующую мысль: паскаль в эпоху Dos был хорошей игрушкой. Си же используется для каких-то скучных низкоуровневых дел. Поэтому подсознание заставляет искать недостатки в си, и не замечать недостатки паскаля. Какие могут быть доводы в пользу си когда игрушку отняли обманом? Сказали, бери игрушку которая круче, а ты только потом осознал, что это не игрушка совсем…

Вообще, «игрушки» постоянно отнимают. Вначале паскаль, потом ActionScript… Выживет ли SDL?

Но это вроде бы только «proposals»

Да. Но я думаю добавят…

Как ты можешь гарантировать, что никто нигде в тысячах блоков вызовов sdsnew/sdsfree не изменит указатель на строку?

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

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

хочется, чтобы И быстро И со всеми мыслимыми гарантиями. каждое решение имеет свою цену, увы, увы

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

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

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

электрон все ругают, однако ирония в том, что это в основе своей быстросишное поделие, просто обернутое желаемым количеством удобств и гарантий

Это кресты, а не Си, с интенсивным использованием классов, безопасных строк, стандартных контейнеров.

Предлагаю собрать все рассуждения по поводу убогости C в одну статью и опубликовать её где-нибудь на просторах Инета, буду давать на неё ссылку молодым некорепшим умом студентам

Зачем мне это? Я несобираюсь становиться каким-то гуру, профессиональным утешителем бездарных индусов, потому мне выгоднее, чтобы остальная отрасль шла по тупиковому пути и не составляла мне конкуренцию. Пусть читают Бакаева, Александреску, Мартина, и пребывают в иллюзии, что они научились писать код.

Ок, мы договорились, что паскаль был полноценным инструментом для создания прикладных программ, а си - некий абстрактный, ни к чему не привязанный язык, так? Тогда зачем си и си++ стандартные библиотеки (в том числе и для работы со «строками»), и по какому принципу они делаются?

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

Зачем надо было вводить потоки в стандартную библиотеку C++? Все разработчики на Qt теперь перешли на стандартные потоки?

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

Кроме того, в Qt и в wxWidgets есть свои строки и другие контейнеры. Зачем вообще создали stl?

Разница не так уж и велика в этом случае. Из основных можно выделить лучшую кроссплатформенность и лучшую поддержку COW у Qt, а STL будет побыстрее. Стоит понимать, что STL каждый вендор реализует по своему, так что могут быть сюрпризы, которых нет в Qt.

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

Если ты не будешь интересоваться ничем, кроме того, что тебе настойчиво суют под нос, то да, для тебя большая часть вещей в мире попадет в категорию «почти никому не известны». Oxygen — это язык, который через минимальные прокладки позволяет работать либо со старым VCL дельфей, либо с готовыми либами Java/CLR — в последнем случае у тебя открываются неограниченные возможности. По стилю Oxygen, конечно, ближе к JVM/CLR, чем к нативному коду — это именно та самая исходная кроссплатформенность, которая была в первых реализация паскаля.

Ну ради споров с вами я точно не буду накатывать куда-то дос чтобы проверить как дела в очередном клоне турбопаскаля который все еще клон, а не оригинал

Проверять ты не хочешь, и верить мне тоже не хочешь. Замечательно.

Я как бы тоже никому не советую писать на С и уж тем более прикладуху, на которую вы ориентируетесь

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

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

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

В С++23 будет и Audio и Video и всё что угодно

Они еще C++20 не приняли, а ты уже про 23 мечтаешь. Я не знаю про звук, но в графике есть как минимум два сильно отличающихся способа рисования — это процессором и видеокартой. Может быть для десктопа и подойдет SDL, но чо делать для микроконтроллера, в которой нет никакого ускорителя графики? Даже софтовой эмуляции нет.

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

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

В С++23 будет и Audio и Video и всё что угодно:

Зачем это в стандарте? Стандартная библиотеку уже и так помойка с кучей сомнительного функционала вместо которого обычно используются сторонние библиотеки. Они бы ещё операционную систему в стандартную библиотеку включили. Надеюсь они хотя бы это в отдельный *.so модуль добавят.

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

Они еще C++20 не приняли, а ты уже про 23 мечтаешь.

С++20 давно принят, о чём ты?

https://habr.com/ru/company/yandex/blog/488588/

Зачем это в стандарте?

В комитете целая отдельная подгруппа есть SG13:

https://isocpp.org/std/the-committee

SG13, HMI & I/O (Human/Machine Interface): Roger Orr (BSI). Selected low-level output (e.g., graphics, audio) and input (e.g., keyboard, pointing) I/O primitives.

Вот и занимаются…

С++20 давно принят, о чём ты?
https://habr.com/ru/company/yandex/blog/488588/

Чот тут от силы половина фич, которые я видел в C++20. Например, где модули?

В эпоху DOS Си был такой же игрушкой … сам MS-DOS … в 1983 переписали на Си…

Что-то в этом абзаце не так.

Эпоха Dos начала заканчиваться, когда появился DirectX (1995 г.) и окончательно завершилась с приходом Windows 2000 (2000 г.). То есть у си было время с начала 80-х до 2000 чтобы захватить нишу системного ПО. В то время как у паскаля оставалась ниша прикладного ПО.

Вернёмся к этому сообщению: Будущее g++ (комментарий)

Беда случилась где-то в конце 90-х, поскольку еще в 1995 году паскаль был там, где сейчас питон и Си. Что случилось между 1995 и 2000 — ума не приложу.

А теперь посмотрите на даты создания DirectX и Windows 2000.

Даёт ли это инструменты для прогнозирования, для ответа на вопрос автора темы? Какие факты мы имеем сейчас?

1. Введено регулярное обновление и усложнение C++ (было раз в ~10 лет, теперь 3 года), Java (было раз в 2 года, теперь 2 раза в год). В связи с этим я спрашивал о необходимости введения потоков в STL.
2. Зачем-то добавился новый компилятор C++.
3. В Python внедряются особенности, противоречащие прежней идеологии.
4. Похоронен Flash. Взамен ему предлагают WASM.
5. C# c Unity уже уверенно сидит в нише разработки игр. То есть там, где до недавнего времени у C++ была монополия.

Язык Си дает изначально крайне опасные методы работы с данными

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

C++ и паскаль могут дать 100% гарантию того, что при работе со строками стандартными методами ты никогда не получишь ошибку работы с памятью.

const char *result = std::string("some"+ "thing" + "something else").c_str();

сдуру, знаешь ли, можно и хер сломать. (превед s++)

возможности железа, как правило, сильно превышают возможности програмистов по утилизации этого железа.

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

const char *result = std::string(«some»+ «thing» + «something else»).c_str();

сдуру, знаешь ли, можно и хер сломать. (превед s++)

я не знаю, что демонстрирует данный код, но он тупо не соберётся

Фичи тут: https://en.cppreference.com/w/cpp/compiler_support

Там новость и фоточка. В следующий раз когда соберётся комитет, они будут обсуждать С++23.

https://isocpp.org/files/img/wg21-1990-2020.png

#include<string>

int main() {
  const char *result = std::string("something").c_str();
  return 0;
}

g++ test.cpp -o test
./test

наслаждайся

наслаждайся

#include<string>

int main() {
  const char *result = std::string("something").c_str();
  printf("%s\n", result);
  return 0;
}

saha@saha-swift ~ $ g++ -Wall test.cpp 
saha@saha-swift ~ $ ./a.out 
something
saha@saha-swift ~ $ g++ --version
g++ (Gentoo 9.2.0-r2 p3) 9.2.0

P.S. Я понимаю, что указатель стал невалидным, но пример не очень показательный. Отстрелить себя ногу можно и более изощрёнными способами :)

ну молодец

а теперь подумай что с этим «безопасным» кодом не так

Я понимаю, что указатель стал невалидным, но пример не очень показательный. Отстрелить себя ногу можно и более изощрёнными способами :)

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