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

Соответственно, он не ломается от расширения числа обобщаемых классов, в отличие от портянки if-ов с динамик кастом к каждому конкретному типу

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

любое добавление класса будет локальным - надо будет написать класс наследник от сканера/принтера/принтсканера, и виртуальную функцию…или виртуальные функции тоже отменили??? и создав обьект данного класса пихнуть его в хранилище.

у вас же все 150 сканеров-принтеров надо явно обьявить в одном месте - в инстанцировании шаблона варианта. причем декларации всех 150 типов должны быть видны.

причем вся изюмина такой «шаблонизации» в наличии юниона в си. тут даже с++ не причем.

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

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

у вас же просто шаблон для скана всего хранилища и вызова однотипных функций на обьектах. то есть задача вообще не та.

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

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

Соответственно, он не ломается от расширения числа обобщаемых классов, в отличие от портянки if-ов с динамик кастом к каждому конкретному типу

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

любое добавление класса будет локальным - надо будет написать класс наследник от сканера/принтера/принтсканера, и виртуальную функцию…или виртуальные функции тоже отменили??? и создав обьект данного класса пихнуть его в хранилище.

у вас же все 150 сканеров-принтеров надо явно обьявить в одном месте - в инстанцировании шаблона варианта. причем декларации всех 150 типов должны быть видны.

причем вся изюмина такой «шаблонизации» в наличии юниона в си. тут даже с++ не причем.

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

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

у вас же просто шаблон для скана всего хранилища и вызова однотипных функций на обьектах. то есть задача вообще не та.

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

Соответственно, он не ломается от расширения числа обобщаемых классов, в отличие от портянки if-ов с динамик кастом к каждому конкретному типу

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

любое добавление класса будет локальным - надо будет написать класс наследник от сканера/принтера/принтсканера, и виртуальную функцию…или виртуальные функции тоже отменили??? и создав обьект данного класса пихнуть его в хранилище.

у вас же все 150 сканеров-принтеров надо явно обьявить в одном месте - в инстанцировании шаблона варианта. причем декларации всех 150 типов должны быть видны.

причем вся изюмина такой «шаблонизации» в наличии юниона в си. тут даже с++ не причем.

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

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

у вас же просто шаблон для скана всего хранилища и вызова однотипных функций на обьектах. то есть задача вообще не та.

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

Соответственно, он не ломается от расширения числа обобщаемых классов, в отличие от портянки if-ов с динамик кастом к каждому конкретному типу

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

любое добавление класса будет локальным - надо будет написать класс наследник от сканера/принтера/принтсканера, и виртуальную функцию…или виртуальные функции тоже отменили??? и создав обьект данного класса пихнуть его в хранилище.

у вас же все 150 сканеров-принтеров надо явно обьявить в одном месте - в инстанцировании шаблона варианта. причем декларации всех 150 типов должны быть видны.

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

причем вся изюмина такой «шаблонизации» в наличии юниона в си. тут даже с++ не причем.

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

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

у вас же просто шаблон для скана всего хранилища и вызова однотипных функций на обьектах. то есть задача вообще не та.

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

Соответственно, он не ломается от расширения числа обобщаемых классов, в отличие от портянки if-ов с динамик кастом к каждому конкретному типу

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

любое добавление класса будет локальным - надо будет написать класс наследник от сканера/принтера/принтсканера, и виртуальную функцию…или виртуальные функции тоже отменили??? и создав обьект данного класса пихнуть его в хранилище.

у вас же все 150 сканеров-принтеров надо явно обьявить в одном месте - в инстанцировании шаблона варианта. причем декларации всех 150 типов должны быть видны.

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

причем вся изюмина такой «шаблонизации» в наличии юниона в си. тут даже с++ не причем.

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

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

у вас же просто шаблон для скана всего хранилища и вызова однотипных функций на обьектах. то есть задача вообще не та.

Соответственно, он не ломается от расширения числа обобщаемых классов, в отличие от портянки if-ов с динамик кастом к каждому конкретному типу

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

любое добавление класса будет локальным - надо будет написать класс наследник от сканера/принтера/принтсканера, и виртуальную функцию…или виртуальные функции тоже отменили??? и создав обьект данного класса пихнуть его в хранилище.

у вас же все 150 сканеров-принтеров надо явно обьявить в одном месте - в инстанцировании шаблона варианта. причем декларации всех 150 типов должны быть видны.

причем вся изюмина такой «шаблонизации» в наличии юниона в си. тут даже с++ не причем.

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

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

у вас же просто шаблон для скана всего хранилища и вызова однотипных функций на обьектах. то есть задача вообще не та.