Здравствуйте, frogkiller, Вы писали:
F>Расскажите, пожалуйста, почему MSVC 7.1 ругается на сабж, говорит, не задан конструктор копии. F>6-я компиляет нормально.
Здравствуйте, frogkiller, Вы писали:
F>Расскажите, пожалуйста, почему MSVC 7.1 ругается на сабж, говорит, не задан конструктор копии. F>6-я компиляет нормально.
F>Смотрю определение auto_ptr'а:
F>
F> auto_ptr(auto_ptr<_Ty>& _Right) _THROW0()
F> : _Myptr(_Right.release())
F> { // construct by assuming pointer from _Right auto_ptr
F> }
F>
F>Вот, он родимый.
F>Тот же код, например, с boost::shared_ptr'ом проходит "на ура".
не просто конструктор копии, а конструктор копии из константной ссылки.
Вот если бы там было auto_ptr(const auto_ptr<_Ty>& _Right) _THROW0()
Но... нет, так что положить auto_ptr в стандартный контейнер тебе не удастся, это запрещено стандартом..
Здравствуйте, frogkiller, Вы писали:
F>Расскажите, пожалуйста, почему MSVC 7.1 ругается на сабж, говорит, не задан конструктор копии.
правильно ругается т.к. auto_ptr — простой "умный указатель" без счетчика ссылок и удаляет объект сразу после потери владения — соответственно конструктор копирования создает неопределенность, а потому и запрещен
F>Тот же код, например, с boost::shared_ptr'ом проходит "на ура".
на то он и shared_ptr . Собственно из-за недостатков auto_ptr он и появился
Здравствуйте, WiseAlex, Вы писали:
WA>Здравствуйте, frogkiller, Вы писали:
F>>Расскажите, пожалуйста, почему MSVC 7.1 ругается на сабж, говорит, не задан конструктор копии. WA>правильно ругается т.к. auto_ptr — простой "умный указатель" без счетчика ссылок и удаляет объект сразу после потери владения — соответственно конструктор копирования создает неопределенность, а потому и запрещен
никакой неопределенности конструктор копирования auto_ptr не создает, происходит передача владения.
F>>Тот же код, например, с boost::shared_ptr'ом проходит "на ура". WA>на то он и shared_ptr :). Собственно из-за недостатков auto_ptr он и появился
хватит гнобить auto_ptr — он умный указатель не глупее boost::shared_ptr, у которого своих проблем хватает.
Просто они сделаны каждый для решения своих задач: boost::shared_ptr — для совместного владения, std::auto_ptr — для передачи владения.
Здравствуйте, jazzer, Вы писали:
J>никакой неопределенности конструктор копирования auto_ptr не создает, происходит передача владения.
т.к. конструскор копирования на входе получает const auto_ptr & , то владение передать неудасться оно будет разделено м/у новым и старым объектом. Это и приведет к неопределенному поведению.
J>хватит гнобить auto_ptr — он умный указатель не глупее boost::shared_ptr, у которого своих проблем хватает. J>Просто они сделаны каждый для решения своих задач: boost::shared_ptr — для совместного владения, std::auto_ptr — для передачи владения.
никто его не "гнобил" и никто не говорил о безупречности shared_ptr. Я только указал, что shared_ptr решает некоторые проблемы, присущие auto_ptr
Здравствуйте, WiseAlex, Вы писали:
WA>Здравствуйте, jazzer, Вы писали:
J>>никакой неопределенности конструктор копирования auto_ptr не создает, происходит передача владения. WA>т.к. конструскор копирования на входе получает const auto_ptr & , то владение передать неудасться оно будет разделено м/у новым и старым объектом. Это и приведет к неопределенному поведению.
К UB приводит другое — реализация станартной библиотеки может копировать объект произвольное количество раз при любых операциях, а для std::auto_ptr, копии не равнозначны, поэтому объект может "потерятся" или еще что-нибудь. UB одним словом. Поэтому-то стандартные контейнеры требуют, чтобы T был CopyConstructible, Assignable и для не которых операций DefaultConstructible, проще говоря все копии должны быть эквиваленты.
J>>хватит гнобить auto_ptr — он умный указатель не глупее boost::shared_ptr, у которого своих проблем хватает. J>>Просто они сделаны каждый для решения своих задач: boost::shared_ptr — для совместного владения, std::auto_ptr — для передачи владения. WA>никто его не "гнобил" и никто не говорил о безупречности shared_ptr. Я только указал, что shared_ptr решает некоторые проблемы, присущие auto_ptr
проблемы нет, и не было.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, frogkiller, Вы писали:
F>>Расскажите, пожалуйста, почему MSVC 7.1 ругается на сабж, говорит, не задан конструктор копии.
VC7.1 не прав, это тоже конструктор копирования (12.1/10).
J>не просто конструктор копии, а конструктор копии из константной ссылки. J>Вот если бы там было auto_ptr(const auto_ptr<_Ty>& _Right) _THROW0()
Это не обязательно, главное — эквивалентность копий. Однако с другой стороны — это почти единственный способ статически проверить с определенной вероятностью, является ли тип CopyConstructible.
J>Но... нет, так что положить auto_ptr в стандартный контейнер тебе не удастся, это запрещено стандартом..
Почему же, разрешено, просто получишь UB. (20.4.5/3)
Здравствуйте, jazzer, Вы писали:
J>хватит гнобить auto_ptr — он умный указатель не глупее boost::shared_ptr, у которого своих проблем хватает.
Формально auto_ptr не является умным указателем — поищи smart pointer в стандартне — не найдешь, однако в TR1 все новые — умные
Здравствуйте, Pavel Chikulaev, Вы писали:
PC>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, frogkiller, Вы писали:
F>>>Расскажите, пожалуйста, почему MSVC 7.1 ругается на сабж, говорит, не задан конструктор копии. PC>VC7.1 не прав, это тоже конструктор копирования (12.1/10).
J>>не просто конструктор копии, а конструктор копии из константной ссылки. J>>Вот если бы там было auto_ptr(const auto_ptr<_Ty>& _Right) _THROW0() PC>Это не обязательно, главное — эквивалентность копий. Однако с другой стороны — это почти единственный способ статически проверить с определенной вероятностью, является ли тип CopyConstructible.
Это понятно, я говорил о сообщении компилятора (правда, я его не видел, просто предполагаю).
J>>Но... нет, так что положить auto_ptr в стандартный контейнер тебе не удастся, это запрещено стандартом.. PC>Почему же, разрешено, просто получишь UB. (20.4.5/3)
Так а компилятор разве пропустит?
Я просто не пробовал с времен шестерки, где auto_ptr был такой, как мне нужно, и его можно было хранить в контейнерах, эх, какое время было хорошее :)
Здравствуйте, jazzer, Вы писали:
PC>>Это не обязательно, главное — эквивалентность копий. Однако с другой стороны — это почти единственный способ статически проверить с определенной вероятностью, является ли тип CopyConstructible.
J>Это понятно, я говорил о сообщении компилятора (правда, я его не видел, просто предполагаю).
error C2558: class 'std::auto_ptr<_Ty>' : no copy constructor available or copy constructor is declared 'explicit'
error C2440: 'type cast' : cannot convert from 'std::auto_ptr<_Ty>' to 'int **'
Т.к. Dinkum там вообще вся в багах. Они нагнали сильно с auto_ptr_ref и с несколькими функциями-членами auto_ptr.
Плюс лишняя копия остается.
J>>>Но... нет, так что положить auto_ptr в стандартный контейнер тебе не удастся, это запрещено стандартом.. PC>>Почему же, разрешено, просто получишь UB. (20.4.5/3) J>Так а компилятор разве пропустит?
Компилятор имеет право не сообщать о UB (1.3/12).
Здравствуйте, Pavel Chikulaev, Вы писали:
J>>>>Но... нет, так что положить auto_ptr в стандартный контейнер тебе не удастся, это запрещено стандартом.. PC>>>Почему же, разрешено, просто получишь UB. (20.4.5/3) J>>Так а компилятор разве пропустит? PC>Компилятор имеет право не сообщать о UB (1.3/12).
Это понятно, я об этой конкретной задаче :)
Например, в обявлении std::vector const T& много где встречается, все эти места компилятор должен зарубить.
. Собственно из-за недостатков auto_ptr он и появился
