implementation-часть TObject и структура объекта в памяти

[zub]

>>позвольте полюбопытствовать, а что такое "deciminalseparator"? яндекс сказал, что не знает.
извиняюсь, имел ввиду decimalseparator, первое что вспомнилось. Но это неважно)) таких вещей тонна и на уровне приложения это не решить в общем случае, только на уровне изменений в компиляторе-ртле

>>именно поэтому я ищу способ сделать так, чтобы было одно и то же.
Лучше обратиться в список рассылки, может последнее время были подвижки в эту сторону, или прольют свет когда ждать (надеюсь в этой жизни )

[ger0strat]

всякие "decimalseparator" находятся в sysinth.inc, что также можно загрузить и в библиотеке.
Application не сильно нужная штука. А тем более в демоне сервера.

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

[zub]

>>В общем, что хотел - узнал. Всем спасибо.
Позволю себе еще комент.
Если в длл не тредуется наследование от объекта\класса из ексе, можно сделать довольно просто - вернуть в длл указатель на объект\класс созданный в ексе (или наоборот), далее работать с ним какбудьто он создан в длл. Чтоб лишний раз не плодить код при объявлении объекта\класса в длл все метды объявить abstract. естественно они все должны быть виртуальными. Ну и для надежности выкинуть объявление в inc общий для exe и dll.
С учетом общего менеджера кучи проблема останется только в том что typeof(tmyobject{реального из exe})<>typeof(tmyobject{абстрактного из dll}), но typeof(tmyobject{реального из exe}) можно также экспортировать в длл и при необходимости оперировать им

>>всякие "decimalseparator" находятся в sysinth.inc, что также можно загрузить и в библиотеке.
интересно как?

[ger0strat]

вернуть в длл указатель на объект\класс созданный в ексе (или наоборот), далее работать с ним какбудьто он создан в длл.

ни разу не правда. AV

интересно как?

а разве нельзя просто заинклудить {$I somefile.inc}? возможно за ним потянутся некоторые модули, но это некритично.

[zub]

>>ни разу не правда. AV
Правда-правда. При условии одщего менеджера памяти, и одинакового окружения при компиляции (ключи, всё что в uses и т.п.). Пробовал так делать когдато давно - было всё норм. Сомневаюсь что сейчас чтото поменялось. Возможно AV у вас было по другим причинам?

>>а разве нельзя просто заинклудить {$I somefile.inc}? возможно за ним потянутся некоторые модули, но это некритично.
если somefile.inc часть ртл, то он уже подтянут неявным uses system который делается компилятором автоматически, любые пользовательские {$I somefile.inc} - это только вредящая вторая (третья в случае exe\dll) копия объявленных в somefile.inc сущностей

[ger0strat]

Возможно AV у вас было по другим причинам?

едва ли, но возможно. попробую собрать тест.

если somefile.inc часть ртл, то он уже подтянут неявным uses system

тогда decimalseparator будет прекрасно доступен в библиотеке и без извращений. как и все подобные переменные/константы. при правильном наборе юнитов, разумеется

[zub]

>>тогда decimalseparator будет прекрасно доступен в библиотеке и без извращений. как и все подобные переменные/константы. при правильном наборе юнитов, разумеется

Конечно будет доступен и в ексе и в длл, но это будут 2 разных decimalseparator, соответственно
в ексе:

Код: Выделить всё

decimalseparator:='.';
ВызовПроцедурыИзДллКотораяПарситСтрочку('123.456');

в длл:

Код: Выделить всё

procedure КотораяПарситСтрочку(value:string);
begin
  чтото:=StrToInt(value);
end;

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

[ger0strat]

Совершенно не понимаю, в чем проблема. Эти прелести либо прописаны статично(DirectorySeparator), то есть скомпилированная программа одной системы будет иметь все равно свои и только свои параметры, либо подхватываются в момент запуска (uid, gid, pid и прочий зоопарк), то есть библиотека точно так же это все получит. Чего избежать-то надо?

Добавлено спустя 4 минуты 46 секунд:
Re: implementation-часть TObject и структура объекта в памяти
Ну если нужно постоянно менять decimalseparator (отчего его смысл теряется), то можно в процессе инициализации создать запись со всеми переменными, которые нужны, передать указатель на нее из библиотеки в приложение и начинать радоваться жизни.

[zub]

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

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

[ger0strat]

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

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

А объект переданный из библиотеки таки заработал. Видимо АВ было действительно по другой причине.

[zub]

>>Или жду пример кода, с которым будут проблемы. Не гипотетического, а приближенного к реальному.
Выше я дал - вполне реальный пример - что в нем гипотетического? Конечно иожно юзать не StrToInt, а аналоги с прямой передачей всяких разделителей, можно "синхронизировать", можно писать свой заменитель ртл`а для разделяемых функций

При синхронизации список "синхронизируемого" будет разростаться с наращиванием функционала плагина (=увеличении зависимости от РТЛ), а главное с изменениями в ртл - тотже decimalseparator сегодня deprecated, завтра его выкинут... ИМХО очень нехороший способ

[ger0strat]

Разделительная точка - параметр, который устанавливается (если не берется из системы) 1 раз и на всё выполнение программы. Ну если нет склонности к мазохизму, конечно. Для таких задач предусмотрена инициализация. Указанный пример отражает скорее структурную ошибку, чем неудобство схемы.

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

[zub]

>>1 раз и на всё выполнение
При необходимости загружать внешние данные созданные на разных машинах с разными настройками - это нетак

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

[ger0strat]

Внешние данные тоже должны быть стандартизированы. Ну хотя бы в каких-то рамках. Иначе на фоне такого изврата синхронизация ртл не выглядит такой уж странной идеей)
Хотя пути заказчика неисповедимы)

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