М
вообще это уже настолько аксиома ("не делать/вызывать внешние DLL с параметрами string"), что я даже не могу найти оф.пруфов ))
Зато можно widestring
Size: a a a
2020 December 21
AS
Константин Тимофеев
Более 15.
а, кажется, при создании DLL, там коммент добавляется об этом..
что надо юзать общий менеджер памяти borlndmm.dll
что надо юзать общий менеджер памяти borlndmm.dll
DB
вообще это уже настолько аксиома ("не делать/вызывать внешние DLL с параметрами string"), что я даже не могу найти оф.пруфов ))
делать можно при использовании правильного менеджера памяти, который умеет быть единым для основного процесса и подключаемых длллок. FastMM умеет. он с какой-то версии делфи стал дефолтным
может поэтому и убрали пруфы )
может поэтому и убрали пруфы )
SB
Константин Тимофеев
Возможно это правильнее. Там по разному в коде может быть. Я хэширование на си оставил. Есть ряд внешних библиотек сложных на си. Но самая засада это фортрана.
Еще упомянуто использование констант вместо SizeOf(). К чему такая дикость, если есть https://www.freepascal.org/docs-html/prog/progsu59.html
SB
И то же самое для record
AS
там, весь пойнт, как я понял, в том, что есть ДЛЛки, в которых нет потоков ) но он вызывается из главного приложения из нескольких потоков...
но это, если я правильно понял
но это, если я правильно понял
AS
Константин Тимофеев
Более 15.
Приложение 1 – исходный текст прокладки для Direct2D
ну и это я бы (настоятельно) рекомендовал выложить на ГХ/ГЛ/ББ
ну и это я бы (настоятельно) рекомендовал выложить на ГХ/ГЛ/ББ
КТ
там, весь пойнт, как я понял, в том, что есть ДЛЛки, в которых нет потоков ) но он вызывается из главного приложения из нескольких потоков...
но это, если я правильно понял
но это, если я правильно понял
Точно так
SB
// для
идентификации формата строки был задействован старший бит в 4-х байтном числе
Тут тоже смутное ощущение геморроя. Вроде бы для этих целей BOM придумали. А еще лучше везде хранить UTF-8 и при чтении-записи конвертить в WideString при необходимости.
идентификации формата строки был задействован старший бит в 4-х байтном числе
Тут тоже смутное ощущение геморроя. Вроде бы для этих целей BOM придумали. А еще лучше везде хранить UTF-8 и при чтении-записи конвертить в WideString при необходимости.
AS
Константин Тимофеев
Точно так
а как всё это собирается под Linux? ))
и собирается ли то же самое - в ФПЦ, но под винду?
и собирается ли то же самое - в ФПЦ, но под винду?
КТ
// для
идентификации формата строки был задействован старший бит в 4-х байтном числе
Тут тоже смутное ощущение геморроя. Вроде бы для этих целей BOM придумали. А еще лучше везде хранить UTF-8 и при чтении-записи конвертить в WideString при необходимости.
идентификации формата строки был задействован старший бит в 4-х байтном числе
Тут тоже смутное ощущение геморроя. Вроде бы для этих целей BOM придумали. А еще лучше везде хранить UTF-8 и при чтении-записи конвертить в WideString при необходимости.
Это обусловлено совместимостью с файлами проектов в старой версии.
КТ
а как всё это собирается под Linux? ))
и собирается ли то же самое - в ФПЦ, но под винду?
и собирается ли то же самое - в ФПЦ, но под винду?
Хорошо собирается. В фпц под винду делал тестовую сборку. И частично оно сначала так и отлаживалось. Но под виндой у нас штатно delphi. Поэтому живём так: delphi в винде - основная ветка, fpc под линуксом - дочерняя, которая реже обновляется.
AS
Константин Тимофеев
Это обусловлено совместимостью с файлами проектов в старой версии.
AS
Константин Тимофеев
Хорошо собирается. В фпц под винду делал тестовую сборку. И частично оно сначала так и отлаживалось. Но под виндой у нас штатно delphi. Поэтому живём так: delphi в винде - основная ветка, fpc под линуксом - дочерняя, которая реже обновляется.
переформулирую:
"как построен процесс сборки?" ))
эээ.. отдельная ветка? зачем? вы ж IDFEF-ов напихали
"как построен процесс сборки?" ))
эээ.. отдельная ветка? зачем? вы ж IDFEF-ов напихали
КТ
переформулирую:
"как построен процесс сборки?" ))
эээ.. отдельная ветка? зачем? вы ж IDFEF-ов напихали
"как построен процесс сборки?" ))
эээ.. отдельная ветка? зачем? вы ж IDFEF-ов напихали
Исходники (pas и dpr файлы - общие для Windows и Linux). Файлы форм - frm - полуавтоматически сконвертированы с dfm. Файлы конфигурации проектов - dproj для Delphi и ctpr для Codetyphon (lazarus) - отдельные для каждой среды разработки. Сборка программы в Windows делается скриптом с вызовом msbuild с указанием разрядности, и нужной конфигурации. Сборка в typhon - инструментом MultiProject.
КТ
Сборка инсталлятора под WIndows - юникодная версия NSIS. Под Linux делаем пока только архив, т.к. версия для спецнужд в основном.
SB
// В идеале для всех интерфейсных функций
лучше как раз PChar и использовать, т.е. он гарантирует, что внутри реализации интерфейсной
функции будут скопированы данные строки, а не просто указатель.
Вот тут прям когнитивный диссонанс, поскольку PChar это и есть указатель. А вот почему в параметрах динамической библиотеки PChar работает как string, а string как PChar - это повод для написания минимального примера и выкладывания на багтрекер FPC.
лучше как раз PChar и использовать, т.е. он гарантирует, что внутри реализации интерфейсной
функции будут скопированы данные строки, а не просто указатель.
Вот тут прям когнитивный диссонанс, поскольку PChar это и есть указатель. А вот почему в параметрах динамической библиотеки PChar работает как string, а string как PChar - это повод для написания минимального примера и выкладывания на багтрекер FPC.
AK
всё равно не понимаю, зачем использовать два разных компилятора под винду и линукс, если можно остановиться на одном