Комментарии 24
спасибо! особенно интересен пример с unique_ptr, т.к. порой раздражает boilerplat-ные make_ptr.
Но все же это для кастомных типов, а возможно ли такое же, но для конструкторов самих *_ptr?
Но все же это для кастомных типов, а возможно ли такое же, но для конструкторов самих *_ptr?
Не очень понятен вопрос, поясните пожалуйста. unique_ptr с точки зрения языка такой же «кастомный» тип, как и любой другой.
ок, переформулирую :) тут нам это описали для containee, а не container'a (например unique_ptr). почему бы не сделать то же самое (или нечто похожее) один раз для unique_ptr, вместо того чтобы для каждого нового кастом класса переопределять стратегию владения?
Вы хотите вывести unique_ptr за скобку? А для чего это было бы полезно?
чтобы меньше печатать)
В принципе возможно, но нужно четко понимать, как вы собираетесь им пользоваться. Можете описать юзкейсы с кусочками кода?
class Foo
{
...
unique_ptr<SomeType> m_foo;
...
};
...
m_foo = new SomeType;
// instead of
// m_foo = unique_ptr<SomeType>(new SomeType);
// m_foo.reset(new SomeType);
...
Без вмешательства в код самого unique_ptr — никак.
Я в таких случаях пишу какую-нибудь sink-функцию, чтобы задействовать вывод типов, например:
template<T> auto to_unique(T* ptr) { return unique_ptr<T>(ptr); }
Я в таких случаях пишу какую-нибудь sink-функцию, чтобы задействовать вывод типов, например:
template<T> auto to_unique(T* ptr) { return unique_ptr<T>(ptr); }
m_foo = make_unique<SomeType>(p1, p2, p3) будет в C++14.
m_foo = make_unique<SomeType>();
Это C++14, но make_unique уже много где появился.
Я в первый раз слышу об упоминаемых вами возможностях. Это есть уже в C++11? Или же это только ожидается в стандарте C++14?
Вопрос снят. Действительно есть в C++11
Вау, очень неожиданно
Пример просто жуткий some_type, unique_ptr не требует конструктор копий, а вы своим some_type убили это требования убили. Опять же unique_ptr придуман не просто так, например в unique_ptr я храню сетевой коннекшен или поток, что будет если я попытаюсь сделать его копию? Пример конечно наглядный, но нарушающий идеологию unique_ptr.
Поясните, плиз, а в каком месте примера противоречие идеологии unique_ptr?
Идиология unique_ptr является эксклюзивное владение объектом, обычно каким-либо ресурсом (кусок памяти, файл, поток (thread), поток ввода-вывод и т.д.), данные объекты либо обычно не имеют конструктора копий и это правильно, есть только конструктор передачи владения.
А в примере же используется конструктор копий, нарушается эксклюзивность владения тем, что unique_ptr косвенно хранит ресурс, посредством некой обёртки.
В случае примера правильнее использовать std::shared_ptr и не извращаться подобным кодом.
А в примере же используется конструктор копий, нарушается эксклюзивность владения тем, что unique_ptr косвенно хранит ресурс, посредством некой обёртки.
В случае примера правильнее использовать std::shared_ptr и не извращаться подобным кодом.
Похоже это не работает в моей версии g++
Кто знает с какой версии gcc появилась поддержка ref-qualified?
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)Кто знает с какой версии gcc появилась поддержка ref-qualified?
Припишу (вдруг кому поможет), что помимо квалификатора const, к методу может быть приписан и квалификатор volatile. Тогда this, соответственно, будет трактоваться как указатель на volatile объект.
В свое время пару часов потратил, чтобы вкурить в ошибки компиляции :)
В свое время пару часов потратил, чтобы вкурить в ошибки компиляции :)
Небольшая правка: в примере с оператором == где указывается на проблему с ambiguous оператором нужно квалификатор const добавить оператору, определенному в классе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ref-qualified member functions