Задачи на знание ООП, (только для Турбо-Паскаля 7.0) Опции

[Bokul]

Супер, спасибо!!!

any_arr.count_each(new(PTfloat));

А можно брать TypeOf типа? У него же нет VMT... Или есть?

[volvo]

А можно брать TypeOf типа? У него же нет VMT...

Смотрим в документацию:

TypeOf (function)
Returns a pointer to an object type's virtual method table.

Declaration:
procedure TypeOf (Param1: ObjectType) : Pointer
Remarks:
Param1 is either an object type identifier or an instance of an object type.
Can only be applied to object types that have a VMT; all other types result in an error.

Значит, можно А почему? У типа действительно нет VMT... У него вообще ничего нет, главное, чтобы VMT могла быть у экземпляра этого типа...

[Bokul]

Спойлер (Показать/Скрыть)

Уже какой раз пытаюсь написать ответ, постоянно вытираю - нету полного понимания. Остановился вот на чем:
Будет ошибка, в any_arr.set_index(1, obj_int); мы вместо указателя на объект-предок T, даем указатель на его наследника, который занимает больший (в любом случае другой) размер в памяти. Типизированный указатель - это только адрес первого байта данных . Как мы узнаем, где находится его конец? Адрес + sizeof(тип указателя). А так как вместо ожидаемого типа, мы даем другой, то должна произойти "обрезание" передаваемого объекта, т.е. укаатель на него будет "не полным" . И потом typeof скопирует себе не весь объект, а только его часть и при попытки обратится к объекту, чтобы узнать его VMT, получим ошибку. ИМХО. Хотя...

Сообщение отредактировано: Bokul - 26.11.2006 4:56

[volvo]

Bokul Не будет того, что ты написал:

Спойлер (Показать/Скрыть)

Дело все в том, что функция TypeOf ничего никуда не копирует... если бы она работала так, как ты написал - в нем бы вообще смысла не было: это была бы просто функция, позволяющая в Compile-Time определить тип объекта... А зачем мне тогда привязываться к VMT? Дело все в том, что TypeOf возвращает адрес VMT для объекта (или типа, в RunTime уже созданы все таблицы причем в единственном экземпляре для каждого объектного типа, что позволяет программе определить, где БУДЕТ находиться VMT экземпляра объекта, когда он будет создан)...

Как мы узнаем, где находится его конец?

А оно нам надо?

Руководство по языку B.Pascal 7 & Objects/LR -> Таблица виртуальных методов

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

, так что же получается? Если объектный тип имеет таблицу виртуальных методов, то у всех его потомков тоже гарантированно будут свои таблицы, так? Таблица создается всегда, кстати... Даже если не вызвать конструктор. Конструктор - он ведь только устанавливает в экземпляре объекта ссылку на VMT, поэтому, кстати, если НЕ вызвать конструктор, а вызвать виртуальный метод - система или зависнет, или тебя просто выбросит в General Protection Fault (поскольку ты не в чистом DOS-е). Причина - программа НЕ ЗНАЕТ, где расположена VMT, но таблица-то есть...

А если таблица есть и у предка, и у потомка, то логично будет предположить, что адреса хранятся в одном и том же месте? Так зачем КОНЕЦ объекта? Компилятору важно правильно добраться до того места, где хранится адрес, а это место гарантированно существует уже в предке - следовательно, все нормально...

Так что, твои рассуждения не верны... ТАМ где ты думаешь, ошибки не будет...

[мисс_граффити]

У него вообще ничего нет, главное, чтобы VMT могла быть у экземпляра этого типа...

Значит, я слегка увлеклась и

obj_int^.Create; 
...
obj_float^.create; 

на компиляцию не повлияют. что с ними, что без них...

volvo, я же уточнила, что код будет только компилироваться. Это, конечно, для корректной работы необходимо, но не достаточно.
По поводу корректной работы.

Спойлер (Показать/Скрыть)

procedure TArr.set_index(i: integer; p: PT);
begin if i <= maxSize then arr[i] := p; end;

при такой передаче p (при помощи указателя, да еще и без var ) приведение типов не осуществляется. в итоге у нас будет указатель на класс-наследник (тип у него будет наследниковский, то есть TFloat), однако поля и методы, введенные в наследнике, доступны не будут (ну это нам и не нужно в данной программе)....
Итак, в результате мы получим странный массив, в котором один элемент - указатель на TFloat, один на TInt, а остальные - на нечто непонятное. То есть тип этого непонятного определяться будет, но он не совпадет ни с типом T, ни с типами его наследников.
аналогичная ситуация и с вызовом для new(PT) - экземпляра нет, VMT не создана. Определить-то тип определим, но какой.....
Получим count=0
А вот если вызвать

any_arr.count_each(obj_float);

- получим count=1.

[volvo]

мисс_граффити Да ты что? Не будет и этого Два предположения из твоих трех - ошибочны...

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

[мисс_граффити]

Расскажешь, как на самом деле?

[volvo]

Расскажешь, как на самом деле?

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

Спойлер (Показать/Скрыть)

Значит, так... Ошибка (вернее, недочет, который выявится при некоторых установках IDE Турбо-Паскаля, ну, и естественно, в любом 32-битном компиляторе) номер один:

  for i := 1 to maxSize do
    if typeof(arr[ i ]^) = typeof(p^) then inc(count); { <--- Здесь ... }

А именно - в попытке разыменования нулевого указателя (большинство компиляторов все-таки инициализируют все элементы arr nil-ом, потому, что эта переменная размещается не в стеке, а в куче)

исправляется очень просто:

  for i := 1 to maxSize do
    if (arr[ i ] <> nil) and (typeof(arr[ i ]^) = typeof(p^)) then inc(count);

Второе:

в результате мы получим странный массив, в котором один элемент - указатель на TFloat, один на TInt, а остальные - на нечто непонятное.

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

[i]Вот, кстати, еще одна причина при создании класса явно инициализировать все его члены либо сразу нужными значениями, либо нулем (или соответствующим ему значением для типа поля): если бы все было проинициализировано нулями, программа вылетела бы независимо от ключей компиляции, а это лучше, чем выдывать похожий на правду результат, а при определенных условиях начать сбоить...

Третье: для того, чтобы процедура count_each работала корректно (выдавала правильный результат), достаточно передать в нее указатель на объект, с инициализированной VMT, т.е. или так, как показала мисс_граффити - передать один из ранее использованных указателей, для которого вызывался Create, или

any_arr.count_each(new(PTfloat, create));

Но, если кто-то подумал, что это - все... Нет... Есть еще кое-что... memory leaks, в связи с чем

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

О том, что это за структура: Это что-то напоминающее кортеж языка Python, только с изменяемыми элементами...

[мисс_граффити]

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

Спойлер (Показать/Скрыть)

Добавляем явное "засовывание" в arr[3] указателя на T:

var
  TT: ^T;
  obj_int: ^Tint;
  obj_float: ^Tfloat;
  any_arr: TArr;
begin
  any_arr.init;
  obj_int := new(PTint);
  obj_int^.Create;
  obj_int^.value := 3;
  any_arr.set_index(1, obj_int);
  obj_float := new(PTfloat);
  obj_float^.create;
  obj_float^.value := 3.5;
  any_arr.set_index(2, obj_float);
  TT:=new(PT);
  TT^.create;
  any_arr.set_index(3,TT);

А теперь делаем Evaluate:
typeof(any_arr.arr[1]^) Ptr(DSeg,$A)
typeof(any_arr.arr[2]^) Ptr(DSeg,$12)
typeof(any_arr.arr[3]^) Ptr(DSeg,$2)
typeof(any_arr.arr[4]^) Ptr(DSeg,$1068)
Почему так?
И разве сравниваться будут не эти значения?

[volvo]

Почему так?

А что, собственно, вызывает сомнения? Три объекта в иерархии, три адреса VMT... То, что есть четвертое значение?

Так сделай

any_arr.set_index(4, nil);

и посмотри на содержимое Evaluate ...arr[4]^ и ...arr[5]^

[мисс_граффити]

те же Ptr(DSeg,$1068)
соответственно, typeof(arr[4]^)<>typeof (объект одного из классов T,TInt,TFloat)
так?
или я что-то совсем неправильно понимаю?

[volvo]

Ну, естественно... Какой же тип у NIL-а? Вообще-то, обращение по nil^ приводит к тому, что в С++ называется UB (Undefined Behavior)... НЕЛЬЗЯ этого делать... Поэтому, какой бы результат ты не получила - он будет некорректным, если значение указателя эквивалентно NIL

[Bokul]

Спасибо за ссылку.

Дело все в том, что TypeOf возвращает адрес VMT для объекта

Т.е. она просто читает это поле:

Это 16-битовое поле, называемое полем таблицы виртуальных методов (VMP), используется для запоминания
смещения таблицы виртуальных методов в сегменте данных.

?

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

Так поможет?

var
  obj_int: ^Tint;
  obj_float: ^Tfloat;
  any_arr: TArr;
 p:pointer;
begin
  mark(p);{запоминаем в p границу текущей не занятой памяти}
  any_arr.init;
  obj_int := new(PTint);
  obj_int^.Create; 
  obj_int^.value := 3;
  any_arr.set_index(1, obj_int);
  obj_float := new(PTfloat);
  obj_float^.create; 
  obj_float^.value := 3.5;
  any_arr.set_index(2, obj_float);
  any_arr.count_each(new(PTfloat));
  release(p);{освобождаем всю занятую память - от p и до конца кучи}
end.

[volvo]

Нет, так не пойдет... Это не выход... Ты не убираешь утечки, а просто стираешь следы их присутствия... Я имел в виду "не допускать появления утечек"...

P.S. Заметь, я не сказал "Не изменяя объекты", я сказал "Не изменяя иерархию", т.е. не добавляя новых типов перед базовым, и между предком и потомком...

[мисс_граффити]

Ну, естественно... Какой же тип у NIL-а?

вот я его непонятным и обозвала...
и написала, что он определится, но как...

[Bokul]

где именно происходят в этой программе утечки памяти

Утечка происходит тогда, когда мы берем больше с кучи, чем возвращаем, да? Если да, то я не вижу ни одного dispose в проге... Или я что-то путаю?

[volvo]

Если да, то я не вижу ни одного dispose в проге

Да... Вот я и не поставил Dispose... Попробуешь сделать это?

[Bokul]

Да... Вот я и не поставил Dispose...

Это хорошо, а я ищу не знаю что...

Попробуешь сделать это?

Ага, теперь ясно в чем задача.

any_arr.count_each(new(PTfloat, create ));

Я так понял, что мы остановились на таком вызове этого метода? Сдесь не происходит выделения памяти кроме как для указателя?

[volvo]

Я так понял, что мы остановились на таком вызове этого метода? Сдесь не происходит выделения памяти кроме как для указателя?

Как так не происходит? А экземпляр объекта где хранится? Не в указателе же...

[Bokul]

Как так не происходит? А экземпляр объекта где хранится? Не в указателе же...

any_arr.count_each(new(PTfloat, create ));

Ну тогда все понятно, мы передаем указатель на объект в процедуру any_arr.count_each (не зная его), он там копируется. Выходит мы получаем два указателя на один объект - один локальный (копия) и второй - который мы не знаем. Мне интересно, что делает Паскаль с этим неизвестным? От этого и зависит, наверное, решение... ИМХО.

Сообщение отредактировано: Bokul - 27.11.2006 2:54