Ответ на »сообщение 165« (al_mt)
___________________________

Ответ на »сообщение 164« (Павел Ишенин)
_______________________
И как впечатления?

От чего?
Если от eepc, то конечно на eeepc все тормознее чем на большом компьютере и часто это надоедает. Но если вариантов нет, то привыкнуть можно.

Если от lazarus + fpc, то я на них в основном только lazarus и разрабатываю ;) Все устраивает, а если не устраивает - то правлю.

Ответ на »сообщение 164« (Павел Ишенин)
_______________________
И как впечатления?

Ответ на »сообщение 163« (al_mt)
___________________________
У меня стоят fpc + lazarus на eepc 900

Вот передо мной встал (во весь непропорциональный рост) вопрос, о самопальном софте для eee PC.
Знаете нетбуки такие мелкие безвинтовые... Кто-нить пытался на них FreePascal/Lasarus ставить?

Размер исполняемых файлов это решаемая проблема. И дело тут:
1. В отладочной информации. При использовании fpc 2.3.1, lazarus 0.9.27 возможно
  а) вырезать отладочную информацию из исполняемого файла. Настраивается в опциях компилятора для проекта
  б) выносить отладочную информацию во внешний файл (будет 1 файл exe, другой dbg)

2. В свзяке LCL - Widgetset. Например, есть в win32 большой обработчик сообщений, который обрабатывает сообщения для большинства контролов и код кое-где написан

if lWinControl is TCustomCheckbox then
...
if (lWinControl is TCustomEdit) then

В результате компилятор не может выкинуть из исполняемого файла компонент TCustomCheckBox, TCustomEdit, так как имеется условие проверки is. И таких мест увы пока много. Решение - писать обработчик сообщений для каждого контрола свой и из него вызывать общий где обработка одинакова.
Были и другие более глобальные проблемы связки Widgetset - LCL которые удалось решить в версии 0.9.27. В результате размер исполняемого файла уменьшился на 18%.

Мы продолжим работу над уменьшением размера исполняемого файла в версии 0.9.29

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

Выводы.
1. Пустая форма с кнопкой увы занимает много места - около 1.6 Мб (без иконки и отладочной информации), что в несколько раз больше чем в delphi. Но при добавлении новых контролов на форму или использовании новых классов объем исполняемого файла растет существеннее медленнее чем в delphi. Таким образом, для больших приложений разница в размере будет минимальна.
2. Проблема известна, решение известно. В этом направлении велась и будет вестись работа в след. версиях.

Ответ на »сообщение 159« (_kolyan)
___________________________
Не совсем верно, вернее разработчики до выхода 1.0 версии будут включать отладочную информацию. При  выходе однерки она будет отключена.

По поводу открытости кодов среды:
  Насколько важна для коммерческих и не очень проектов вкладка приложения "информация о версии" все знают. Приведу проблемы которые пришлось решать нам.
  1. В последних версиях delphi на вкладке с информацией о приложении невозможно вписывать кирилицу - в скомпилированном файле получаются кракозябры. (неудачное внедрение UTF). Пришлось вписывать необходимое количество символов латиницей, а в готовом приложении, перед отправкой клиенту, редакторами ресурсов исправлять.
  2. В лазаре на этой вкладке не хватало нескольких полей которые мы привыкли заполнять. 15 минут на правку исходников среды - и все великолепно!

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

На сайте FPC (кажется там) английским по белому написано, что основной объем - это отладочная информация. Вроде как в среде нет галки, чтобы не включать ее в исполняемый файл. Но есть утилита strip в папке с FPC, которая удаляет эту информацию.
12.9Мб -> 1.2Мб

Это все еще больше, чем аналогичное приложение на Delphi, но уже сравнимо.

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

Внесу свою лепту. У меня есть проект www.contester.ru. Обстоятельства в своё время подсказали создать версию для Windows и для Linux. Так вот, не-GUI приложения любой сложности отлично портируются с Delphi на FreePascal. Удобно то, что на самом деле я только один раз прописываю участки кода, специфичные для ОС, далее пишу на более высоком уровне и код действительно кроссплатформный.

"Напиши один раз - скомпилируй везде" конечно утопия. Но FreePascal всё больше повышает совместимость с Delphi. Надеюсь, со временем, работ по реализации специфики Linux будет меньше.

Что же касается размеров исполняемых файлов - это для меня совершенно не важно. И это понимают разработчики FreePascal. Я думаю, они будут работать над уменьшением "экзешников" в последнюю очередь - и будут правы. Есть более важные задачи.