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




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

1. грязь свеху (b=0, c=131074) это просто грязь из свободной памяти и и тогда все ок, или это кусок от какого-то реального объекта и мы кому-то реально что-то поломали в своей же программе??

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

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

maytonНу что это такое за мерзость ты написал?

Это наезд? )))

maytonЧто это за даункастинг в первой строке?

Я бы скорее назвал это апкастингом, если уж на то пошло. Даункастинг это так:

sherzod_,

чё обиделись на меня что-ли?...

m_SlaLumix, твой код примерно соответствует:



Ок, понял.

А в этом случае a[1] и a[2] чью-то конкретную память берут (какого-то живого объекта) или свободную, ничейную?? Это просто неэтичная операция или кастиг вверх может уронить программу??

MasterZivЕсли реального обращения с b как с B не будет, скорее всего, ничего не будет.

ок, понятно

MasterZivЕсли попытаются реально к b обратиться как к B, а не A, скорее всего, будет защита памяти и крах программы.

ок, понятно


MasterZiv0) это не просто грязь, это вообще не грязь, это UB -- т.е. твоя программа попросту невалидна. Как она при этом будет работать -- неизвестно.

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

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


MasterZiv1) это не кастинг вверх, это кастинг вниз. Он так и называется -- downcast, в безопасном варианте -- type-safe downcast.
Кастинг вверх всегда безопасен. Кастинг вниз требует проверки реального типа объекта.

2) единственный и он же безопасный метод выполнения downcast -- делать его всегда type-safe downcast. В С++ это dynamic_cast

ок, с направлением разобрался
спасибо за ключевое слово type-safe downcast

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

MasterZivили его проприетарные аналоги из разных библиотек, которые реализуют по сути тот же dynamic_cast своими методами.

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

mayton1)LumixЯ бы скорее назвал это апкастингом, если уж на то пошло. Даункастинг это так:


Нет.


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

MasterZivLumixА в этом случае a[1] и a[2] чью-то конкретную память берут (какого-то живого объекта) или свободную, ничейную??


Язык С++ это не специфицирует. Как это реализовано -- зависит от конкретного компилятора, его моделей памяти и способов её организации. Они могут взять чужую память, другого объекта, могут взять свободную память, могут вообще вызвать ошибку по защите памяти, особенно вероятно, если значения индексов будут большими или отрицательными.


Ок, понятно

MasterZivLumixЭто просто неэтичная операция или кастиг вверх может уронить программу??


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

Ок, понятно

mayton
2)
Следующее выражение перепиши с использованием dynamic_cast.




И расскажи что случилось в runtime.

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



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

maytonНе обижайся!

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

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

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

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

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

maytonУ меня уже в голове созрела книга под названием "Вы можете сделать это в С++, но этого делать нельзя."

где можно оставить предзаказ? ;)

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

Вот это да!! Охренеть!!
А это правило распространяется на наследников третьего и глубже уровней??

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() и теперь никто ни на кого не ссылается, каждый живет сам по себе и из каждого класса можно вызывать любой их этих классов через аксессор, полностью забивая болт тему взаимных связей между ними!!