Lazarus 1.0

От asm-а. Вы таки провоцируете кэпа.

Тоже мне, аргумент - брейнфак тоже тьюринг-полный язык.

Вы КЭП?

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

В D, например, модули есть и это не случайность.

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

Честно говоря, ни один баг не попадался. Или может не заметил :)

Вы КЭП?

Не я. :) Но вы его провоцируете.

да поняли поняли. Школьник которому вдолбили, что делфи, де, круто, а потом ничего другого не осилил?

Да, блин, дальше бутсекторов на ассемблере не осилил ;)

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

Честно говоря, ни один баг не попадался. Или может не заметил :)

Пока Lazarus используется как блокнот, багов почти нет, да... :) А я тут вот наткнулся на новую багу. Теперь TForm создаётся у них как-то через жопу, потому что работающий код инициализации OpenGL контекста в эту самую TForm(используя её XWindow) нынче показывает какой-то бред - изображение отрезано сверху ровно на половину. TPanel и пр. - всё ок, в форму - всё, бида. Видать каких-то костылей с хаками понатыкали...

А пример RAII на паскале в студию можно?

try/finally уже не в почете? + автоматическое управление строками и интерфейсами

Если у вас пересекаются имена воспользуйтесь namespace, хотя это не единственный способ. А static как раз ограничивает область видимости символа, и в чем тут различие с implementation?

потому что синтаксис грамотно продуман

Потому что Вирт - педант, для него главное было сделать разбор парсером LL(1) и до первой ошибки, а не учитывать практические нужды. Борланд, Apple и остальные слегка поправили его ошибки, но вот даже перегрузка операторов лишь во freepascal есть, а на стандарт паскаля все клали - приходилось сталкиваться с ситуацией, когда от freepascal в вузе отказались из-за несоблюдения им стандарта - той его части, что описывает поведение неинициализированной переменной типа TEXT.

Торвальдс в вопросах ЯП такой же авторитет, как Денис Попов.

А авторитеты в ЯП тут и не нужны. Торвальдс отказал педанту Таненбауму и прочим некрофилам, которым не нравилось использование виртуальной памяти, потому что на их некрофильских машинах она не работала. Торвальдс ещё 20 лет назад сказал всё про «сперва подумал» - никто не может продумать всё заранее, и пытаться спланировать всё одной головой или даже командой бесполезно - программам следует развиваться эволюционно. Позже Стив МакКоннел объяснял, что программирование - грязная задача, и найти идеальное решение невозможно вообще, а приемлемое найдётся лишь после попытки реализовать неприемлемое. Паскалисты не верят, и радуются быстрой компиляции (даже говорят, будто на порядке быстрее, хотя на деле в пару раз), и не тревожатся пока о том, что теряется в LL(1) языке. Может лет через 20 дойдёт что.

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

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

А, порты из java. И это поделие, с перегрузкой операторов, с java на каждом шагу, с BEGIN/END и синтаксисом неудобным человеку, но удобным для LL(1), где даже рекурсию A()->B()->A() не реализуешь в соответствии со стандартом, считается лучше синтаксически чем C++.

Так и есть. Тупо переносили и переносят фичи с С++.

Если у вас пересекаются имена воспользуйтесь namespace

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

А static как раз ограничивает область видимости символа

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

Перегрузка операторов довольно сомнительная фича. Хотя она уже давно есть и в FP и в Object Pascal.

Потому что Вирт - педант

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

Паскалисты не верят, и радуются быстрой компиляции

Это не главное достоинство паскаля.

и не тревожатся пока о том, что теряется в LL(1) языке

Что же теряется? И самое интересное, что приобретается в CSG-языке?

А пример RAII на паскале в студию можно?

try/finally уже не в почете? + автоматическое управление строками и интерфейсами

не. Тут товарищ немного другое имел ввиду. Вот пример задачи. Говнокод:

void some_func(size_t n) {
    char * a = new char[n];
    char * b = new char[n];
    fill_def(a);
    some_call(a, b, n);
    delete [] a;
    delete [] b;
}

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

рекурсию A()->B()->A() не реализуешь в соответствии со стандартом

я не понял, пример можно?

procedure some_func(n: size_t) 
var
  a, b: array of char;
begin
    Setlength(a, n);
    Setlength(b, n);
    try
      fill_def(a);
      some_call(a, b, n);
    finally
      Setlength(a, 0);
      Setlength(b, 0);
    end;
end;

память выделенная для a и b никогда не утечет, или я что-то не так понял?

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

На сколько понял finally срабатывает всегда? Исключение или нет, блок будет выполнен всегда? еще вопрос:

a, b: array of char;
....
    Setlength(a, n);
    Setlength(b, n);

    Setlength(a, n);
    Setlength(b, n);

Тут у нас N пришло в значении 400 000 000, а в системе осталось 500 мегов. То есть на первый массив хватило, на второй нет. Что будет?

то есть array сам подчистит в случае чего? Вот это и хотелось узнать.

Точно-точно, я уже забыл когда массивы использовал последний раз. По поводу «OOM» на втором вызове вызове SetLenght: по хорошему надо делать try/finally для каждого выделения памяти тогда все будет ок. Да, finally вызывается всегда.

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

Для рассматриваемого примера достаточно написать так

procedure some_func(n: size_t) var a, b: array of char; begin Setlength(a, n); Setlength(b, n); try fill_def(a); some_call(a, b, n); except //здесь обработка ошибки если была end; end;

о как! то есть меняем условие немного

void some_func(size_t n) {
    some_object * a = new some_object[n];
    some_object * b = new some_object[n];
    fill_def(a);
    some_call(a, b, n);
    delete [] a;
    delete [] b;
}

Как будет выглядеть решение на паскале?

Смотри выше только нужно добавить еще один try/finally

Не нужно.

так нарисуй полное решение. Выше где?

Если объекты ручками чистить надо, что как там поможет try/fynally? вот этот код?

procedure some_func(n: size_t) 
    var a, b: array of some_object; 
begin 
    Setlength(a, n); 
    Setlength(b, n); 
    try 
        fill_def(a); 
        some_call(a, b, n); 
    except //здесь обработка ошибки если была 
    end; 
end;

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

Setlength(b, n); 

Это другой анонимус :)) (буду подписываться как 111)

Объекты не почистит удалит только сами массивы. Для динамических массивов неявно используется try finally содержащий всё тело подпрограммы. В случае фейла на Setlength сработает именно он. try except нужен для обработки проблем в fill_def или some_call, если нужно, конечно. А так можно и не обрабатывать.

Можно так, например

procedure some_func(n: size_t) 
    var a, b: array of some_object; 
begin 
 try
    Setlength(a, n); 
    Setlength(b, n); 
    //здесь заполняем массивы
    try 
        fill_def(a); 
        some_call(a, b, n); 
    except //здесь обработка ошибки если была 
    end; 
finally
 //здесь чистим массивы
 finalize(a);
 finalize(b);
end;

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

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

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

можно распространять в виде dcu файлов

upx — зло, даж на сайте фпц так написано -)

ok. буду подписываться как 222

В общем понял. Setlength(a, n); не инициализирует объекты.(конструктор по-умочанию не будет вызван?)

Еще вопрос. Выше по стеку нас ждет обработчик исключений, который пишет в лог. Setlength кинет исключение в случае недоступности памяти, так? Исключение может кинуть и fill_def и some_call как все эти исключения дальше прокинуть, после того, как ловим их?

Пока Lazarus используется как блокнот, багов почти нет, да... :)

Я негодую :) Последнее, что делал, это демон, как часть ботнета и с автоапдейтом, соединяющийся с удаленным MySQL-Сервером (100 различных по типу запросов в минуту), примерно столько же HTTP-запросов и 13 DNS-Queries в секунду. Всё это в 20 Threads и целый месяц без остановки.

Ни одного рестарта.

Видать каких-то костылей с хаками понатыкали...

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

Напоминает сказки «коекакразобравшихся» о неимоверном количестве багов в PHP :) и ваще тупой язык, я придумаю сейчас свой :)))

upx — зло, даж на сайте фпц так написано -)

Нормально с UPX идёт. Проблема только, что раму жрет т.к. закидывает туда всю прогу.

dcu это скомпилированный модуль, значит вместе с ним я должен распространить еще его интерфейсную часть. Но использовать эту часть я могу только как справочное пособие, на процесс сборки она никакого влияния не оказывает. Если у меня поменялась библиотека (dcu файл) то как программа, его использующая, проверит версию этого файла? Ведь заголовочные файлы участвуют в сборке наряду с библиотеками а тут только библиотеки предлагается использовать. Если я все правильно понял.

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

Та да, но не в том случаи когда отлаженный код работает везде, и работал до недавнего с самим Lazarus'ом, а потом обновился до 1.0 и везапно всё отвалилось :)

весь этот ужас встречаю и на си++ аутсорс проектах.

А я иногда в одном проекте встречаю :)

Enjoy your breaking changes :)

Enjoy your breaking changes :)

Мне то практически пофиг, мне Lazarus только как IDE нужна, а остальные то страдают. Я вообще предпочитаю FreePascal использовать исключительно как компилятор Pascal-кода, ибо использование любых его вспомогательных функций и т.д. - очень чревато и много где не работает нормально и отваливается от версии к версии.

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

использование любых его вспомогательных функций

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

остальные то страдают

у людей не отобрать кактус, пока другого нет :)

222 ok.

А теперь можно увидеть код на паскале, который решает задачу с утечкой и пробрасывает всевозможные исключения (дает понять выше, что что-то не так) из SetLength, fill_def и some_func?

111

В Паскале нет конструктора по умолчанию. Конструктор всегда вызывается явно, как и деструктор.

Если нужно прокинуть дальше, то после анализа и, возможно, обработки написать raise. Это предотвратит удаление объекта исключения и он попадет в следующую секцию.