Класс-не наследник tObject

[runewalsh]

Реален ли сабж на FPC?

[defecator]

Эмммм.....А как такое может быть ?

[runewalsh]

Вообще, хотелось бы иметь memory layout как у object'а - VMT+указатели на виртуальные методы, без таблицы интерфейсов, имён методов и проч. Подозреваю, что никак.

[Павел Ишенин]

Насколько я понял objcclass что-то похожее на то что вы просите. Правда я с этими структурами не работал и могу сильно ошибаться.

[zub]

>>Вообще, хотелось бы иметь memory layout как у object'а
а сам object не устраивает?

[runewalsh]

Сам object и использую, только крышечки иногда выглядят не в тему
Может есть способ для объектов, распределённых в куче, обойтись без явного разыменования указателя, то есть использовать foo.Width вместо foo^.Width?

[скалогрыз]

Вообще, хотелось бы иметь memory layout как у object'а - VMT+указатели на виртуальные методы, без таблицы интерфейсов, имён методов и проч.

чего ради... "экономии памяти"?

[runewalsh]

Ну, во-первых, объекты мне более симпатичны.
А во-вторых, если, в классе заведомо не будут использоваться, ну там, message'ы, интерфейсы, is-as и т. п., то разумно (имхо) их не поддерживать. И, хотя это не принципиально - да, объекты быстрее, особенно создание и уничтожение, + экономия памяти.
М. б. фичи, поддерживаемые благодаря наследованию от tObject, являются частью концепции классов в Object Pascal? Но, например, в C++ у классов нет общего предка, и сделать такое в Free Pascal было бы по крайней мере интересно.

[скалогрыз]

А во-вторых, если, в классе заведомо не будут использоваться, ну там, message'ы, интерфейсы, is-as и т. п., то разумно (имхо) их не поддерживать.

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

кстати, программисты C++ по-всякому изгаляются, когда им нужен функционал as и is

И, хотя это не принципиально - да, объекты быстрее, особенно создание и уничтожение, + экономия памяти.

а есть ли замеры (тесты) по "быстродействию"?
и есть ли замеры по экономии памяти?!
есть ли такая задача, где использование классов, ну никак не подходит, но нужно что-то ООП-шное?!

имхо: тут есть некая фобия, необоснованная боязнь высокоуровневых конструкций языка (страх потери в скорости и объёмах памяти). Точно так же, как тру-программисты не используют тип String или динамические массивы.
Программистов Java и .Net такие вещи, например, не смущают

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

[runewalsh]

// Конечно, я страдаю этим (^object вместо class) только в своих проектах.

необоснованная боязнь высокоуровневых конструкций языка

Может быть, но зачем неявно наследовать все классы от TObject? Всё равно, что наследовать все интерфейсы от IUnknown, даже если я не собираюсь создавать COM-интерфейс. Последнее в FPC решается сменой модели интерфейсов на CORBA, тогда у интерфейсов не будет общего предка, по идее, нечто похожее можно сделать и с классами...

а есть ли замеры (тесты) по "быстродействию"?

Набросал, в аттаче.

и есть ли замеры по экономии памяти?!

Эмм, ну, в теории, лишних 80 байт на VMT всё-таки

есть ли такая задача, где использование классов, ну никак не подходит, но нужно что-то ООП-шное?!

Нет... Я не против классов, просто, скажем, какому-нибудь tVector3D, и не только ему, большая часть функциональности TObject не нужна.
Скажите наконец кто-нибудь, что такого FPC не умеет, по крайней мере пока, чтобы я успокоился.

[Sergei I. Gorelkin]

Эмм, ну, в теории, лишних 80 байт на VMT всё-таки

80 байт на класс. Расход на экземпляр - 1 указатель (4 или 8 байт в зависимости от платформы). В случае с object размер VMT плюсуется к каждому экземпляру, если я правильно понимаю, и время инициализации каждого экземпляра растет в зависимости от размера этой самой VMT.
Появление class как раз и ставило задачей уйти от этой зависимости.

Скажите наконец кто-нибудь, что такого FPC не умеет, по крайней мере пока, чтобы я успокоился.

Не умеет. Успокойся

[runewalsh]

В случае с object размер VMT плюсуется к каждому экземпляру, если я правильно понимаю, и время инициализации каждого экземпляра растет в зависимости от размера этой самой VMT

А вот и нет. Как и для классов, в object memory layout первые 4/8 байт - указатель на VMT, и она не копируется для каждого экземпляра - п. 8.2.12 Programmer's Guide

Не умеет

Спасибо

[Sergei I. Gorelkin]

А вот и нет. Как и для классов, в object memory layout первые 4/8 байт - указатель на VMT, и она не копируется для каждого экземпляра - п. 8.2.12 Programmer's Guide

Да, там действительно только указатель на VMT, только расположен не в начале, а в конце, причем не так-то просто определить, где именно: http://bugs.freepascal.org/view.php?id=16034

Тогда мне становится интересно, из-за чего создание object оказывается (по результатам приложенного теста, на моем компьютере на 15%) быстрее, чем class. Теоретически должно быть одно и то же... Надо будет поисследовать на досуге...

[скалогрыз]

Нет... Я не против классов, просто, скажем, какому-нибудь tVector3D, и не только ему, большая часть функциональности TObject не нужна.

лично моё решение:

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

TVector3D = record x,y,z: single; end;

естественно, сейчас прибежит куча людей и скажет: "а вот нету методов в рекордах у FPC!" (new-delphi не совместимость, кстати!).
на что у меня давно приготовлена библиотека с разнообразными функциями и процедурами, вида:

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

procedure v3dSomeMath(var v1,v2: TVector3d)
procedure v3daSomeMath(var v: array of TVector3D)

отсутствие каких-либо VMT и разыменовываний, делают код и "компактным" (ура 0<N<1024-byte сэкономил! ) и удобочитаемым.

Кроме того, такой код работает и на FPC и на Delphi одинаково. (Delphi уж очень остерегается использовать object-ы)

[zub]

>>лично моё решение:
>>TVector3D = record x,y,z: single; end;
>>естественно, сейчас прибежит куча людей и скажет: "а вот нету методов в рекордах у FPC!"

Иногда хочется еще иметь наследование. оно в delphi для record`ов не появилось?
object`ы не поддерживают, из record`ов делают object`ы. нафига?

главные плюсы object`а - возможность создания не в куче и наследование. это не record не class не заменит