Программируете ли вы на Паскале?

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

То, что ОС оказалась на Си - отдельная тема. В случае с UNIX тут скорее «Си оказался языком, который сделали для ОС». В случае с виндой - с большой долей случайность, с маленькой - наверно были какие-то преимущества, но не такие уж значительные.

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

Я на Си с Паскаля когда-то давно перешёл потому, что под виндой Паскаля тупо не было

Да ладно! Ваш покорный начинал именно с Паскаля, именно под виндой, за давностью лет уж и не вспомню - вроде как это был либо Borland TP 5 or 6, где-то там…

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

ЧО?!?!?! Ну ладно Delphi

Но даже 7-й Borland Pascal был в двух инкарнациях искаропки - под DOS и под 3.х венду. Причем, версия под DOS включала в себя весь стафф для ОО, в том числе Turbo Vision.

Понятно, что проги, написанные под 3.х венду отлично работали и на последующих версиях, прежде всего на Windows 95

Это буквально шаг назад по сравнению с Algol 60 (в котором, в отличие от паскаля, область видимости переменных была).

Ну почему же ересь, как im клиент psi совсем неплох. А если его ещё и на шинах рекламируют, то это что-то да значит!

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

Разве что BP7. И он делал 16-битные проги. 32-битное началось с Delphi, но, как я уже выше писал, это было не то. WINAPI написано на Си, и необходимость, кроме самого WINAPI, работать ещё и с прослойками C-Pascal (и только с теми, которые реализованы авторами компиляторной библиотеки) совершенно не хотелось.

Нафиг мне твоя 3.х винда, речь была про новую платформу - 32-битный защищённый режим в нативном виде. Просто винда оказалось первым что я из 32-битного увидел. Собственно с Линуксом та же история - все библиотеки поставляются с нативными .h для Си, а если нужно их использовать из Паскаля - либо надеяться, что авторы fpc к ним уже сделали адаптеры, либо костылить эти прослойки самостоятельно.

Алгол это в основном теоретический язык, не надо сравнивать.

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

Причём тут однопроходная компиляция?

Скоп в Паскале и есть процедура. Процедуры могут быть вложенными. А объявления в середине кода замусоривают его и не нужны. Это даже сейчас заметно, а уж на 80х25 экранах того времени - проблема намного острее.

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

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

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

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

Я в одной из тем уже приводил пример вида:

#include <stdio.h>

void main(void){
{
 int a = 1;
}
float a = 5.6;
printf(«Переменная a = %f»,a); ///выдаст 5.6

printf(«Переменная a = %d»,a); ///выдаст 1
}

Как запустить этот пример что бы все работало?

В школе начинал с турбопаса, потом пару лет писал мелкие студенческие поделки на седьмом делфи. В целом остались приятные воспоминания. Думаю, по удобству формошлепания делфи образца 2002 года до сих пор дерет в жёппу Qt Widgets, ну а про MFC лучше вообще промолчать.

Еще из приятных фич запомнились неплохо приготовленные модули, которых в крестах толком еще нет, несмотря на то, что C++20 уже четыре года стукнуло. Еще помню более продвинутую объектную систему с интерфейсами, ссылками на классы и виртуальными конструкторами, чего в крестах не было и не предвидится.

Сейчас бы я на паскале ничего писать не стал. Не вижу у него какой-то уникальной ниши, где бы он рулил и педалил. Везде уже есть более современные и удобные альтернативы. Есть стойкое ощущение, что паскаль застрял в прошлом и сливает современным ЯП по фичам. Как в FPC обстоят дела с управлением памятью? До сих пор надо пердолиться с ручными Create/Free? Рефлексия и аннотации/атрибуты? Асинхронщина и корутины?

хотя конечно индексация массивов с 1 это лютый зашквар.

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

program m;
type months=(January,February,March,April,May,June,July,August,September,October,November,December);
var  month: months;
     message: array[months] of string;
begin
 for month:=January to December do
  begin
   case month of 
    March..May: message[month]:='Весна!';
    June..August: message[month]:='Лето!';
    September..November: message[month]:='Осень...';
    else message[month]:='Нет повода не выпить.'
   end;
   writeln(message[month])
  end
end.

program vars;
uses Variants;
var V: variant;
begin
V:=VarArrayCreate([-3,9],varVariant);
V[-3]:=true;
V[0]:='Ура!';
V[9]:=0;
writeln(V[-3]);writeln(V[0]);writeln(V[9])
end.

по удобству формошлепания

Layouts? Alignment? Anchoring? Relative positioning? Что нибудь там было, или как дедушки лепили по сетке

Layouts? Alignment? Anchoring? Relative positioning? Что нибудь там было, или как дедушки лепили по сетке

Были и alignment и anchoring. Это позволяло легко верстать резиновые интерфейсы, чтобы при изменении размеров контейнера дочерние компоненты автоматически растягивались/сжимались или привязывались к любым его сторонам.

Лейаутов в седьмом делфи не припомню, но и без них все прекрасно клепалось. Когда позже перешел на культи, то от Qt Designer блевал дальше чем видел. Особенно когда надо было что-то поменять в сложной форме с кучей вложенных лейаутов, где порой приходилось тыкать Break Layout и всю эту дрисню с нуля переделывать. Не зря многие знакомые разработчики отказывались от Qt Designer и пилили интерфейсы полностью в крестокоде. В делфи такого даже близко не было. Формы любой сложности отлично рефакторились без пиксель хантинга и доделывания интерфейса в коде.

Ну а фишка делфи, когда можно перетащить на форму какой-нибудь TАDOTаblе, подключить его к БД и сразу видеть содержимое таблицы прямо на форме, и вовсе кажется какой-то невероятной космической технологией для культей.

/tmp$ gcc a.c 
a.cpp:3:1: error: ‘::main’ must return ‘int’
    3 | void main(void){
      | ^~~~
a.cpp: In function ‘int main()’:
a.cpp:10:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘double’ [-Wformat=]
   10 |  printf("Переменная a = %d",a); ///выдаст 1
      |                         ~^  ~
      |                          |  |
      |                          |  double
      |                          int
      |                         %f

ок, фиксим void main –> int main и добавляем \n в конец вывода:

$ ./a.out 
Переменная a = 5.600000
Переменная a = 1213461152

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

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

Надо же… видать много поменялось за 30 лет.

#include <stdio.h>

int main(void){
  {
    int a = 1;
    printf("Переменная a = %d\n",a); ///выдаст 1
  }
  {
    float a = 5.6;
    printf("Переменная a = %f\n",a); ///выдаст 5.6
  }
  {
    const char *a = "c not easy!";
    printf("Переменная a = %s\n",a); 
  }
}

видимо как то так. Да, и правда - если все переменные в коде называть одинаково разобраться будет трудно… ;-)

Оговорюсь, что я не программист, а инженер АСУТП. В универе нас учили Делфям. Соответственно, когда надо было что-то быстро накодить для «нормального» компа, а не ПЛК, я брал Lazarus и не парился. Работало.

Сейчас задач как-то таких нет особо. Панельки китайские, которые я использую, вообще на C скриптуются, соответственно, я уже больше кода на нём написал, чем на Паскале. Под ПЛК я пишу на языках IEC 61131-3, в основном – на FBD/LD и ST. Правда, у нас в промавтоматике каждый вендор считает своим долгом сколхозить свой диалект, в котором всё через жопу, а не как в стандарте.

Кстати, пользуясь случаем, поною. Жалующиеся на begin-end вместо скобочек. Каково вам притащенное из долбаного VB в ST требование заканчивать каждый оператор своим особым end? END_IF, END_FOR, END_CASE :)

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

Каково вам притащенное из долбаного VB в ST требование заканчивать каждый оператор своим особым end? END_IF, END_FOR, END_CASE :)

Ну местных ты этим особо не удивишь :) В баше еще более забористая наркомания: if … fi, for … done, case … esac.

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

Язык объективно мертв, и в своей единственной области применения (образовании) тоже не особенно нужен, потому что 1) есть языки более живые 2) образовантельная программа с игрушечными языками построена в корне неправильно.

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

Но индексация с любого значения, да, array[-5..5] of char;

Не for ... done а do ... done. Но да, всё равно выбивается из остального стиля.

От такого -Wshadow -Werror спасает, использую везде.

Turbo Paslac + Turbo Vision во время учебы в университете. Delphi появился в университете, потом простые БД на нем на работе.

А потом, как мальчик Бобби из «Острова сокровищ», связался с Solaris, и покатился…

Достаточно было обернуть подобное объявление в фигурные скобки

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

несколько фреймворков для написания GUI

Я тока лазаревый знаю. Поделись, плиз

Два прохода и так и так не нужно делать. Я вообще не знаю зачем их придумали, скорее всего это легаси от каких-то фортранов из 60-х годов.

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

Про стекфреймы можно тоже объяснить (никакого «нового» там не нужно), но в свете сказанного выше эти детали совершенно несущественны.

Причём тут контекст и стекфреймы

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

Это гарантированно работает всегда

Это вообще не работает

#include <stdio.h>

int main () {
  int x = 1;

  printf("%d\n", x);

  { int y = 2; }

  printf("%d\n", y);
}

test.c: In function ‘main’:
test.c:10:18: error: ‘y’ undeclared (first use in this function)
   10 |   printf("%d\n", y);
      |                  ^

При том что блок это новый фрейм

Нет. Это только в учебных теориях так.

Переменные из блока существуют только внутри блока.

Переменная из объявления в середине блока существует только в хвосте блока, а не во всём. Соответственно

вставить машкод для резервирования

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

Это вообще не работает

Что за несёшь? Зачем сломанный код мне пихаешь? При обнаружении объявления - ставим скобку и увеличиваем счётчик. При обнаружении конца блока - ставим все накопленные закрывающие.

#include <stdio.h>

int main () {
  int x = 1;

  printf("%d\n", x);

  { int y = 2;

  printf("%d\n", y); }
}

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

Хуже того (для твоей ложной теории), компиляторы всегда поддерживали код вида

int x = 10;
int a = f(x);
int b;

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

родились строки:

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

Это только в учебных теориях так

Это в любом древнем компиляторе так.

кодогенерация начиналась до того, как компилятор просмотрит все объявления

Нет, на размер фрейма вызов функции не влияет. Компилятор может захардкодить размер до вызова.

При обнаружении конца блока - ставим все накопленные закрывающие.

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

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

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

типа

void fun(int fx) {
  int x;
  { //первый блок
    int y,z;
  }
  { //второй блок
    int y;
  }
}

тут самый длинный фрейм - x,y,z. вот такой фрейм и будет создан при входе в функцию. и никакой ерунды с расширением фрейма при входе в блок не надо. и выходе тоже.

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

Зачем два прохода? Достаточно хранить при чтении функции одну структуру фрейма, и корректировать ее при появлении новых переменных. Потом вставить нужное количество для резерва в начале функции.

Для goto все равно придется что то хранить наперед.

Как можно так упрямо не видеть очевидных вещей?

Код в инициализаторе объявления на «размер фрейма» (в кавычках, потому что это твоя выдумка в данном случае) не влияет, а отдельный код вдруг стал влиять, да? И как он его захардкодит до вызова, а вдруг там на следующей строке объявление длинного массива который не влезает в твой хардкод? Это так не делается.

Во-первых придётся следить за контекстом, сколько блоков навставляли

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

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

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

Кстати да, заполнить одно число в уже сгенерённом коде после просмотра всей функции - это не второй проход, так что даже доп. инструкций можно избежать.

Зачем два прохода

Затем что тебе нужно выдавать машкод как можно скорее, в идеале построчно.

Достаточно хранить при чтении функции одну структуру фрейма

Хранить где?

Потом вставить нужное количество для резерва в начале функции

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

как он его захардкодит до вызова

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

А за синтаксической корректностью проги компилятор не следит?

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

Какая разница?

Херасе. Целых несколько байт на ровном месте.

Почему не сделали то

Потому что машины тех лет такое тянули с трудом. Делать так означало значительно ограничить доступность языка на разных машинах.

самый длинный фрейм функции с учетом деклараций во внутренних блоках, и генерит его на входе в функцию

Это сейчас так. Раньше все было гораздо примитивнее.

в однопроходном компиляторе апдейтятся

1. размер фрейма функции, если он заранее неизвестен.
2. goto вперед
3. переходы в булевских выражениях, поскольку там тоже джампы вперед.

си вроде однопроходен.

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

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

Причём тут тип результата? Хватит уже чушь за чушью нести.

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

Ещё раз повторяю вопрос - программу типа такой

main() {{{{{

Херасе. Целых несколько байт на ровном месте.

Это дело программиста, если он хочет тратить.

Потому что машины тех лет такое тянули с трудом.

Какое такое то? Запомнить сколько скобок открыто? Не неси чушь.

Только в школе на уроках информатики в самом начале 90-х. С тех пор забыл, как страшный сон.

Зачем два прохода

Затем что тебе нужно выдавать машкод как можно скорее, в идеале построчно.

И зачем для этого два прохода?

Хранить где?

В оперативной памяти. Там же где хранится goto, для этого нужно выделить ровно одну переменную.

Это значить генерировать код в отдельный буфер.

Все равно придется, см goto. Но это только для тел функций. Закончилась функция, буфер можно освободить.

Причём тут тип результата? Хватит уже чушь за чушью нести.

Для размера фрейма больше ничего знать не нужно. Хватит уже тупить.

древний Си-компилятор скомпилирует? Без отмазок и общих слов - только да или нет.

Да. И что?

Это дело программиста, если он хочет тратить.

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

Какое такое то?

Компиляцию в два прохода. Или эквивалентное этому компиляцию во внутренний буфер. Запоминать при компиляции всё равно что-то нужно, но смысл в том, чтобы делать это как можно меньше.

goto вперед

Для этого не надо много запоминать. По месту такого goto можно компилять как косвенный переход.

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

И зачем для этого два прохода?

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

Достаточно хранить при чтении функции одну структуру фрейма, и корректировать ее при появлении новых переменных

У тебя результат компиляции пишется на ленту. Пролог ты как потом собрался впихнуть? Придётся компилять во внутренний буфер, а это дорого. Если есть место под буфер можно тупо прочитать исходник и компилять в два прохода. Чуда не получилось.

Все равно придется, см goto

Смотри выше.

Пролог ты как потом собрался впихнуть?

Во временный буфер для функций. Через него же реализуется goto. Зачем ты тут выдумал лишний проход, совершенно непонятно.