Здравствуйте, A13x, Вы писали:

A>pimpl да не тот
Один в один. Дамаю, основная масса паттернов переделка базовых паттернов, т.е. по сути тоже что и прежде, только в профиль.

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

A>Т.е. у класса может быть ряд методов не нуждающихся в смене реализации + к тому ряд методов предполагающих использование стратегии могут предлагать реализацию по умолчанию, если стратегия не задана.
A>Вот утрированный пример (не из жизни):
Именно что утрированный, да и усложнённый. Того же можно достичь и через это:

class Strategy : public StrategyBase;

И размер ResultSet не увеличился.

Здравствуйте, rg45, Вы писали:

R>

R>
1. Ни в одном из классов в иерархии наследования не было определенных пользователем деструкторов
   R>
2. Ни в одном из классов в иерархии наследования не было полей с нетривиальным деструктором
   R>

R>Ну и зачем оно такое счастье?

Это всё пустое, так как для тривиальности деструктора требуется, так же, отсутствие виртуальности...

Здравствуйте, k.o., Вы писали:

KO>Если да, то я нигде не призывал, отказаться от вызова деструкторов, а всего лишь выразил сомнение в том, что обязательно будет UB.
1) формулировка странная. Так как UB -- это формальное состояние, когда с авторов реализации стандарт снимает всякую ответственность за последствия, то оно не может быть или не быть. Просто оно не всегда приводит к нежелательным последствиям...

2) Всё это ваше хаккерство опирается на то предположение, что если мы по одному и тому же адресу создадим такой выведенный объект или сякой, и приведём и тот и другой к указателю на базу, то получим один и тот же адрес. Гарантий этого на самом деле нет...

Ну и вообще в стандарте вроде есть прямой запрет на продолжение использования указателя на объект, после окончания времени жизни объекта...

Например, можно представить себе реализацию С++ (скажем интерпретатор), которая для пущей надёжности в каждом указателе хранит не только смещение относительно 0 плоской модели памяти, но и номер аллокации либо ещё какое-то ID, валидность которого проверяет при доступе...

Здравствуйте, k.o., Вы писали:

KO>недвусмысленно намекает на то, что работать мы будем через интерфейс. Разумеется, тот код требует некоторого допиливания, хотя бы потому, что он не компилируется, но ТС сразу написал, что это только идея. Я, впрочем, не буду спорить, что говорить о замене vptr несколько некорректно, т.к. мы просто используем память существующего объекта для создания нового.

Что-то сильно я сомневаюсь, что можно так вольно обращаться с полями. В конце концов, например, деструктор класса позовёт деструктор поля, а там уже совсем и не то...

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, A13x, Вы писали:

A>>pimpl да не тот
V>Один в один. Дамаю, основная масса паттернов переделка базовых паттернов, т.е. по сути тоже что и прежде, только в профиль.

Насчет переделки согласен, вопрос по большему счету философский. Кстати, в википедии вот пример тоже до подозрительности напоминает банальный pointer to implementation — http://en.wikipedia.org/wiki/Strategy_pattern

Здравствуйте, rg45, Вы писали:

R>А вот здесь я бы акцент все-таки поставил бы по-другому. UB не будет только в том случае, если есть гарантия того, что ни в одном из классов иерархии нет нетривиальных деструкторов. Вряд ли такое требование можно назвать типичным для иерархий с абстрактными классами во главе. В исходном сообщении такого ограничения также не накладывается — строчки "//реализация..." говорят о том, что в производных классах могут присутстовать члены с нетривиальными деструкторами. Видимо, Тот-кто-сидит-в-пруду, когда говорил о необходимости вызова деструкторов, также в качестве общего случая рассматривал (вполне обоснованно) ситуацию, когда классы имеют нетривиальные деструкторы.

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, rg45, Вы писали:

E>Может быть меня конечно глючит, например я могу путать стандарт и MSDN, но я точно помню, что в одном из этих двух документов утверждалось, что для тривиальности деструктора нужно ещё и отсутствие виртуальных баз и методов. Так что рассматриваемый случай с наследниками абстрактных классов совершенно точно не относится к тривиальным деструкторам...

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

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, k.o., Вы писали:

KO>>Если да, то я нигде не призывал, отказаться от вызова деструкторов, а всего лишь выразил сомнение в том, что обязательно будет UB.
E>1) формулировка странная. Так как UB -- это формальное состояние, когда с авторов реализации стандарт снимает всякую ответственность за последствия, то оно не может быть или не быть. Просто оно не всегда приводит к нежелательным последствиям...

Ну, учитывая, что исходный код даже не компилируется, говорить о наличии в нём UB не совсем корректно. Если же мы рассматриваем развитие этой идеи, то реальный код может быть разным, может быть с UB, может быть и без него. Это я и имел в виду говоря что там не обязательно будет UB.

E>2) Всё это ваше хаккерство опирается на то предположение, что если мы по одному и тому же адресу создадим такой выведенный объект или сякой, и приведём и тот и другой к указателю на базу, то получим один и тот же адрес. Гарантий этого на самом деле нет...

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

Автор: rg45
Дата: 05.04.11

E>Ну и вообще в стандарте вроде есть прямой запрет на продолжение использования указателя на объект, после окончания времени жизни объекта...

есть, но использовать указатель на новый объект, пусть и размещённый на месте старого, можно.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, k.o., Вы писали:

KO>>недвусмысленно намекает на то, что работать мы будем через интерфейс. Разумеется, тот код требует некоторого допиливания, хотя бы потому, что он не компилируется, но ТС сразу написал, что это только идея. Я, впрочем, не буду спорить, что говорить о замене vptr несколько некорректно, т.к. мы просто используем память существующего объекта для создания нового.

E>Что-то сильно я сомневаюсь, что можно так вольно обращаться с полями. В конце концов, например, деструктор класса позовёт деструктор поля, а там уже совсем и не то...

Ну, это уже претензии к c-smile, в исходном сообщении никаких полей не было, так что всё в порядке. Вообще это надо смотреть, что стандарт говорит по поводу POD полей (скорее всего ничего, т.е. это UB).

Здравствуйте, k.o., Вы писали:

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

Нет стандарта в быстром доступе.

Здравствуйте, k.o., Вы писали:

KO>есть, но использовать указатель на новый объект, пусть и размещённый на месте старого, можно.

Да, но гарантий того, что эти указатели совпадут таки нет...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, k.o., Вы писали:

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

E>Нет стандарта в быстром доступе.

можно черновик C++0x посмотреть, там, это почти не изменилось: здесь, тоже 12.4/4.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, k.o., Вы писали:

KO>>есть, но использовать указатель на новый объект, пусть и размещённый на месте старого, можно.

E>Да, но гарантий того, что эти указатели совпадут таки нет...

Так нам их и не надо, смотри по ссылке, что я тебе давал. Там, конечно, много букв, но, от этого ещё меньше хочется всё заново повторять.

Здравствуйте, k.o., Вы писали:

KO>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, k.o., Вы писали:

KO>>>есть, но использовать указатель на новый объект, пусть и размещённый на месте старого, можно.

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

E>>Да, но гарантий того, что эти указатели совпадут таки нет...

KO>Так нам их и не надо, смотри по ссылке, что я тебе давал. Там, конечно, много букв, но, от этого ещё меньше хочется всё заново повторять.

Здравствуйте, k.o., Вы писали:

KO>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, k.o., Вы писали:

KO>>>недвусмысленно намекает на то, что работать мы будем через интерфейс. Разумеется, тот код требует некоторого допиливания, хотя бы потому, что он не компилируется, но ТС сразу написал, что это только идея. Я, впрочем, не буду спорить, что говорить о замене vptr несколько некорректно, т.к. мы просто используем память существующего объекта для создания нового.

E>>Что-то сильно я сомневаюсь, что можно так вольно обращаться с полями. В конце концов, например, деструктор класса позовёт деструктор поля, а там уже совсем и не то...

KO>Ну, это уже претензии к c-smile, в исходном сообщении никаких полей не было, так что всё в порядке. Вообще это надо смотреть, что стандарт говорит по поводу POD полей (скорее всего ничего, т.е. это UB).

в C++0x можно (не будет UB) обращаться к полям класса с тривиальным деструктором после того как объект был разрушен. Правда, о том, что значения этих полей останутся прежними ничего не говорится.

Здравствуйте, k.o., Вы писали:

KO>И что такого волшебного в malloc? Можно использовать и new char[<size of storage for any implementation>] или вообще aligned_storage<(size of storage for any implementation)>::type storage;

Можно. В C++ вполне можно написать свой аллокатор и , вероятно, за счёт дополнительного знания об объектах он будет работать быстрее стандартного.

BFE>>А занимаясь такими вещами, мы делаем шаг в сторону С-- (здесь) или же в сторону Майкросовтовского CoCreateInstance.

KO>Какими такими?

Ну вот когда начинают думать об объектах не в абстрактных терминах , а в терминах объёма памяти и кусках адресных пространств, вот тогда и начинается... А на выходе получается (обычно) непереносимый код. Или же что-то вроде management С++, в котором простая операция доступа через указатель (вроде a->b) в шесь раз медленнее...

BFE>>Чем, собственно, не устраивает классический подход :

KO>Позволю себе процитировать ТС:
KO>

KO>Хочу использовать реализации интерфейсов без динамической реаллокации объектов реализующих их

Вот собственно это и интересно. Чем вызвано такое требование ? Это ограничение связано с реал-тайм или с контролем памяти ? Или же тут что-то ещё ? Или стандартный аллокатор настолько плох ?

Здравствуйте, A13x, Вы писали:

A>После уже второго такого обсуждения о хаке виртуальной таблицы стало интересно — а не наткнутся ли любители переписывать таблицы виртуальных методов на грабли в виде девиртуализации проведенной оптимизирующем компилятором?
+1.
Одна из форм UB.
Поэтому и нельзя реюзать указатели/ссылки на погибший объект, даже если ты там сконструировал что-то новое и вроде как ссылки/указатели остались валидными — компилятор знает, что они указывали на изначальный класс, и вправе генерить какой угодно код, исходя из этого предположения.
Помимо девиртуализации вызова, он может, например, просто закешировать указатель на vtbl при первой инициализации указателя, а не считывать его каждый раз при обращении по указателю (зачем делать два джампа, когда достаточно одного?) и таким образом продолжить обращаться к старой таблице даже после подмены, с сопутствующими фейерверками.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

E>Что-то сильно я сомневаюсь, что можно так вольно обращаться с полями. В конце концов, например, деструктор класса позовёт деструктор поля, а там уже совсем и не то...

На чем основаны твои сомнения?

Давай еще раз посмотрим на это дело:

#include <malloc.h>
#include <new.h>

struct Base
{
  int a;
  Base() {}
  virtual void foo() { ++a; printf("foo Base, %d\n",a);  }
};

struct Particular: public Base
{
  Particular() {}
  virtual void foo() { printf("foo Particular, %d\n",a);  }
};

int main()
{
   void* memory = calloc(1, sizeof Base); 
  
   Base* obj = new(memory) Base();
   obj->foo();
   new(memory) Particular();
   obj->foo();

   free(memory);
   return 0;
}

Какая конкретно строка здесь вызывает сомнения?

Здравствуйте, A13x, Вы писали:

A>После уже второго такого обсуждения о хаке виртуальной таблицы стало интересно — а не наткнутся ли любители переписывать таблицы виртуальных методов на грабли в виде девиртуализации проведенной оптимизирующем компилятором?

A>Знаю, что современные компиляторы в ряде случаев могут использовать т.н. девиртуализацию — прямой вызов функции (или даже inline подстановка) в месте вызова функции.

Хотел бы я посмотреть на компилятор делающий "девиртуализацию" COM или Corba интерфейсов которые есть сугубо abstract classes.
COM и Corba интерфейсы имеют форму понимаемую и C++ и C. Т.е. всегда возможно получить доступ к vtbl полю. Хотя бы зайдя через C.

Конечно это будет хак и ересь с точки зрения Vovan the Programmer. Но с точки зрения разработчика COM/Corba cores обычная такая себе фича.

placement new C++ для замены vtbl это конечно не тот кунштюк который рекомендован для использования детям дошкольного возраста.
Просто надо знать что есть такая фича и она работает by C++ nature. Но использовать надо осознанно и по делу. Как всегда в C++ впрочем.
На войне как на войне.

Здравствуйте, k.o., Вы писали:


E>>Да, но гарантий того, что эти указатели совпадут таки нет...

KO>Так нам их и не надо, смотри по ссылке, что я тебе давал. Там, конечно, много букв, но, от этого ещё меньше хочется всё заново повторять.

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