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

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


egorychНо на самом деле, тебе не нужен такой кривой каст. Всё, что тебе нужно - это сделать твой globalStorage указателем на базовый класс ( class A, в твоих примерах ) и функцию b() сделать возвращающей тип A*, и тогда ты 100% гарантируешь, что с любым объектом, который она вернёт, работа возможна только в рамках интерфейса базового класса.

если бы не стояло задачи как в аксессор наследника можно вставить экземпляр базы (родителя), то и всех этих трех тем не было бы вообще

egorychВозвращаясь к посылу именно этого треда, то, если малька перезаточить твой исходный пример, то падения можно добиться прямо не отходя от кассы:

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

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

с одной стороны печально, но с другой стороны стало понятно что к чему...

egorychLumixВот это да!! Охренеть!!
А это правило распространяется на наследников третьего и глубже уровней??на всех. собственно, он ( виртуальный деструктор ) требуется, если удаляется наследник через указатель базового класса. если где-то в иерархии есть невиртуальный деструктор, то удаление на нём прекратится и не будут вызваны деструкторы наследников, поэтому есть рекомендация _всегда_ в классе делать виртуальный деструктор, на автомате.

ок, понятно

egorychmaytonУ меня уже в голове созрела книга под названием "Вы можете сделать это в С++, но этого делать нельзя."ну, ты немного запоздал ;-))
вот несколько подобных: верёвка достаточной длины... , скользкие места C++ , неидеальный C++ . вероятно, есть и другие

Про веревеку прочту в выходные, когда время свободное будет!!

MasterZivМне искренне жаль, что вроде бы очевидные мысли до тебя с такими муками доходят.

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

MasterZivНе обижайся. Просто видимо в твоем образовании компьютерном были какие-то пробелы, которые и были причиной этого. Это даже не обязательно твоя вина...

Я и не обижаюсь. У меня отсутствует формальное образование в области программирования. Мне как в 91 году родители подарили 286 компьютер, так с тех пор я все изучаю самоучкой ну или в результате общения, как тут на форумах. Мои родители всегда были против того, чтобы я занимался программированием как основным источником дохода, поэтому мне пришлось выучиться на экономиста и 80% денег я делаю не в программировании. Программирование это только один из моих бизнесов, потому что мои деловые связи в других бизнесах позволяют легко находить клиентов сразу по ходу. Например, ведем переговоры по товарам, а потом за обедом у коммерческого директора компании, которой мы продаем товары, я узнаю не надо ли чего накодить и оказывается, что можно и накодить, вот моя команда и подключается "в игру". Кто не в курсе, по-научному это называется кросс-сейл.

Я получаю реально крутые ощущения от работы в этом проекте. Кто-то из мужиков на рыбалку ездит, кто-то бухает беспробудно, кто-то в большой теннис играет, кто-то бильярд, а я кайфую от кодинга. К тому же вся его прелесть, что можно и в командировке и где угодно этим заниматься, все что надо это ноут с интернетом, а сервера нашей команды работают 24/7.

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

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

Про память конкретно вы, конкретно на этом форуме мне уже довольно внятно все объяснили. Где-то давно была тема или темы, когда я разбирался что такое на стеке и что такое на куче. Вроде я довольно неплохо все понял. А темы обращения с указателями и с кастингом, которые мы обсудили в эти дни были для меня новы и как мне кажется, я тоже все отлично понял и я надеюсь, что любой человек, который тоже в этой теме хочет разобраться сможет прочитать три эти темы и быстро въехать в суть вопроса.

Насчет пробелов...
дело в том, что мне оооочень тяжело дается образование в форме типа вот так http://www.youtube.com/watch?v=atVgLRzl3rI

MasterZiv1) есть еще другие способы выполнить type safe down cast. Самый простой — просто знать, что в этом месте программы тип какой надо, либо, более универсально, завести в классе поле — тип объекта, и проверять его.

Я вчера на примере, который дал Егорыч, где дата-мемберы хранятся через указатели, я впервые понял, что хранение объекта в памяти похоже на тузика после взрыва. Я всю жизнь думал, что если class B : public A, то просто есть участок памяти где сначала идет А, а потом идет В типа так

ААААААААААААААААААBBBBBBBBBBBBBB.............................

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

ААААААВВВВВВВ.......ААА......ААА....ВВВ.......ВВВ.....АААА........ВВВВВВВВ......АА...ВВ...ВВВ.....АААА.....

потом я прочитал, что такое deep copy constructor и вообще впал в печаль...

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

MasterZiv
> Насчет пробелов...

Так на счёт пробелов -- уже всё понятно. Раз вообще нет спецобразования -- тут
не пробелы, тут сплошные заснеженные поля...
Не, хорошо, что врубаешься...



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

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




и чей теперь int a сказать уже нельзя....
действительно, вы абсолютно правы!

MasterZiv>
> потом я прочитал, что такое deep copy constructor и вообще впал в печаль...
>

Да там всё просто ...

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

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



да, да, да, да, все это так, так, так

Edd.DragonLumixААААААВВВВВВВ.......ААА......ААА....ВВВ.......ВВВ.....АААА........ВВВВВВВВ......АА...ВВ...ВВВ.....АААА.....
Может так?

ААААААВВВВВВВ.......ССС......DDD....EEE.......FFF.....GGG........HHHHHHHH......II...KKK...LLL.....MMMM....

Т.е. дело не в том, что манатки, на которые ты ссылаешься, хранятся где угодно. А в том, что ты необоснованно считаешь частью объекта, который на них ссылается. И отсюда ожидаешь, что кто-то как-то их сложит в стройную кучку. А кто это это сделает? Снова менеджер памяти должен проявить доблестный интеллект? Нет.

Да, вы абсолютно правы. Я много лет считал такие объекты, которые хранятся по указателю частью самого объекта, а так считать абсолютно неправомерно

собственно там внутри темы, когда мы обсуждали как удалить изнутри new MasterZiv обратил мое внимание, что объект в памяти вообще не имеет отношения к указателю, что указатель имеет, а объект не имеет

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


Edd.DragonНо ты можешь сделать это сам. Устрой собственный менеджмент памяти.

Да, придется вводить какие-то правила типа один объект один указатель один владелец. В общем что-нибудь придумаю, главное, что теперь у меня наступила ясность как там все на самом деле происходит!!! эти ошмётки меня конечно мало радуют, но лучше правда, чем иллюзии...

Edd.DragonСобственно, логичный вопрос. Объект A ссылается на C. И объект B ссылается на С. Ну и к кому из них это C "прилепить" в памяти?

Собственно говоря когда-то давно я ввел систему аксессоров точно по этой же самой причине!! Было вообще непонятно что в каком классе хранить и я принял решение да пошло все нахер!! если пользователь не знает в чем ему хранить пусть хранит вообще в отдельном классе и этот класс будет доступен через аксессор в любом другом классе

поэтому вашу задачу про ссылающиеся друг на друга объекты мы решили через акссесоры: есть три класса A, B, C и у них есть три аксессора a(), b(), c() и теперь никто ни на кого не ссылается, каждый живет сам по себе и из каждого класса можно вызывать любой их этих классов через аксессор, полностью забивая болт тему взаимных связей между ними!!