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

[ger0strat]

Доброго времени суток.
Вопрос собственно в том, где найти первый сабж и/или описание второго.
Что касается TObject по информации из Objects и objpash.inc имеется следующее:
TObject объявлен и как объект, и как класс. Какое объявление когда используется - неизвестно.
В objpash никаких указаний на то, где же реализация, не нашел.
В objpas вполне ожидаемо упоминаний не нашел.

Мне не даёт покоя мысль, что структуры классов приложения и библиотеки можно-таки синхронизировать.
С менеджером памяти вопрос решён, но остаётся неясно, обо что же именно спотыкаются классы. Если метаданные хранятся по какому-то смещению то вполне реально их просто скопировать. Курение исходников пока результатов не дало, но процесс продолжается.

[pda]

TObject объявлен и как объект, и как класс.

У нас какие-то разные исходники fpc. У меня нет объявления TObject как object.

В objpash никаких указаний на то, где же реализация, не нашел.

Как несложно догадаться, зная структуру и принципы организации исходников в fpc, реализация в objpas.inc (в том же каталоге). Ищите начало по подстроке "constructor TObject.Create".

Мне не даёт покоя мысль, что структуры классов приложения и библиотеки можно-таки синхронизировать.

Начколько я помню, динамические пакеты в fpc пока не доделаны.

[ger0strat]

У нас какие-то разные исходники fpc. У меня нет объявления TObject как object.

objects.pp строка 250 (fpc 2.6.2)

Как несложно догадаться, зная структуру и принципы организации исходников в fpc, реализация в objpas.inc (в том же каталоге). Ищите начало по подстроке "constructor TObject.Create".

Не совсем понял. Там есть objpash.inc и objpas.pp. Но сути не меняет, в обоих глухо.

Начколько я помню, динамические пакеты в fpc пока не доделаны.

Потому и думаю, как это обойти)

[zub]

tobject был object`ом когдато давно, во времена турбовижена, классов тогда в помине небыло. Сейчас это 2 разные сущности одна для объектов, другая для классов.
В случае объектов его можно использовать как базовый объект, а можно и неиспользовать. в случае классов он используется автоматически в виде базового, если базовый класс неуказывать.
Для объектов 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

[ger0strat]

tobject был object`ом когдато давно

Спасибо, в общем этого было достаточно)
Вопрос не горит, можно и подождать. Но ведь интересно.

Возникает другой вопрос: если диапозоны адресов в библиотеке и в приложении доступны друг другу без трансляции (а иначе нельзя было бы передать, например, PChar в функции), то в чем же проблема? Компилирует и то, и другое, один и тот же fpc, то есть структуры VMT идентичны.

[pda]

то в чем же проблема?

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

[zub]

>>то есть структуры VMT идентичны.
Идентичны, но разные. По факту будет 2 набора одного и тогоже кода - 2 разных обжекта\класса реализующих одно и тоже

[ger0strat]

начиная с того кто выделял память

Решается установкой общего менеджера памяти.

"а той ли версии классы мне подсовывают, может у них другая реализация"

Модуль один и тот же. Компилируются все модули на одном наборе юнитов.

Добавлено спустя 1 минуту 42 секунды:
Re: implementation-часть TObject и структура объекта в памяти

Идентичны, но разные. По факту будет 2 набора одного и тогоже кода - 2 разных обжекта\класса реализующих одно и тоже

А какая разница, который набор используется, если они содержат одинаковые данные?

[zub]

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

Добавлено спустя 4 минуты 22 секунды:
Re: implementation-часть TObject и структура объекта в памяти
>>А какая разница, который набор используется, если они содержат одинаковые данные?
такаяже, какая и для финализации стринга созданного в программе менеджером памяти в длл. вроде они одинаковые, а куча слетает))
ктоме того с точки зрения компилятора одинаковые классы из программы и длл совершенно разные, и это правильно))

[ger0strat]

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

набор юнитов мой, так что если сам изменю - перекомпилирую все
вся радость в динамическом подхвате модулей сервера. можно, конечно и на record'ах собрать, что вполне работает, но люто неудобно.

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

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

[zub]

>>еще раз, эта-то проблема решена. используется один менеджер памяти из отдельной библиотеки для приложения и всех модулей
Значит проблема должна быть понятна. Осталось решить ее для всех сущьностей дублируемых в exe\dll, т.е. например все системные переменные - application, deciminalseparator и т.д. и т.п... т.е. пихнуть всю ртл в тотдельную длл и решить вопросы с версионностью))

[ger0strat]

вот даже как... я как-то не подумал, надо попробовать, вдруг выгорит

Добавлено спустя 9 минут 13 секунд:
Re: implementation-часть TObject и структура объекта в памяти
позвольте полюбопытствовать, а что такое "deciminalseparator"? яндекс сказал, что не знает.

[pda]

набор юнитов мой, так что если сам изменю - перекомпилирую все

Компилятор только об этом не в курсе. А так же rtl и динамический линковщик. Компилятор же не по строковому имени типы сравнивает. В результате TObject из основного приложения не то же самое, что тот же TObject из библиотеки. И даже полное совпадение полей не значит, что это тот же класс с той же реализацией.

[ger0strat]

Компилятор только об этом не в курсе.

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

В результате TObject из основного приложения не то же самое, что тот же TObject из библиотеки.

именно поэтому я ищу способ сделать так, чтобы было одно и то же.

[pda]

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

Компилятор и rtl, рассчитанные на общий случай, принимают вашу торжественную клятву, произнесённую на томиках "Исскуства программирования" Кнута.

именно поэтому я ищу способ сделать так, чтобы было одно и то же.

Ну, у Borland это получилось. Так что в принципе - можно.