Проверить выделена ли память под объект

[BOBAH13]

Сообщение от Utkin

Вот и напрасно - ТС требуется удаление объектов не в определенной последовательности, а так как вздумается высшим силам (пользователю).

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

[Sibedir]

Сообщение от GunSmoker

Далее, пример №2 анализу не поддаётся, так как не сказано, что здесь является объектом, а что - состоянием объекта. Где куда какая ссылка вписывается - тоже не ясно.

В моей программе пользователь сможет создавать математическую модль физической системы. Т.е. шарик и нитка - это экземпляты некоего TSomeSibObject = class (TSibObject).
Пользователь пишет что-то типа скрипта. Типа того:

1. Создать объект
Тип: Узел-связь
Имя: Точка крепления
X, Y, Z: (0, 0, 0)
2. Создать объект
Тип: Нить
Имя: Нить1
P1: <Точка крепления>
P2: (1, 1, 0)
... (сечение, плотность, модуль деформации, прочность и т.д.)
3. Создать объект
Тип: Тело
Имя: Нить1
P1: Нить1.P2
P2: ...
P3: ...
... (геометрия, плотность, и т.д.)
4. Запускаем цикл имитирующий подъем шарика. Если система уравновесилась и находится в относительном покое, снимаем какие-то данные и завершаем работу. Если нить не выдержала переходим на 5.
5. Удаляем нить. Запускаем цикл имитирующий свободный подъем шарика (допустим в течении 5 сек) (по сути это тот же цикл из 4, только не обрабатывается нить, т.к. она удалена). Снимаем какие-то данные и завершаем работу.

Повторюсь. Скрипт пишет юЗверь. Он может дать команду именно
1. Удалить нить
, а не
1. Тело.P1 := Создать глобальную точку
2. Тело.P1.Assign (Нить1.P2)
3. Удалить нить

[GunSmoker]

Ну так и делайте связь отдельным объектом.

type
  TLink = class;

  TLinkableObject = class
  private
    FLink: TLink;
    function GetLinkedObject: TLinkableObject;
  public 
    destructor Destroy; override;
    property LinkedObject: TLinkableObject read GetLinkedObject;
  end;

  TLink = class
  private
    FUp, FDown: TLinkableObject;
  public
    constructor Create(AObj1, AObj2: TLinkableObject);
    destructor Destroy; override;
    property Up: TLinkableObject read FUp write FUp; 
    property Down: TLinkableObject read FDown write FDown;
  end;

destructor TLinkableObject.Destroy; 
begin
  if Assigned(FLink) then
    FreeAndNil(FLink);
  inherited;
end;

function TLinkableObject.GetLinkedObject: TLinkableObject;
begin
  Result := nil;
  if FLink = nil then
    Exit;
  if FLink.FUp = Self then
    Result := FLink.FDown
  else
  begin
    Assert(FLink.FDown = Self);
    Result := FLink.FUp;
  end;
end;

constructor TLink.Create(AObj1, AObj2: TLinkableObject);
begin
  inherited Create;

  Assert(Assigned(AObj1));
  Assert(Assigned(AObj2));
  Assert(not Assigned(AObj1.FLink));
  Assert(not Assigned(AObj2.FLink));
 
  FUp := AObj1;
  FDown := AObj2;

  AObj1.FLink := Self;
  AObj2.FLink := Self;
end;

destructor TLink.Destroy; 
begin
  inherited;
 
  if Assigned(FUp) then
    FUp.FLink := nil;
  if Assigned(FDown) then
    FDown.FLink := nil;
end;

Но лучше, конечно, на интерфейсах.

[Sibedir]

Ну так и делайте связь отдельным объектом.

М-м-м, кол-во связей Ns может превышать кол-во самих обектов No во много раз
Ns ~ No^2 (в задаче о нескольких гравитирующих телах и подобных ей)

Но лучше, конечно, на интерфейсах.

Т.е. по принципу поста #29 (только счетчик автоматический)?

Вы мне вот все про интерфейсы твердите, а конкретно ничего не говорите. Ответте, пожалуйста, на вопросы в посте #29.

[GunSmoker]

Если готовое примеры кода и указание на готовые реализации - это не конкретно, то что ж для вас конкретно? Программу за вас написать?

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

Не забивайте голову ерундой.

Просто не вижу смысла использования именно интерфейсов.

А вы в программе String используете? А почему не указатели с ручным выделением и освобождение памяти? Так же и интерфейсы. "Не так" пойти не может. Меньше поле для ошибок. Автоматизация. Удобно.

Счетчик прикрутить к классу - минутное дело.

Чего всех так тянет изобретать велосипеды вместо изучения существующих инструментов?

М-м-м, кол-во связей Ns может превышать кол-во самих обектов No во много раз

Ну и что? Связь по-любому надо где-то хранить. Можно подумать, что если вы сделаете связь не объектом, она перестанет занимать место.

Вводится:
- для обеспечения общности предка всех объектов (консенсус м/у грамоздким TComponent и нефункциональным и разобщенным использованием множества разных потомков TObject)
- для единообразия храниения данных (обеспечивается единый механизм сохранения, загрузки, конвертации)
- для обеспечения работы еще нескольких общих механизмов (удаление, логические и математические взаимосвязи, отслеживание изменений и пр.)

Ещё один велосипед. Это называется TPersistent.

[GunSmoker]

Каков размер предметной области? Просто может оказаться, что объекты здесь вообще не в тему, а вот БД - в самый раз.

На БД же намекает ваше желание экономить на копейках.

[Sibedir]

Если готовое примеры кода и указание на готовые реализации - это не конкретно, то что ж для вас конкретно? Программу за вас написать?

GunSmoker, я не такой лох, чтобы не суметь написать объект-связь. Мне как раз готовый код не нужен. Мне нужно ЛОГИЧЕСКОЕ ОБОСНОВАНИЕ с указанием на механизм реализации (как оно работает изнутри).

Не забивайте голову ерундой.

Чего всех так тянет изобретать велосипеды вместо изучения существующих инструментов?

Ага, зачем вникать? Делай как все и будет тебе счастье. Сомнительное счастье использовать готовые решения без осмысливания их работы приминительно к своей задаче.
Я не забиваю голову ерундой, а пытаюсь разобраться. И пока ни одного достойного довода в пользу интерфейсов (кроме наличия счетчика и автоудаления, что само по себе еще не благо) я не услышал.

А вы в программе String используете? А почему не указатели с ручным выделением и освобождение памяти?

Потому что этот велосипед (String) меня почти-полностью устраивает. Он работает просто, надежно и достаточно быстро (в умелых руках).

Ну и что? Связь по-любому надо где-то хранить. Можно подумать, что если вы сделаете связь не объектом, она перестанет занимать место.

Согласен, чем-то пожертвовать придется. Вопрос в том, как сделать эту связь более компактной и быстрой в работе. А ваш код мне очень даже нравится.

Ещё один велосипед. Это называется TPersistent.

Что есть такого у TPersistent особого? Несколько пустых и еще пара не нужных мне методов?

Каков размер предметной области? Просто может оказаться, что объекты здесь вообще не в тему, а вот БД - в самый раз.

Не-е-е. БД вообще не вариант. Работать с десятком тысяч данных через запросы? Да меня мой собственный одноядерный проц застрелит, или еще хуже руки на себя наложит.

Постораюсь пояснить, чем меня так смущают интерфейсы.
Вот классы меня не смущают. Там все просто. Каждый метод имеет свой точный адрес (относительно адреса класса). При вызове любого метода, как и при обращении к полю, компилятор вставляет 1 указатель на вызываемый метод. С интерфейсами же так быть не может по определению. Один и тот же интерфейс можно прикрутить к сотне классов. А при обращении к методу, объявленному в интерфейсе через экземпляр среднего рода (я могу не знать класс, и комп может его заранее не знать), мотод таки найдется. Но мы не знали его точное расположение. Только имя. Следовательно произошел некий скрытый поиск. Следовательно программа потратила "лишнее" время. Я не знаю этого точно, потому-то мне это и не нравится. Я ни когда не сяду за руль автомобиля, не зная принцип его работы. Автобус ездит так же как легковая, но за легковушку я сяду, а за руль автобуса - ищите другого камикадзе.

[Sibedir]

Хм. А вот вполне, как мне кажется, разумное решение. Правда, при "неправильном" использовании может привести к "засеранию" памяти.

Можно переопределить метод NewInstance и создавать объект в новой куче. Перед указателем добавляем новое поле со смещением _Assigned = -X. Туда при инициализации записывать True, а при уничтожении False. Естественно, это место в куче будет застолблено (вот оно "засерание"), пока не будет произведена ревизия ссылок.
А теперь добавляем

function TMyObject.Assigned: Boolean;
begin
  Result := PBoolean(Integer(Self) + _Assigned)^;
end;

[Sibedir]

Вот чего накропал:
Выделина ли память.zip
Знаю, что не правильно. Очень хотелось бы услышать мнение тех, кто знает, как GetMem выделяет память.

[GunSmoker]

Sibedir, без обид, но ваши "изобретения" выглядят ровно так же, как попытки Utkin-а изобрести результат операции деления на ноль.

Совет: не маяться фигнёй.