автоуказатели

не томи душу просвети, вообще указателями не пользуешь? правильные плюсы это RAII. укзатель + RAII == смартпоинтер.

 

Здесь передача владения базируется на соглашениях. Другими словами, описании функции start_tread в отношении второго параметра (указателя) должно говорить о том, что владение действительно пердается, и в случае неудачного запуска потока к этому указателю будет применен delete и т.д. Это (в том числе), говорит о том, что start_tread не является низкоуровневой функцией нижележащего api, а представляет из себя просто 'обертку' для вызова другой функции. Здесь, в свою очередь, возникает резонный вопрос - почему для этой обертки не была выбрана функция с сигнатурой 'start_tread(F, std::auto_ptr<T>)' ?

Если же здесь, в качестве примера, start_tread является аналогом низкоровневой функцией (вроде beginthreadex), то показанная передача владения не является корректной, т.к. в случае ошибки при запуске потока указатель утечет.

 

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

 

Хм... Зачем в случае с параметром std::auto_ptr нужно явно это указавать? Это все равно что для такой функции:

Код (Text):

1. void f(int)

писать в документации: 'функция в качестве аргумента принимает число'.

Код (Text):

1. auto_ptr<params> p( new params );
2. start_thread(thread_routine, p.release());

Здесь не совсем видно факта 'приема' указателя. Т.е. отдать-то отдали, а насколько готова к этому принимающая сторона? Как минимум, надо смотреть документацию, а то и реализацию (c т.з. инспекции кода). Разумеется, можно отталкиваться от того факта, что раз есть вызов release, то программист понимал что делает и принимающая сторона готова к приему владения. Но в случае такой сигнатуры - 'start_thread(F, std::auto_ptr<T>)' подобных вопросов не возникает _вообще_, в точке вызова все предельно ясно.

 

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

Код (C++):

1. void f(auto_ptr<int> const&);
2. void f(auto_ptr<int>&);
3. void f(auto_ptr<int>);

и я бы скорее выбрал start_thread(F, T const&); Наверно намекает, что указатели должны быть глубоко внутри.

 

Ты сейчас только-что сам наплодил ненужную сущность. ^)

 

Эта сущность описана в литературе как pimpl По сути развитие смартпоинтеров )

 

J0E
Чтот значит развитие? Это вообще разные понятия. Заменять Pimpl-ом смарт это бредово.

 

Замена имеет смысл что бы скрыть такие детали реализации как new и поинтеры. Конечно не всегда оправдано создавать новый тип.

то что написал выше стандартными средствами грубо делается так

Код (C++):

1. struct TString {
2.   TString() stringBuffer(new TStringBuffer) {}
3.   auto_ptr<TStringBuffer> stringBuffer;
4. };

 

Из сказанного несколькими постами выше следует обратное =)

Смысла в первых двух я не вижу.

 

Ха ха, говоря что не нужен auto_ptr ты часть его реализации КОПИПАСТИШЬ в класс )

"моя реализация" вполне может иметь семантику TString myString; если добавить пару TStringBuffer& operator();

 

Смотри:

Фактически тут написано следующее - несколько объектов типа TString ссылаются на один (общий) объект типа TStringBuffer. std::auto_ptr здесь вообще не применим, т.к. моделирует ситуацию монопольного владения. Как только тебе понадобится схема, при которой удаление общего объекта должно выполнятся автоматически в тот момент когда больше не осталось ссылающихся на него объектов TString, то без использования, например, boost::shared_ptr, тебе придется вручную добавлять счетчик ссылок, деструкторы и т.д.

 

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

во! потому что ты УЖЕ видел реализацию auto_ptr и знаешь "соглашения" заранее без заглядывания в реализацию принимающей функции.

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

 

Да ладно, присвоить - завладеть, переприсвоить - передать владение ))

 

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

Ок. =)

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

 

Я буст не юзаю, у меня свой смарт. ^)

 

И не нужен целый C++

 

Чтобы юзать boost::shared_ptr, достаточно подключить 1 hpp файлик и все

 

Ты противоречишь сам себе, сначала заявляя "о вкусах не спорят", а следом подразумеваешь безграмотность у пользователей stl и boost.

Безграмотность - это считать что auto_ptr имеет оверхед по сравнению с голым поинтером и бинарь увеличится "на сотни мегабайт".

 

Да пора уже банить за слова типа "Зачем мне из-за одного класса тащить буст?", "От STL одни только тормоза", "Мне не нравится boost::shared_ptr и поэтому я написал свой"