Я надеваю свой шаблонный плащ и шаблонную шляпу...

Была у меня иерархия (классов) на основе вложенности, A содержит вектор объектов B, который в свою очередь содержит вектор объектов С. Всё ок.

Объекты класса C содержали ещё вектор объектов класса D, возможно пустой. Класс D содержал shared_ptr<C>. Чтобы было нагляднее, класс D, это, например, персонаж, а класс C - это клетка карты. Таким образом D всегда находится на какой-то клетке, держит с ней связь через shared_ptr<C>, а клетка содержит в себе список персонажей, которые на ней находятся. Всё ок, всё работало. Тут важный момент про конструкции языка: так как C и D ссылаются друг на друга, то в одном из их заголовков будет упоминание другого .

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



это породило цепную реакцию шаблонизации всей иерархии классов вплоть до класса A, и там есть ещё 3 обслуживающих класса (тоже шаблоны) которые используют A и друг друга в качестве параметра шаблона. Все эти классы (кто-то ещё раз) ошаблонились. Там тоже есть интересный вопрос по синтаксису, но это всё потом, главное - проблема теперь в C и D. По задумке слабой связанности, С теперь не имеет вектор с D, но есть C1<T>, у которого вектор<T> и функции работы с ним. D теперь без указателя shared_ptr<C>, но есть D1<T> у которого shared_ptr<T> и методы работы с ним.

Всё ок, до тех пор пока не начнёшь всё это создавать, потому что должно быть D1<C1> и C1<D1>, как это сделать? Выше я упоминал, что в случае обычной ссылки друг на друга, один из классов упоминается в заголовке другого и всё хорошо. А как тут быть? Попытался поразбивать C/C1 и D/D1 на иерархии и как-то использовать другие классы в качестве параметров шаблонов, но только всё запутал.

В результате шаблонной магии я вчера развалил себе весь проект напрочь(damage 281 hp per class), т.е. сейчас у меня ни одного работающего класса нет, так как все зависят от D и C.

Anatoly MoskovskyА с чего вы решили, что это хоть как-то устраняет зависимость? )))Изначальные классы друг о друге ничего не знают.
Пётр СедовCEMb, умные указатели -- это неуклюжая попытка превратить C++ в подобие managed-языка. При разработке игр на C++ это не особо нужно.Умные указатели тут ни при чём, я мог бы использовать что-то другое для связи, это ситуацию не меняет, вопрос же был не про это А игры тут при чём? Как игры или не игры влияют принципиально на разработку?
MasterZivчто уж тут ок? иерархия (классов) на основе вложенности - это как-то странно, это не ок...Ну не иерархия, а зависимость, всё равно всё ок. Иерархия - логическая, т.е. элементы одного класса являются частью другого (членами класса). Иерархия получается логическая.
MasterZivдостаточно сделать лишь forward declaration другого класса, в видеНу я это и имел ввиду, когда говорил об упоминании.
MasterZivникакая шаблонная магия тут не нужна.Почему никто не читает то, что я пишу шаблонная магия нужна была для построения двух как можно более независимых иерархий классов. Это необходимо для более удобной разработки, когда мне надо будет менять базовые элементы в обоих иерархиях. Сейчас зависимости между двумя иерархиями явно присутствуют в классах, это неудобно.

maytonА можно пример использования? Чтобы почувствовать всю "крутость" и "загадочность" этой магии.ага, если речь про
template <typename T> class A : public T {};
то тут всё просто. Данная конструкция делает надстройку над классом, к которому применяется. Применений тут много, я хочу использовать увеличение информации внутри класса. Есть класс А:

делаем шаблон:

после этого мы можем делать так:
CUID<A> auid; - Объект с функционалом класса А и с уидами. При этом ни А ничего не знает про CUID, ни CUID ничего не знает про A и эти два класса могут разрабатываться независимо.
Мы можем вешать CUID на любые классы: CUID<B> - это отличие от наследования, где если мы хотели добавить uid в дочерний класс и отнаследовались - чтобы навешать uid на другой класс, нам надо заново наследоваться (это грубое сравнение, в реальной жизни, само собой, мы бы по-другому сделали). Тут же достаточно просто в объявлении объекта указать CUID чтобы получить дополнительный нужный функционал. Ногами не пинайте, если вдруг рассказываю понятные вещи, я обычно всегда стараюсь подробно всё рассказывать.
"Магия" у меня там в проекте заключалась в том, что я хотел таким образом развести независимо 3 иерархии классов, которые у меня были изначально связаны друг с другом, чтобы потом можно было разрабатывать их независимо. Шаблонизацию я закончил, осталось сделать правильные объявления. Надеюсь.

MasterZivДля этого шаблонная магия тоже не нужна.
Для этого нужны классические паттерны, к которым шаблонная магия никак не относится.какие?
egorychну, ТС пусть читает Александреску , он как то же крестил ежа с ужом, собирал патерны на шаблонах.ну вот я как раз его и читаю.
Пётр СедовПрочитал вот это:так я и говорю, чтобы было нагляднее :)
Пётр СедовЕсли игровую логику пишут на C++, то значит хотят выжать максимум из железа (по скорости и по памяти), а значит умные указатели лучше не использовать. наверно, получается так. Хотя не уверен, что работа в играх с каким-то внутреигровыми объектами на shared_ptr съест ресурсы железа соразмерно с той же графикой.

В общем, получилось как-то так:











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

Ну как, стал я шаблонным магом 2-го уровня? о_о

решил я зайти с другой стороны.
т.е. первая сторона: при объявлении переменной шаблонного класса мы передаём в шаблон все базовые типы и шаблоны используемых классов, и потом в этом шаблоне раздаём типы всем шаблонным-шаблонным параметрам. Это всё хорошо и правильно, потому что это гарантия использования одних типов во всех используемых классах.
другая сторона: шаблон, который должен знать только про один входящий обслуживаемый класс, при этом иногда должен возвращать или работать с типами, с которыми работает этот обслуживаемый класс-параметр. Если более детально, то в первом случае мы инициализируем всё в рамках одной переменной, а во втором, эту переменную(этот тип) используем для создания сервисного объекта. Вот тут тонкое место про типосовместимость: нам по-хорошему не надо заводить в шаблоне параметры для базовых типов, используемых в первом случае, просто потому что есть возможность там задать другие типы. У меня в результате так и получилось: пока я разрабатывал, я в шаблон добавил просто родительские классы, а потом при компиляции "оказалось", что типы этих классов не совпадают с типами классов, с которыми работает обслуживаемый класс.
Ок, поэтому во втором случае полезно передавать только основной класс в шаблон и из него как-то получать типы, с которыми работает этот класс. Если мы работаем как транслятор или посредник-обработчик, т.е. вызываем функции базовых классов или передаём данные базовых типов из обслуживаемого класса наружу, то auto подходит великолепно. Но вот если нам нужны какие-то переменные базовых типов внутри класса, то auto уже не подходит. Я решил использовать decltype. При этом, так как у меня из обслуживаемого класса доступны только функции, можно написать decltype(&f()) и получить тип. И тут у меня два вопроса
1. если функция возвращает shared_ptr<T>, то как из этого типа выдернуть T?
2. почему я не могу сказать decltype(&f()) если f - private или protected? sizeof вроде в таких случая работает.

CEMb1. если функция возвращает shared_ptr<T>, то как из этого типа выдернуть T?decltype(foo.get()); же...

ermak.nn, да, конечно, я просто навскидку написал общую идею. Спасибо.

вообще, если полностью, то это выглядит так:



таким образом TYPE для внешнего наблюдателя это T0, если A<A0<T0>>::TYPE. Но:
1. криво как-то выглядит...
2. всё-таки есть сомнения в идеологической правильности такого подхода

Доработал идею полностью на шаблонах сегодня утром, хочется немного высказаться
Для простоты понимания, значит, иерархия была такая, по аналогии:
1. Библиотека - шкаф - книга - страница.
2. Закладка.
3. Поиск.
4. Консоль.
Это всё просто аналогии, на самом деле всё абстрактно. Это важно.

Изначально шаблонов не было, иерархия №1 была "классической": в библиотеке шкафы, в шкафах книги, в книгах страницы. Закладка могла указывать на страницу, на одной странице могло быть различное (0..N) число закладок. Само собой, когда я делал иерархию №1, я сделал интерфейс книги так, что можно получить страницу по номеру. Потом, когда я делал шкаф, я сделал интерфейс для получения книги по названию, ну и, для удобства по названию книги и номеру страницы - страницу из шкафа. В аналогии звучит весело, но когда на руках абстрактные классы, это вроде как нормально и удобно. Ок. С библиотекой в результате получилось тоже самое: по номеру шкафа, названию книги и номеру страницы из библиотеки можно сразу получить страницу.

С закладками всё немного не так, как в жизни, закладке пришлось-таки помнить своё место от шкафа до страницы, иначе смысл такой закладки терялся. Но вернёмся к первой иерархии. Когда я стал её переводить на шаблоны, названия классов выросли до 3 экранов. Почему так. Библиотека должна была знать классы шкафа, книги и страницы, чтобы уметь возвращать объект страницы. При этом явно указывать ни один из этих классов нельзя, они все идут как параметры шаблона, итого 3 (на самом деле 4, ещё и закладки, но это потом). Далее, класс шкафа должен так же уметь работать с книгами и страницами, которые тоже должны быть параметры его шаблона. Шаблона. Вот теперь делаем шаг назад и в шаблоне библиотеки заменяем первый шаблонный параметр (шкаф) этим самым шаблоном шкафа. Тоже самое проделываем с книгой, но ещё и в шаблоне шкафа заменяем первый параметр, книгу, на шаблон книги. В результате у нас получается прикольная иерархия шаблонов, которые внутри себя передают свои параметры друг другу. Название класса библиотеки почти влазит в один экран. Ура.

И вот теперь надо добавить закладки. Закладка по сложности описания почти доходит до библиотеки, потому что у неё в параметрах тоже шкаф, книга и страница. Но при этом посмотрим на первую иерархию, там тоже должна появится закладка, как минимум в классе библиотеки и в классе страницы. А так как страница фигурирует в книге и шкафу, то и там тоже. Страница превращается в шаблон с параметром "закладка" и этот шаблон в качестве параметра заменяет класс в шаблонах библиотеки, шкафа и книги.

Если вы ещё со мной, то вернёмся к закладке: у неё в качестве параметров должны добавляться шкаф, книга и страница. При этом они должны быть идентичны по (шаблонной)сигнатуре параметрам в первой иерархии. Но шкаф, книга и страница сами принимают на вход шаблон закладки. Рекурсия :) Но задача решается применением магии 20058755 , описанной выше, но более сложной. Там 2 класса, тут класс + иерархия 3 классов, все друг на друга ссылаются. Нагрузку по прокидыванию себя в шаблонные параметры я оставил в закладке, так как иерархия №1 и так была перегружена магией.

Если до этого всё было более-менее понятно, до дальше шли пункт 3 и 4. Это тоже должны были стать 2 шаблона, первый принимал в качестве параметра библиотеку, второй принимал на вход библиотеку и поиск. Т.е. из консоли должно было возможно делать поиск в библиотеке, грубо говоря. И вот тут я стал запутываться, так как шаблонный параметр библиотеки в обоих этих классах тоже должен был быть шаблоном, причём ровно таким многоэтажным, каким он был в иерархии №1. Почему так: поиск и консоль должны были уметь возвращать, например, страницу по закладке. Т.е. класс страницы там должен был как-то появиться, чтобы поиск и консоль могли с ним работать.

На самом деле я всё писал не в такой последовательности, просто потому что изначально всё было уже написано без шаблонов, а потом я пытался всё и сразу перевести на шаблоны. И проблемы начались где-то по середине, когда я пытался свести все шаблоны к нужному виду, чтобы они нормально принимались в качестве параметров другими шаблонами, опять рекурсия. А надо ещё учесть, что у всех шаблонов были родительские классы, с информацией. Шаблоны, по моей задумке, нужны были для связи. Поэтому для простоты я ввёл порядок в описание, чтобы было нагляднее.

И вот когда в понедельник с утра я понял, что всё слегка запуталось, я сел и посмотрел на иерархию №1. И вот тогда я решил выкинуть все транзитные взаимосвязи. В библиотеке только шкафы, в шкафах только книги, а в книгах страницы. И сразу куча "кода" из названий классов пропала, во-первых. Во-вторых, я разбил классы библиотеки на отдельные шаблоны-прослойки, которые просто работали с транзитными данными, принимая в качестве шаблонных параметров только родителя и только целевой тип. Например библиотека_с_книгами<библиотека, книга>который, например, просто по названию возвращает просто книгу(из auto шкафа, см. далее). Код упростился и распался на несколько никак не зависящих частей. Они все наследовались один раз, при декларации класса(шаблона), и потом про них можно забыть. Точно так же выкинул упоминания класса страницы из шаблона шкафа, и часть кода сразу можно было выкинуть(она "волшебным образом" оказалась уже в прослойках для класса библиотеки).

Вот тут вылезла польза auto. Если раньше я считал его просто удобным иногда, а часто вредным из-за нечитаемости кода, тот тут оно просто стало необходимым. Изначально библиотека ведает только о шкафах. Абстрактная прослойка, работающая с книгами, ничего про класс шкафов не знает, но имеет доступ к родительским методам для работы с ними. Поэтому auto для определения типа, возвращаемого методом родительского класса - самое оно! Пришлось местами переписать функции, чтобы они именно возвращали объекты. Не знаю, хорошо это или плохо. Раньше они возвращали bool, теперь кидают исключение.

Но смотрите, я мог и не делать эти прослойки тут . Основной бонус, к которому меня подтолкнули шаблоны - разрыв связей, и это мне удалось по максимуму. Вот эти код-прослойки я могу делать прямо внутри классов поиска и консоли: я могу написать там тот же код на auto для получения нужных объектов нужных классов и потом получения их дочерних объектов и так далее. Или могу отнаследовать входящий шаблонный параметр библиотеки от готового кода прослойки. Неважно. Главное у меня теперь есть дважды независимый код, который можно использовать на конкретных объектах, о которых он ничего не знает (кроме названий функций). Главным уроком было то, что когда я переписал "нормальный" код на шаблоны, сразу стало видно, что он совсем не нормальный, и сразу стало видно, как надо сделать правильно.

В результате у меня семь файлов(4+1+1+1) с описанием независимых друг от друга классов, без forward declaration, их можно разрабатывать отдельно, что и было целью моего приключения: я хотел иметь возможность фиксировать эти классы на некоторых моментах разработки, а потом мочь заменять их другими с более широким или просто иным функционалом, при этом чтобы другие работали как прежде, а так же мочь возвращаться к прежним классам, если нужно. И теперь я это могу, просто заменив название одного класса на другой в строке декларации объекта :)

И дайте мне уже мой чёртов второй уровень шаблонной магии

Anatoly MoskovskyВаша ошибка в том, что вы вместо описания конкретной предметной области пытались в первом посте объяснить все какими-то абстрактными сущностями A B C.
Если бы вы сразу написали про книги, то вам бы сразу и сказали что в сущности Страница не должно быть никакой ссылки на сущность Закладка. И никаких бы циклических ссылок не было бы ))
Нет никакой ошибки. Предметную область я добавил в описание для того, чтобы было легче понять логическую связь между классами. Выше я приводил пример с картами. Если писать про А, В, С, никто читать не будет, потому что потеряется на втором абзаце :) читать и одновременно строить и держать в голове абстрактную модель в общем случае тяжело для человека.
Сделать ссылающиеся друг на друга и при этом независимые шаблоны - это была цель. Как альтернатива избавлению от связей в коде. По-моему, получилось отлично: никаких #include, forward declaration, интерфейсов, собирается на момент компиляции. Лучше не бывает!
Где мой диплом шаблонного мага? :) я уже придумал ТЗ на новое заклинание для получения 3-го уровня.

Я надеваю свой шаблонный плащ и шаблонную шляпу...

Статическая альтернатива polymorphic hell

Вчера вечером натолкнулся на такую проблему:
- Есть некое множество классов, назовём их Shape, у которых есть метод Compare, который на вход принимает ссылку на другой объект Shape.
- Есть некий класс А, который должен содержать вектор этих самых Shape. У А есть тоже метод Compare, который на вход принимает ссылку на А.
- В А::Compare нужно все родные Shape "сравнить" через Compare входящего объека А. При этом если классы родного Shape и входящего Shape не совпадают - делать ничего не надо. Строгая типизация, типа.

Сначала я сделал так: все классы Shape отнаследовал от одного базового, скажем ShapeBase, метод Compare сделал виртуальным, в классе А завёл вектор ShapeBase и в методе А::Compare устроил двойной цикл сравнения "каждый с каждым".

Но тут обнаружилась проблема: строгая типизация. Нужно было на ходу извлекать реальные типы из итераторов ShapeBase. При условии, что А::Compare должен отрабатывать так быстро, как только можно, методы динамического определения типов оказались плохим вариантом. Так как долго.

В результате я опять решил всё сделать на шаблонах. Проблема была в том, что вектор в А должен содержать объекты разных классов. Я решил сделать шаблон, с двумя параметрами, один - базовый класс A, второй - класс Shape, вектор которого я объявил внутри шаблона.


Ok, добавляя этот шаблон к А(через параметр P), я получал для одного класса Shape то, что требовалось.

Теперь надо чтобы можно было добавить в структуру второй шаблон. Параметр Р тут как верёвочка, на которую нанизываются шаблоны. Если теперь просто навесить сверху второй Shape, он так же удачно заработает, но отвалится первый, его методы Compare и AddShape перестанут работать, так как они перекрыты вторым шаблоном, и их не будет видно.
Проблема решается через добавление


Теперь при добавлении объектов Shape1, Shape2 и так далее, все они складываются в свои вектора. Ура.
Осталась одна проблема: базовый класс А. Он должен поддержать то, что написано в using. Туда достаточно добавить минимальные заглушки (шаблону в большей степени всё равно), и вся иерархия становится завершённой(в решении я вынес это в отдельный шаблон, чтобы не мусорить в А). Compare потребуется указать параметр, так как он будет зваться рекурсивно, а вот AddShape всё равно на параметры, он зовётся только снаружи.

Минусы:
- заведение закрывающего класса Shaper. Хотя в обычном варианте так же присутствует "лишний" класс - основа иерархии.
- если в иерархии А были явные конструкторы с параметрами - придётся их пробросить в Shaper и P.
- обработку (обход) по вектору придётся вынести в сами методы шаблона Shaper, для рекурсии. А это даже уже плюс.
- "вектор" объектов нельзя сортировать/перестраивать как угодно, сложно (но реализуемо) обращение по индексу.
- объявление типа конечного класса занимает много места :)

Плюсы:
+ скорость обхода "вектора" на порядок меньше, чем в классическом варианте: количество итераций пропорционально N против N ² в случае с полным обходом.
+ статическая типизация. И нет virtual.
+ "вектор" "отсортирован" автоматически - как бы мы ни добавляли элементы в "вектор", при обработке они пойдут порядке объявленных в шаблоне классов. Плюс сомнительный, скорее просто фича.
+ все классы Shape и класс А - независимы друг от друга, все связываются через Shaper
+ изначальный код класса А ничего не знает про новый функционал, связанный с классами Shape. Если заглушки вынести в отдельный класс, то код класса А вообще не меняется. Так ж класс Shaper ничего не знает про класс А.

В общем случае такой подход не применим, но в моём варианте отлично подходит.


Мне было бы так же интересно, как можно было бы быстро решить эту задачу классическим методом. Но только не добавляя в классы Shape информацию о типе! :)

...
- а я написал игру, используя шаблоны
- ну и как игра?
- победил на этапе компиляции...

---
Возникла такая ситауация: у меня есть шаблон, который принимает на вход шаблонные-шаблонные параметры. В процессе реализации мне захотелось абстрагировать один фундаментальный тип (это был float) на что-то общее, потому что тип иногда даёт ошибки вычисления, да и вообще есть задачи, которые должны решаться снаружи этого типа (функции, константы). Поэтому решено было заменить тип классом, шаблонным, само собой, но это не важно. Важно то, что тип (float) плотно использовался в одном из шаблонных-шаблонных параметров А. А это значит, что в шаблон этого шаблонного-шаблонного параметра А нужно будет добавить ещё один typename и то же самое учесть во всех зависимых от него шаблонах, а это большая переделка.

для начала я вынес всю работу с float в отдельный шаблон:


в таком виде A1 непригоден для использования, так как по сигнатуре не подходит под А

поэтому непосредственно перед использованием-объявлением я написал строчку:


так вот вопрос: можно ли как-то обойтись без А2? Как-то в идеале примерно так:


т.е. в результате должен получиться шаблон с одним входящим параметром. Понятно, что в таком "объявлении" неясно, какой из двух параметров указан, поэтому и вопрос, есть ли какие инструменты в языке, которые позволяют в одной строке указать один из параметров шаблона?

CEMbСтатическая альтернатива polymorphic hellВсё можно сделать в разы проще:
почему никто не сказал?

Anatoly MoskovskyПотому что никто не читает и тем более не улучшает абстрактный код делающий непонятно что Тема ветки - про изучение шаблонов, я хочу сильно преуспеть на этом поприще. Далее, я два раза придумывал тематические объяснения для структур данных, чтобы было удобнее понимать. И я как раз упомянул, что описание - чтобы было удобно читать не про абстракции.
Последние два поста про формирование блока объектов внутри класса. Никто же не жалуется, что vector<T> - ни о чём? Или паттерны программирования. Тут та же ситуация, я пытаюсь на шаблонах сделать иерархию классов, цель указана три поста назад: 20172805 , но и то, у меня там в качестве примера приведена ситуация собирания и рисования двух классов объектов.

я тут пару раз уронил компилятор(ms vc++2013), "внутренняя ошибка, поменяйте строки местами...", и у меня возник вопрос.
можно как-то (ключи?) посмотреть логи сборки, процесс компиляции, в общем, более развёрнуто увидеть причины ошибок?

А кто знает самый просто способ выдернуть тип шаблонного параметра из класса?

NekZ, о, спасиб, я до этого пользовался таким: 20126260

Btw, у меня проблема

Общий смысл: сделать двух-связанный список классов, по такому принципу:
1. Класс А содержит массив объектов класса В
2. Класс В содержит указатель на объект класса А, в массив которого он входит.
Ну и всё на шаблонах, чтобы можно было сложную иерархию классов написать просто:

шаг первый был прост, передаём класс B в качестве параметра в шаблон А и там заводим на него массив, ок.
шаг второй был сложнее, так как при правильной передаче всех шаблонных параметров в обе стороны, описания классов (да просто первая строка декларации) разрастались в геометрической прогрессии. Поэтому оставался один вариант: при создании массива внутри класса, класс сам сообщает его элементам себя в качестве родительского. Это очень компактно и не растягивает декларации классов. Всё ок, но только в случае, если классов два. Дело в том, что в вше приведённом объявлении, класс S передаёт себя в качестве родителя в класс P, но сам он ещё ничего про класс L не знает. И вот, получив родителя с элемента класса P, мы не сможем с него вызвать GetParent.
второй день не могу придумать, как малыми силами это победить

Причём, s2 и s - это один и тот же объект в памяти, но s->GetParent() нормально работает. При этом в коде нету виртуальности. Как уболтать компилятор?

...
Кольцо Всевластия несомненно было шаблоном: работало исключительно согласно классу персонажа, которого в него передавали...

Сделал двойным проходом:

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

PS: если вы не пишите ответы, то закидывайте сюда хотя бы интересные вопросы/код/задачки, касающиеся шаблонной магии

Натолкнулся на такую проблему, есть два класса:




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

Далее, где-то в main:


Всё ок.

Потом я решаю развивать A1 новым функционалом независимо и создаю A2:



Далее, где-то в main:


Ошибка, не могу конвертнуть A1<B1<A2>> в A2<B1<A2>>
Потому что функция описана в A1 и делает shared_ptr шаблона, в которой A2 передаётся позже, стало быть Fill об этом никак узнать не может. Переносить Fill каждый раз при создании следующего класса не хочется, да и не так всё просто, как в этом примере.

Как быть?

Проблема решилась тройным проходом
Т.е. вот в этой строке:


Для класса S, когда он в L передаётся, L ещё выглядит вот так:


Поэтому то, что передаётся в конструктор S после того, как L проинициализировался и до того - это разные классы. Поэтому, перед тем, как создавать сам объект, я делаю фейковую иерархию, а потом её разворачиваю назад, и вот тогда всё ок.

Такой вопрос, есть класс(шаблон), отнаследованный от enable_shared_from_this:




есть отнаследованный класс B:




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

MasterZivХочется -- сделай!В том виде, как я написал, не компилируется.
Хочется даже так: чтобы каждый отнаследованный класс T был public enable_shared_from_this<T> неявно.

Anatoly Moskovsky, спасибо
Буду делать по старинке, обычный указатель, закрою все доступы и лишние конструкторы, чтобы можно было проинициализировать 1 раз и буду сидеть бояться. По идее, этот указатель (shared_from_this) передаётся дочернему объекту в конструктор, когда его создаёт этот класс. Т.е. не может быть ситуации, когда ребёнок жив, а родитель нет. Просто хотел сделать всё по-современному :)

Anatoly MoskovskyГлавное помнить, что shared_from_this() нельзя вызывать из конструктора ))Не задумывался про это, но оно и ожидаемо, как и бросание эксепшинами в вентилятор конструкторе.
Посмотрел внутренности. Ага, WeakPtr инициализируется в конструкторе shared_ptr() после того, как выполнился конструктор класса-параметра. До этого он Empty.
Спасибо

Вопрос.
Есть нитка классов:
не компилируется на строчке


C2275 на тип ТЕ. Недопустимое использование типа в качестве выражения.
Не пойму, что сделать...
Цель: если тип не совпадает, передать управление следующему в нитке классу, до тех пор, пока не найдём тип или не кончатся классы.

Anatoly Moskovsky, почему не шаблонный?

Anatoly Moskovsky, так у метода свой, отдельный шаблон на TE