std::auto_ptr и плохой тон

Напиши им, что они упоролись. Для C++03 это вполне нормальное решение.

Написал, но более культурно. :)

Как и с goto: никакого смысла нет, сплошные суеверия

Отпиши потом сюда, что ответили. Интересно посмотреть.

Сам жду. Там еще возмутились использованием CMake и std алгоритмами вместо самописных (но это дело вкуса).

boost::shared_ptr? Если буст нельзя использовать, то не использование умных указателей в С++ является плохим тоном.

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

Сижу думаю, с каких это пор auto_ptr считается плохим тоном.

Как минимум со времен unique_ptr

Как минимум со времен unique_ptr

с++11 нельзя, я же сказал.

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

Если так, то на все их возражения достаточно сказать «подменять указатель на член класса - вот это действительно плохой тон».

scoped_ptr?

забей. чаще всего в таких случаях сам автор задания неосилятор.

Сижу думаю, с каких это пор auto_ptr считается плохим тоном.

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

Другое дело, что по возможности лучше использовать scoped_ptr/shared_ptr, поскольку у них более интуитивная семантика.

Там еще возмутились использованием CMake и std алгоритмами вместо самописных (но это дело вкуса).

Мало того, что чудаки, так еще и велосепидоры.

Там еще возмутились использованием CMake и std алгоритмами вместо самописных

Какие-то неадекваты, создающие проблемы на ровном месте.

возмутились использованием CMake

Это где такой гений сидит?

Для C++03 это вполне нормальное решение.

Нифига не нормальное, если бы он неявно владение не отдавал бы, был бы нормальным.

Как сказал сам Страуструп:
1) Применение поинтеров вообще далеко не всегда оправдано и нужно.
2) Если «локально», то unique_ptr
3) если шарить, то shared_ptr

А вообще сейчас модным считается 'move semantic' и move constructor.

с каких это пор auto_ptr считается плохим тоном

С тех пор как стало понятно, что некоторые так и норовят засунуть его в контейнеры stl.

А еще бывает, что их используют в качестве мемберов класса, а нормальное копирование/присвоение не делают. Результат очень интересный.

Потому, что у него кривой конструктор копирования и оператор присваивания. Как вариант, можно использовать для C++03 boost::scoped_ptr. А вообще переползайте уже на текущий стандарт, хватит старым пользоваться=)

А еще бывает, что их используют в качестве мемберов класса, а нормальное копирование/присвоение не делают

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

А вообще переползайте уже на текущий стандарт

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

И нафига я буду тратить время на явное их определение, если меня вполне устраивает поведение «по-умолчанию»? Оно, в общем-то, для того и существует

Чтобы в дальнейшем не было казусов.

Оно, в общем-то, для того и существует

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

неправильно.

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

Нифига не нормальное, если бы он неявно владение не отдавал бы, был бы нормальным.

А теперь расскажите, с каких пор передача владения приватными членами класса является хорошим тоном.

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

Довольно слов, покажите мне ассемблерный листинг.

гонят

а если не нужен подсчет ссылок?

Почему? Тем более, что unique_ptr еще со времен -std=c++0x. Какой gcc?

Продолжай читать дальше :)

А теперь расскажите, с каких пор передача владения приватными членами класса является хорошим тоном.

Молодец, сам придумал, сам опроверг.

Если у тебя проблемы с русским языком попытаюсь выразиить мысль проще: auto_ptr ненормален тем, что отдаёт владение в конструторе копирования и операторе присваивания.

Вообще-то, от того что нельзя использовать C++11 auto_ptr не потерял всех проблем, из-за которых его и заменили на unique_ptr, так что претензия совершенно справедлива.

некоторые так и норовят засунуть его в контейнеры stl

Тут кстати можно это сделать случайно по невнимательности. Например, кто-то в библиотеке сделал:

class MyClass {
  // .... 
  typedef std::auto_ptr<MyClass> Ptr;
  // ...
};

А потом появляется что-нибудь типа:

std::vector<MyClass::Ptr> vector_of_my_class_pointers;

А потом появляется что-нибудь типа

Вот-вот, и я о том же. Понасуют автоптр куда ни попадя, а потом огребают. Лучше уж считать его deprecated и забыть как страшный сон.

Честно говоря, удивлен, что сия возможность теперь считается плохим тоном. Также, очень странным показалось мне решение комиссии по стандартизации исключить его из новых стандартов C++ по причине того, что им лишь неправильно пользовались, ведь инструмент же не виноват, что им неправильно пользуются! :)

Для меня std::auto_ptr<> является прекрасным инструментом управления памятью и exception-safe гарантии отсутствия ее утечек. Например, очень удобно использовать его в качестве члена класса, который хранит и корректно удаляет атрибут, опционально присутствующий у объекта класса, но это лишь один из множества случаев, когда использование std::auto_ptr<> является удобным и вполне оправданным.

В новом стандарте для этих целей предусмотрен std::unique_ptr.

А твое удивление мне непонятно. Очевидно же, что копирование, изменяющее оригинал, нелогично.

Могу предположить, что они его не осилили и огребли проблем, с тех пор недолюбливают. Или просто не осилили.

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

Как только он будет полностью поддерживаться основными компиляторами в дистрах типа RHEL

Зачем для разработки использовать RHEL, или я чего-то не понимаю?

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

Там еще возмутились использованием CMake и std алгоритмами вместо самописных (но это дело вкуса).

Может, «там» хотели проверить, насколько хорошо ты умеешь программировать сам, а не насколько хорошо знаешь стандартную библиотеку C++?

А по поводу auto_ptr... некоторые (в частности, Спольски) и использование исключений считают (и не безосновательно) плохим тоном. Было бы интересно послушать их аргументацию.

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

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

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

Это единственный способ выжить в мире с++. Потому что, если разрешить всё, ты будешь иметь помесь буста с каким-нибудь куте, разбавленного ассемблерными вставками.

блин. почти 50 сообщий, и только одно, которое объясняет, в чем его кривость. Сами найдете? Это очень просто

некоторые (...) и использование исключений считают (и не безосновательно) плохим тоном. Было бы интересно послушать их аргументацию.

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

Ну и эксепшн-сейфти добавь к этому. В общем, исключения могут создать больше проблем, чем решить, если, конечно, программа не из серии «ё*нулась - ну и х*й с ней».

почти 50 сообщий, и только одно, которое объясняет

Ты, должно быть, тут новенький?

Там еще возмутились использованием CMake и std алгоритмами вместо самописных

Беги оттуда.

Меня туда и не взяли. Не подошел я им. :)

А я вот надеюсь, что они думали о std::unique_ptr