Доброго времени суток.
Вопрос собственно в том, где найти первый сабж и/или описание второго.
Что касается TObject по информации из Objects и objpash.inc имеется следующее:
TObject объявлен и как объект, и как класс. Какое объявление когда используется - неизвестно.
В objpash никаких указаний на то, где же реализация, не нашел.
В objpas вполне ожидаемо упоминаний не нашел.
Мне не даёт покоя мысль, что структуры классов приложения и библиотеки можно-таки синхронизировать.
С менеджером памяти вопрос решён, но остаётся неясно, обо что же именно спотыкаются классы. Если метаданные хранятся по какому-то смещению то вполне реально их просто скопировать. Курение исходников пока результатов не дало, но процесс продолжается.
implementation-часть TObject и структура объекта в памяти
Модератор: Модераторы
ger0strat писал(а):TObject объявлен и как объект, и как класс.
У нас какие-то разные исходники fpc. У меня нет объявления TObject как object.
ger0strat писал(а):В objpash никаких указаний на то, где же реализация, не нашел.
Как несложно догадаться, зная структуру и принципы организации исходников в fpc, реализация в objpas.inc (в том же каталоге). Ищите начало по подстроке "constructor TObject.Create".
ger0strat писал(а):Мне не даёт покоя мысль, что структуры классов приложения и библиотеки можно-таки синхронизировать.
Начколько я помню, динамические пакеты в fpc пока не доделаны.
У нас какие-то разные исходники fpc. У меня нет объявления TObject как object.
objects.pp строка 250 (fpc 2.6.2)
Как несложно догадаться, зная структуру и принципы организации исходников в fpc, реализация в objpas.inc (в том же каталоге). Ищите начало по подстроке "constructor TObject.Create".
Не совсем понял. Там есть objpash.inc и objpas.pp. Но сути не меняет, в обоих глухо.
Начколько я помню, динамические пакеты в fpc пока не доделаны.
Потому и думаю, как это обойти)
tobject был object`ом когдато давно, во времена турбовижена, классов тогда в помине небыло. Сейчас это 2 разные сущности одна для объектов, другая для классов.
В случае объектов его можно использовать как базовый объект, а можно и неиспользовать. в случае классов он используется автоматически в виде базового, если базовый класс неуказывать.
Для объектов tobject в виде базового класса сразу добавит к вашему объекту указатель на вмт, т.к. имеет в своем определении виртуальный деструктор
это из objects.pp
Добавлено спустя 4 минуты 9 секунд:
>>Потому и думаю, как это обойти)
Лучше подождать. Или придется придумывать кривые хаки
Добавлено спустя 7 минут 41 секунду:
Re: implementation-часть TObject и структура объекта в памяти
>>implementation-часть TObject и структура объекта в памяти
в памяти объект распологается довольно просто - поля данных в порядке определения, с выравниванием. Если в наследнике появляются виртуальные методы, а в предке их небыло, то на границе наследования (там где кончились данные предка и пошли данные наследника) появляется указатель на VMT
В случае объектов его можно использовать как базовый объект, а можно и неиспользовать. в случае классов он используется автоматически в виде базового, если базовый класс неуказывать.
Для объектов tobject в виде базового класса сразу добавит к вашему объекту указатель на вмт, т.к. имеет в своем определении виртуальный деструктор
Код: Выделить всё
{---------------------------------------------------------------------------}
{ TObject OBJECT - BASE ANCESTOR OBJECT }
{---------------------------------------------------------------------------}
TYPE
TObject = OBJECT
CONSTRUCTOR Init;
PROCEDURE Free;
FUNCTION Is_Object(P:Pointer):Boolean;
DESTRUCTOR Done; Virtual;
END; это из objects.pp
Добавлено спустя 4 минуты 9 секунд:
>>Потому и думаю, как это обойти)
Лучше подождать. Или придется придумывать кривые хаки
Добавлено спустя 7 минут 41 секунду:
Re: implementation-часть TObject и структура объекта в памяти
>>implementation-часть TObject и структура объекта в памяти
в памяти объект распологается довольно просто - поля данных в порядке определения, с выравниванием. Если в наследнике появляются виртуальные методы, а в предке их небыло, то на границе наследования (там где кончились данные предка и пошли данные наследника) появляется указатель на VMT
tobject был object`ом когдато давно
Спасибо, в общем этого было достаточно)
Вопрос не горит, можно и подождать. Но ведь интересно.
Возникает другой вопрос: если диапозоны адресов в библиотеке и в приложении доступны друг другу без трансляции (а иначе нельзя было бы передать, например, PChar в функции), то в чем же проблема? Компилирует и то, и другое, один и тот же fpc, то есть структуры VMT идентичны.
ger0strat писал(а):то в чем же проблема?
Там ворох проблем, начиная с того кто выделял память и кончая "а той ли версии классы мне подсовывают, может у них другая реализация". Часть этих проблем (с памятью) уже решена (вроде), часть ещё нет.
>>то есть структуры VMT идентичны.
Идентичны, но разные. По факту будет 2 набора одного и тогоже кода - 2 разных обжекта\класса реализующих одно и тоже
Идентичны, но разные. По факту будет 2 набора одного и тогоже кода - 2 разных обжекта\класса реализующих одно и тоже
начиная с того кто выделял память
Решается установкой общего менеджера памяти.
"а той ли версии классы мне подсовывают, может у них другая реализация"
Модуль один и тот же. Компилируются все модули на одном наборе юнитов.
Добавлено спустя 1 минуту 42 секунды:
Re: implementation-часть TObject и структура объекта в памяти
Идентичны, но разные. По факту будет 2 набора одного и тогоже кода - 2 разных обжекта\класса реализующих одно и тоже
А какая разница, который набор используется, если они содержат одинаковые данные?
>>приложения и библиотеки
>>..
>>Модуль один и тот же. Компилируются все модули на одном наборе юнитов.
но в разное время, т.е. навскидку могут быть разные версии компилятора\ртл, разные ключи компиляции, набор юнитов может быть исправлен донеузнаваемости... да малоли чего.
Действительно, задача сложная, но нужная. Я бы непрочь наследоваться в библиотеке от класса\обжекта определенного в программе))
Добавлено спустя 4 минуты 22 секунды:
Re: implementation-часть TObject и структура объекта в памяти
>>А какая разница, который набор используется, если они содержат одинаковые данные?
такаяже, какая и для финализации стринга созданного в программе менеджером памяти в длл. вроде они одинаковые, а куча слетает))
ктоме того с точки зрения компилятора одинаковые классы из программы и длл совершенно разные, и это правильно))
>>..
>>Модуль один и тот же. Компилируются все модули на одном наборе юнитов.
но в разное время, т.е. навскидку могут быть разные версии компилятора\ртл, разные ключи компиляции, набор юнитов может быть исправлен донеузнаваемости... да малоли чего.
Действительно, задача сложная, но нужная. Я бы непрочь наследоваться в библиотеке от класса\обжекта определенного в программе))
Добавлено спустя 4 минуты 22 секунды:
Re: implementation-часть TObject и структура объекта в памяти
>>А какая разница, который набор используется, если они содержат одинаковые данные?
такаяже, какая и для финализации стринга созданного в программе менеджером памяти в длл. вроде они одинаковые, а куча слетает))
ктоме того с точки зрения компилятора одинаковые классы из программы и длл совершенно разные, и это правильно))
набор юнитов может быть исправлен донеузнаваемости
набор юнитов мой, так что если сам изменю - перекомпилирую все
вся радость в динамическом подхвате модулей сервера. можно, конечно и на record'ах собрать, что вполне работает, но люто неудобно.
такаяже, какая и для финализации стринга созданного в программе менеджером памяти в длл. вроде они одинаковые, а куча слетает))
еще раз, эта-то проблема решена. используется один менеджер памяти из отдельной библиотеки для приложения и всех модулей
>>еще раз, эта-то проблема решена. используется один менеджер памяти из отдельной библиотеки для приложения и всех модулей
Значит проблема должна быть понятна. Осталось решить ее для всех сущьностей дублируемых в exe\dll, т.е. например все системные переменные - application, deciminalseparator и т.д. и т.п... т.е. пихнуть всю ртл в тотдельную длл и решить вопросы с версионностью))
Значит проблема должна быть понятна. Осталось решить ее для всех сущьностей дублируемых в exe\dll, т.е. например все системные переменные - application, deciminalseparator и т.д. и т.п... т.е. пихнуть всю ртл в тотдельную длл и решить вопросы с версионностью))
вот даже как... я как-то не подумал, надо попробовать, вдруг выгорит
Добавлено спустя 9 минут 13 секунд:
Re: implementation-часть TObject и структура объекта в памяти
позвольте полюбопытствовать, а что такое "deciminalseparator"? яндекс сказал, что не знает.
Добавлено спустя 9 минут 13 секунд:
Re: implementation-часть TObject и структура объекта в памяти
позвольте полюбопытствовать, а что такое "deciminalseparator"? яндекс сказал, что не знает.
ger0strat писал(а):набор юнитов мой, так что если сам изменю - перекомпилирую все
Компилятор только об этом не в курсе. А так же rtl и динамический линковщик. Компилятор же не по строковому имени типы сравнивает. В результате TObject из основного приложения не то же самое, что тот же TObject из библиотеки. И даже полное совпадение полей не значит, что это тот же класс с той же реализацией.
Компилятор только об этом не в курсе.
имелось ввиду перекомпилирую и приложение, и библиотеки на одном и том же компиляторе. то есть rtl один-в-один.
В результате TObject из основного приложения не то же самое, что тот же TObject из библиотеки.
именно поэтому я ищу способ сделать так, чтобы было одно и то же.
ger0strat писал(а):имелось ввиду перекомпилирую и приложение, и библиотеки на одном и том же компиляторе. то есть rtl один-в-один.
Компилятор и rtl, рассчитанные на общий случай, принимают вашу торжественную клятву, произнесённую на томиках "Исскуства программирования" Кнута.
ger0strat писал(а):именно поэтому я ищу способ сделать так, чтобы было одно и то же.
Ну, у Borland это получилось. Так что в принципе - можно.