freepascal.ru

Довольно давно использую FPC в своих разработках, но все под Win32 да Go32. Когда пишу под винду то использую опыт работы с Delphi, когда под DOS, то, соответственнно, опыт TP/BP и всегда чувствую себя нормально, благо программирую уже более десяти лет.

Но вот сел писать программу, которая должна компилироваться и работать под всеми "большими" платформами (Windows, Linux и FreeBSD, 32/64 бита, возможно даже не-x86) и чувствую себя как последний чайник потому что просто не знаю что в этих условиях мне можно, а чего нельзя. Программа по сути простая -- читает один файл и пишет другой, никакой сети, никаких платформенно-зависимых интерфейсов. Но вопросов все равно масса:

- на какие модули я могу расчитывать (применительно к программе интересует SysUtils)?
- если модуль кроссплатформенный, то все ли функции будут присутсвовать и работать как ожидается (I/O-функции File*)?
- есть ли готовая библиотека, заменяющая полезные платформенно-зависимие мелочи (типа виндовой GetTickCount)?
- как минимальной кровью пополучить скопом все испольняемые файлы без установки каждой системы и FPC под нее?

P.S. Давно заметил что FPC по сравнению с Delphi более критичен к мелким ошибкам. Если под Delphi код работает вроде бы идеально, то под FPC запросто может завалиться при первом же запуске. Однако после анализа обычно выясняется, что ошибка действительно есть (обычно "мелочь" типа выхода за границы допустимых значений). Считаю такое поведение преимуществом FPC (это ведь Pascal, а не C).

mike
Все очень просто, - не использовать uses Windows и другие модули использующие WinAPI.
А если чего-то не будет хватать, то всегда можно воспользоваться модулями LCLclasses, LCLtype, LCLproc и тд.
Там описаны почти все типы и классы используемые в WinAPI

Для чисто консольных приложений – не использовать uses Interfaces и Forms.
А LCL (=VCL) само по себе кросс-платформенно...

mike писал(а):(это ведь Pascal, а не C)

А почему в Pascal компилятор должен глотать ошибки?
Pascal – это не компилятор для «блондинок», здесь все по-честному
Награда этому – возможность компоновать объектные модули, написанные на разных языках (можно собрать программу на половину написанную на Pascal и на С если все символы будут связаны, имена соответствовать, а также порядок передачи данных в процедуры соответствовать)
Да и вообще FPC работает подобно С.
Также генерирует ассемблер-код, прогоняет as, получаем объектные файлы, а потом они прогоняется через ld. А на выходе получится программа или еще что-то ))
Такой же процесс и в С и в С++, разница в том, что FPC прогоняет код за 1 проход, а С** делает это как минимум дважды.
as, ld и прочие утилиты – из комплекта GNU Build Tools (т.е. из GCC )

NXP писал(а):Все очень просто, - не использовать uses Windows и другие модули использующие WinAPI.

Так вот неочевидно кто его использует (точнее, кто использует его и только его). Из того же SysUtils торчит масса виндовых "хвостов" (типа некоторых констант fmShare*), непонятно, будет ли под очередной платформой работать, например, FileSeek от конца файла.

А вот еще мне нужно сделать truncate некоторому файлу, как сделать это кроссплатформенно?

И еще вопросы по типам данных. Проверить пока возможности нет. Размерность типа Cardinal всегда соотвествует разрядной сетке процессора? А Integer? А конструкция типа Pointer(Cardinal(Ptr)+Ofs) допустипа под экзотикой типа ARM/PPC (тут опять же вопрос розрядности Pointer)?

NXP писал(а):

mike писал(а):(это ведь Pascal, а не C)

А почему в Pascal компилятор должен глотать ошибки?

Не должен, именно потому что это не C. Я ж назвал это преимуществом FPC, а не недостатком.

mike писал(а):Так вот неочевидно кто его использует (точнее, кто использует его и только его). Из того же SysUtils торчит масса виндовых "хвостов" (типа некоторых констант fmShare*), непонятно, будет ли под очередной платформой работать, например, FileSeek от конца файла.А вот еще мне нужно сделать truncate некоторому файлу, как сделать это кроссплатформенно?

Разработчики об этом позаботились.
Главное – не использовать WinAPI явным образом. Все необходимые подставы выполнят макросы.
Ps Лучше по началу не даже не задумываться об этом.
Просто не используй uses Windows
PSS В комплекте с Lazarus идет куча примеров. Они все кросс-платформены.
Там также используется LCL, модули SysUtils и прочие нативные для Delphi.
Но нет использования WinAPI.
PSSS В Linux с модулем Windows не получится скомпоновать программу. Так что опасения не имею под собой почвы. Очевидно, что такие моменты давно отлажены.

NXP писал(а):

mike писал(а):Так вот неочевидно кто его использует (точнее, кто использует его и только его). Из того же SysUtils торчит масса виндовых "хвостов" (типа некоторых констант fmShare*), непонятно, будет ли под очередной платформой работать, например, FileSeek от конца файла.А вот еще мне нужно сделать truncate некоторому файлу, как сделать это кроссплатформенно?

Разработчики об этом позаботились.

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

NXP писал(а):PSSS В Linux с модулем Windows не получится скомпоновать программу.

С модулем Windows все понятно, но проверять каждый новый модуль в каждой из целевых систем накладно. У меня их даже нет в наличии (вообще некуда поставить какой-нибудь ppc-linux).

mike писал(а):И еще вопросы по типам данных. Проверить пока возможности нет. Размерность типа Cardinal всегда соотвествует разрядной сетке процессора? А Integer? А конструкция типа Pointer(Cardinal(Ptr)+Ofs) допустипа под экзотикой типа ARM/PPC (тут опять же вопрос розрядности Pointer)?

Cardinal 32-битный. Integer - 16 бит в режиме совместимости с TP, в остальных режимах 32 бит. Разрядность Pointer имеют типы PtrInt и PtrUInt - соответственно знаковое и беззнаковые целые.
Всякие Pointer(Cardinal(Ptr)+Ofs) можно забыть как кошмарный сон. FPC умеет складывать и вычитать указатели и целые в любых комбинациях.

Sergei I. Gorelkin писал(а):

mike писал(а):И еще вопросы по типам данных. Проверить пока возможности нет. Размерность типа Cardinal всегда соотвествует разрядной сетке процессора? А Integer? А конструкция типа Pointer(Cardinal(Ptr)+Ofs) допустипа под экзотикой типа ARM/PPC (тут опять же вопрос розрядности Pointer)?

Cardinal 32-битный.

А под x86-64?

Разрядность Pointer имеют типы PtrInt и PtrUInt - соответственно знаковое и беззнаковые целые.

Спасибо, полезно.

Всякие Pointer(Cardinal(Ptr)+Ofs) можно забыть как кошмарный сон. FPC умеет складывать и вычитать указатели и целые в любых комбинациях.

И вправду работает!

mike
Если речь идёт о файловых операциях, то теоретически под всеми платформами будут работать то, что было в ТР, т.е. Assign(F, filename) или AssignFile(F, filename) и весь набор связанных с этим инструкций.
Так же будут работать файловые потоки типа TFileStream.

NXP писал(а):Да и вообще FPC работает подобно С.
Также генерирует ассемблер-код, прогоняет as, получаем объектные файлы, а потом они прогоняется через ld. А на выходе получится программа или еще что-то ))

FPC так не работает, если его специально не заставлять.

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

Так например, юнит Windows, WinSock, BaseUnix и т.п. заведомо плафтомно-зависимы, потому нежелательно непосредственное их использование в своих проектах.

Можно полагаться на следующие юниты:
(привожу только то, в чем уверен)
Базовые: SysUtils, Classes
Работа с датами: DateUtils
Работа с сетью: Sockets
...

Можно полагаться на следующие библиотеки:
(привожу только то, в чем уверен)
Libcurl - работа с FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE. Для работы на том же сайте найдете curlpas
SQLite - встраиваемая реляционая СУБД
MySQL - клиент-серверная и встраиваемая реляционая СУБД
libxml - работа с XML-файлами, интерфейсы SAX, DOM
...

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

Vadim писал(а):mike
Если речь идёт о файловых операциях, то теоретически под всеми платформами будут работать то, что было в ТР, т.е. Assign(F, filename) или AssignFile(F, filename) и весь набор связанных с этим инструкций.

Изначально мне хватило бы Assign(Txt, 'file.txt')/Reset(Txt), но обнаружилась досадная особенность -- открыть таким образом "живой" лог нельзя, не позволяет жестко зашитиый в Reset тип шаринга "1" (fmShareDenyWrite) для текстовых файлов. Причем на содержимое переменной FileMode в данном случае библиотека кладет (точно так же ведут себя и борландовские языки). Поэтому пришлось реализовывать собственный класс буферизированного доступа к текстовому файлу, а в нем мне удобнее всего использовать FileOpen/FileRead/..., но даже при использовании блочного или потокового ввода/вывода встает тот же самый вопрос о правомерности использования режима fmShareDenyNone.

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

Вот я и и нтересуюсь, какие можно, а какие нельзя

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

Ну с модулями вроде более-менее выяснил, мне пока достаточно SysUtils, Types и Classes. Вот еще актуальным вопрос о размерности Cardinal под 64-битными платформами остался...

P.S. Что нужно сделать для того, чтобы работали еще какие-нибудь другие target'ы кроме "родного"? Нужные бибилиотеки в каталог "units" подложил, но во-первых макрос $target в пути к библиотекам под FP (не FPC) не работает, а во-вторых даже если на время привести путь в соответствие с новым traget'ом, исполняемый файл в итоге не линкуется. Подскажите где взять полный набор кросскомпиляторов и как настроить среду FP для переключения их и путей одним только указанием target.

mike писал(а):Изначально мне хватило бы Assign(Txt, 'file.txt')/Reset(Txt), но обнаружилась досадная особенность -- открыть таким образом "живой" лог нельзя, не позволяет жестко зашитиый в Reset тип шаринга "1" (fmShareDenyWrite) для текстовых файлов.

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

mike писал(а): Вот еще актуальным вопрос о размерности Cardinal под 64-битными платформами остался...

32-битный он. В настоящее время. В прошлом был 64-бит, но по-видимому это вызывало излишне много проблем. 64 бита без знака - это QWord.

mike писал(а):но во-первых макрос $target в пути к библиотекам под FP (не FPC) не работает...

Макрос называется $FPCTARGET.
Кроме юнитов и библиотек нужен пакет binutils для целевой платформы. Но не для всех, например компиляция из Linux в Windows (т.к. для Windows линкер встроен в компилятор) обходится без них.
Вообще, на тему кросс-компиляции тут много чего понаписано, даже статьи.

Sergei I. Gorelkin писал(а):

mike писал(а):Изначально мне хватило бы Assign(Txt, 'file.txt')/Reset(Txt), но обнаружилась досадная особенность -- открыть таким образом "живой" лог нельзя, не позволяет жестко зашитиый в Reset тип шаринга "1" (fmShareDenyWrite) для текстовых файлов.

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

Понимаю, но работать как-то нужно.

mike писал(а): Вот еще актуальным вопрос о размерности Cardinal под 64-битными платформами остался...

32-битный он. В настоящее время. В прошлом был 64-бит, но по-видимому это вызывало излишне много проблем. 64 бита без знака - это QWord.

Ясно, спасибо.

mike писал(а):но во-первых макрос $target в пути к библиотекам под FP (не FPC) не работает...

Макрос называется $FPCTARGET.
Кроме юнитов и библиотек нужен пакет binutils для целевой платформы. Но не для всех, например компиляция из Linux в Windows (т.к. для Windows линкер встроен в компилятор) обходится без них.
Вообще, на тему кросс-компиляции тут много чего понаписано, даже статьи.

Будем искать.