История изменений

Изолированные типы, не связаны ни в какие иерархии иине знающие ничего о других

а у вас типы всегда изолированы? вы принципиально отказываетесь относить ворон, воробьев и уток к птицам, собак и кошек к млекопитающим, а ах всех к живой природе?

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

в данном случае принтеры и сканеры вовсе не изолированы, а относятся к суперклассу «офисные устройства», что видно невооруженым взглядом. и даже если у них как будто нет общих свойств. и такой суперкласс можно записать пустым базовым классом, явно указав на их некую общность, но без разделения конкретных свойств.

Отсутствие явных кастов к конкретным типам в месте вызова

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

вы собственно написали своим вариантом

struct {
  int tag_;
  union{
    T1 t1_;
    T2 t2_;
    T3 t3_;
  };
};

и три функции визитора, которые будут выбираться свичом, по тегу с реинтерпрет кастом на начало union. замотали это в шаблон и назвали правильным ООП? Это в си так делают, где ООП нет.

Можно налагать любые требования на интерфейс объектов в месте вызова.

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

ваш типа способ еще слаб и тем, что

1. нельзя написать уже готовое обобщенное хранилище под расширяемую иерархию классов(впрочем вы ее отрицаете похоже). при каждом расширении придется переинстанцировать шаблон.

2. хранилища такого рода будут друг с другом несовместимы, то есть визиторы для storage <A,B> будут несовместимы с визиторами для storage <A,B,C>. то есть вы порождаете лапшу из классов на все случаи жизни, и число инстанцированных сущностей растет пропорционально числу хранилищ * число хранимых классов.

3. у вас неправильный визитор для Foo. он там зовет и принт и скан одновременно. так не бывает для принтеров со сканерами.

ps. что что будет если я напложу 100 наследников класса принтер, под разные модели принтеров, и 50 разных сканеров, и попытаюсь их положить в ваше хранилише?

pss. явного реинтерпрет каста там не будет, в силу волшебных свойств union.

Изолированные типы, не связаны ни в какие иерархии иине знающие ничего о других

а у вас типы всегда изолированы? вы принципиально отказываетесь относить ворон, воробьев и уток к птицам, собак и кошек к млекопитающим, а ах всех к живой природе?

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

в данном случае принтеры и сканеры вовсе не изолированы, а относятся к суперклассу «офисные устройства», что видно невооруженым взглядом. и даже если у них как будто нет общих свойств. и такой суперкласс можно записать пустым базовым классом, явно указав на их некую общность, но без разделения конкретных свойств.

Отсутствие явных кастов к конкретным типам в месте вызова

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

вы собственно написали своим вариантом

struct {
  int tag_;
  union{
    T1 t1_;
    T2 t2_;
    T3 t3_;
  };
};

и три функции визитора, которые будут выбираться свичом, по тегу с реинтерпрет кастом на начало union. замотали это в шаблон и назвали правильным ООП? Это в си так делают, где ООП нет.

Можно налагать любые требования на интерфейс объектов в месте вызова.

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

ваш типа способ еще слаб и тем, что

1. нельзя написать уже готовое обобщенное хранилище под расширяемую иерархию классов(впрочем вы ее отрицаете похоже). при каждом расширении придется переинстанцировать шаблон.

2. хранилища такого рода будут друг с другом несовместимы, то есть визиторы для storage <A,B> будут несовместимы с визиторами для storage <A,B,C>. то есть вы порождаете лапшу из классов на все случаи жизни, и число инстанцированных сущностей растет пропорционально числу хранилищ * число хранимых классов.

3. у вас неправильный визитор для Foo. он там зовет и принт и скан одновременно. так не бывает для принтеров со сканерами.

ps. что что будет если я напложу 100 наследников класса принтер, под разные модели принтеров, и 50 разных сканеров, и попытаюсь их положить в ваше хранилише?

Изолированные типы, не связаны ни в какие иерархии иине знающие ничего о других

а у вас типы всегда изолированы? вы принципиально отказываетесь относить ворон, воробьев и уток к птицам, собак и кошек к млекопитающим, а ах всех к живой природе?

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

в данном случае принтеры и сканеры вовсе не изолированы, а относятся к суперклассу «офисные устройства», что видно невооруженым взглядом. и даже если у них как будто нет общих свойств. и такой суперкласс можно записать пустым базовым классом, явно указав на их некую общность, но без разделения конкретных свойств.

Отсутствие явных кастов к конкретным типам в месте вызова

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

вы собственно написали своим вариантом

struct {
  int tag_;
  union{
    T1 t1_;
    T2 t2_;
    T3 t3_;
  };
};

и три функции визитора, которые будут выбираться свичом, по тегу с реинтерпрет кастом на начало union. замотали это в шаблон и назвали правильным ООП? Это в си так делают, где ООП нет.

Можно налагать любые требования на интерфейс объектов в месте вызова.

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

ваш типа способ еще слаб и тем, что

1. нельзя написать уже готовое обобщенное хранилище под расширяемую иерархию классов(впрочем вы ее отрицаете похоже). при каждом расширении придется переинстанцировать шаблон.

2. хранилища такого рода будут друг с другом несовместимы, то есть визиторы для storage <A,B> будут несовместимы с визиторами для storage <A,B,C>. то есть вы порождаете лапшу из классов на все случаи жизни, и число инстанцированных сущностей растет пропорционально числу хранилищ * число хранимых классов.

3. у вас неправильный визитор для Foo. он там зовет и принт и скан одновременно. так не бывает для принтеров со сканерами.

Изолированные типы, не связаны ни в какие иерархии иине знающие ничего о других

а у вас типы всегда изолированы? вы принципиально отказываетесь относить ворон, воробьев и уток к птицам, собак и кошек к млекопитающим, а ах всех к живой природе?

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

в данном случае принтеры и сканеры вовсе не изолированы, а относятся к суперклассу «офисные устройства», что видно невооруженым взглядом. и даже если у них как будто нет общих свойств. и такой суперкласс можно записать пустым базовым классом, явно указав на их некую общность, но без разделения конкретных свойств.

Отсутствие явных кастов к конкретным типам в месте вызова

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

вы собственно написали своим вариантом

struct {
  int tag_;
union{
  T1 t1_;
  T2 t2_;
  T3 t3_;
};

и три функции визитора, которые будут выбираться свичом, по тегу с реинтерпрет кастом на начало union. замотали это в шаблон и назвали правильным ООП? Это в си так делают, где ООП нет.

Можно налагать любые требования на интерфейс объектов в месте вызова.

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

ваш типа способ еще слаб и тем, что

1. нельзя написать уже готовое обобщенное хранилище под расширяемую иерархию классов(впрочем вы ее отрицаете похоже). при каждом расширении придется переинстанцировать шаблон.

2. хранилища такого рода будут друг с другом несовместимы, то есть визиторы для storage <A,B> будут несовместимы с визиторами для storage <A,B,C>. то есть вы порождаете лапшу из классов на все случаи жизни, и число инстанцированных сущностей растет пропорционально числу хранилищ * число хранимых классов.

3. у вас неправильный визитор для Foo. он там зовет и принт и скан одновременно. так не бывает для принтеров со сканерами.

Изолированные типы, не связаны ни в какие иерархии иине знающие ничего о других

а у вас типы всегда изолированы? вы принципиально отказываетесь относить ворон, воробьев и уток к птицам, собак и кошек к млекопитающим, а ах всех к живой природе?

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

в данном случае принтеры и сканеры вовсе не изолированы, а относятся к суперклассу «офисные устройства», что видно невооруженым взглядом. и даже если у них как будто нет общих свойств. и такой суперкласс можно записать пустым базовым классом, явно указав на их некую общность, но без разделения конкретных свойств.

Отсутствие явных кастов к конкретным типам в месте вызова

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

вы собственно написали своим вариантом

struct {
  int tag_;
union{
  T1 t1_;
  T2 t2_;
  T3 t3_;
};

и три функции визитора, которые будут выбираться свичом, по тегу с реинтерпрет кастом на начало union. замотали это в шаблон и назвали правильным ООП? Это в си так делают, где ООП нет.

Можно налагать любые требования на интерфейс объектов в месте вызова.

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

ваш типа способ еще слаб и тем, что

1. нельзя написать уже готовое обобщенное хранилище под расширяемую иерархию обьектов. при каждом расширении придется переинстанцировать шаблон.

2. хранилища такого рода будут друг с другом несовместимы, то есть визиторы для storage <A,B> будут несовместимы с визиторами для storage <A,B,C>. то есть вы порождаете лапшу из классов на все случаи жизни, и число инстанцированных сущностей растет пропорционально числу хранилищ * число хранимых классов.

3. у вас неправильный визитор для Foo. он там зовет и принт и скан одновременно. так не бывает для принтеров со сканерами.