class A {...}
class B : public A {...}

std::tr1::shared_ptr< A > a(new B());
std::tr1::weak_ptr< B > b;
b = a; // не компилируется
Как можно сделать преобразование от предка к потомку для умных указателей?
Нужно для списка классов, порожденных от A(возможно, абстрактного).
Заранее спасибо.

а ты ничего не напутал ? преобразование вниз по иерархии это совсем плохая практика. 

Ты и просто на указателя такую штука так просто не сделаешь



тут нужно либо пользоваться хардкорными кастами (типа static_cast, или какой то другой). Либо хм... а других способов и не припомню я.

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


ЗЫ. А еще в вашем коде память течет ;)

Добавлено через 4 минуты и 47 секунд

А что, простите, "хардкорного" в static_cast?

http://alenacpp.blogspot.com/2005/08/c.html первый абзац абзац наиболее четко описывает то что я хотел сказать.

Раскройте мне секрет как связано преобразования вниз по иерархии и виртуальные деструкторы ?

afiskon, большое спасибо  ! Как раз это и было нужно. Надо tr1 и boost получше изучить. Тема закрыта.

Это смотря что делаешь. Есть список объектов базового класса, обрабатывается алгоритмом. В то же время каждый элемент этого списка - свойство других объектов, но уже как производный класс. У каждого элемента есть ID, по которому он находится, и его тип заранее известен ==> никаких ошибок не будет.


Это сообщение отредактировал(а) volk666 - 2.6.2011, 00:15

cupper Это у вас такой хитрый троллинг? 


Я так могу про что угодно написать:

или:

1. ПОЧЕМУ?
2. Даже если new в теории небезопасен (забыл сказать delete - и память потекла), это не значит, что его никогда-никогда не нужно использовать. Например, любая фабрика использует new. Не использовать теперь фабрики? Другой вопрос, что с умными указателями программа будет надежнее.


Пожалуйста:



Тут идет преобразование вниз (а вообще низ и верх иерархии - вещи относительные, родителей обычно рисуют сверху), но если у нас имеет место наслодование A -> B -> C, то мы можем создать C, вернуть его, как A, потом кастнуть в B и вызвать не тот деструктор ~B, когда нужен ~C. 

А вообще советую вам почитать Майерса, у него вопросы, что вы задаете, очень хорошо освещены.

Это сообщение отредактировал(а) afiskon - 2.6.2011, 13:48

А сами то читали :?



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


Жаль нет Страуструпа в электронке под рукой, еще бы и на него сослался. Боюсь что бестолку.

И кстати, указатели это зло, зловещее зло  страшен тот код где работа идет только с голыми указателями. Это как бриться скальпелем пьяным на намыленном полу. Код должен быть прост и не вызывать вопросов.

Это сообщение отредактировал(а) cupper - 2.6.2011, 21:54

полагаю, динамический полиморфизм Вам не известен. 

Добавлено через 2 минуты и 34 секунды
вообще-то, afiskon истину глаголит.

а работать с сырыми указателями, или со смартами - это не ошибка или нарушение правил - это выбор  

cupper, одно дело избегать (Майерс) и не использовать (Алёна C++ в вашей интерпретации). Я согласен с тем, что использование указателей по возможности нужно сводить к минимуму. Меньше шансов выстрелить себе в ногу. Но с 

или

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

Я ей богу не понимаю почему вы плюшки ООП приписываете к кастам. Я бы мог щас расписать принципы ооп, накой хер нужны динамические полиморфизмы и виртуальные деструкторы... но вы и так должны это знать. Единственно чего я не понимаю - причем тут касты и все это. Каст это всего лишь преобразования типа но не стандартное (которое умеет делать сам компилятор, например от потомка к предку) а то ответственность за которое полностью и бесповоротно несет сам программист. А это лишний повод для ошибки.

Если в задаче появляется необходимость привести указатель предка к указателя на потомка для того что бы вызвать функции потомка, получается что у вас потомки совсем таки разные получаются. И смысл унаследовать их от родителя как бы и теряется. Так как они не дополняют а изменяют базовый класс. У Майерса про ето как раз очень хорошо написано, не помню в какой именно книже, толи советы по С++? толи по STL. 

PS. исправил ошибки.

Это сообщение отредактировал(а) cupper - 3.6.2011, 13:45

Трудно в чем-то убедить человека, когда он этого не хочет 

пичалька 

Добавлено через 2 минуты и 10 секунд
хотел было привести пример стандартной ситуации когда это нужно(возможно это единственный способ при динамическом полиморфизме), но не стану...
как уже сказал afiskon:

Пример в студию !

http://liveworkspace.org/code/bf5e12a26406...b9cf0c8731596c8

покажи способ сделать это не используя каст по иерархии ;)
на примере динамического полиморфизма.

зы
хотя я предпочитаю статический.

boostcoder

а где тут приведение указателя на базовый тип к указателю на потомка?

azesmcar, та нет. я хотел показать что без каста такое невозможно.

    
как страшно жить 

Добавлено через 31 секунду

так ведь речь шла про downcast, а не про upcast  

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

Добавлено через 3 минуты и 44 секунды

речь об этом?:

http://liveworkspace.org/code/15f2508fa76c...b707a3e1dda6f12

а что тут незаконного? или я что-то упустил?

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

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

Добавлено через 51 секунду
естественно в данном случае идет об _опасных_ кастах.. какие именно входят в этот список, надеюсь уточнять не надо 

http://codepad.org/C9s9zRmk

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

Добавлено через 6 минут и 19 секунд

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

http://liveworkspace.org/code/aaeea40f6406...fc4d55be44c2c25

зы
на практике никогда такого не делал. честное слово.

Нет, почему же.
Необходимость делать downcast должна настораживать программиста, а например необходимость использования оператора if - нет, впрочем как и использование наследования.


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


Где тут cast? Я вообще понятия не имею как этот пример компилируется (если компилируется) и как компилятор должен повести себя в такой ситуации.

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

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




Это сообщение отредактировал(а) mes - 3.6.2011, 17:14

когда я писал пост http://forum.vingrad.ru/index.php?showtopi...t&p=2356159

этот же online компилятор выдавал мне приведенный error. Сейчас он компилирует код. О_о

http://liveworkspace.org/code/a449910606cf...37cf3deb0d590f6

Девид Блейн, отдыхает.


Это сообщение отредактировал(а) cupper - 3.6.2011, 18:11

значит, все же, struct отличается от class в с++

Добавлено через 7 минут и 30 секунд

http://liveworkspace.org/code/8f1f86dea05b...807f74b33a42c98

все таки разницы никакой  

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

Добавлено @ 18:29
мля.. нехорошо получилось..

Это сообщение отредактировал(а) boostcoder - 3.6.2011, 18:29