Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

Здравствуйте, Went, Вы писали:

W>Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

имхо, в таком случае его нужно называть clone_ptr.

Здравствуйте, Went, Вы писали:

W>Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

Концептуально неверно. Нежданчики попрут буквально сразу, как появится конструктор копирования.
Нельзя вот так просто взять и поменять идеологию uniq на идеологию clone, если вы конечно изначально не ошиблись с названием unique_ptr.

Здравствуйте, Went, Вы писали:

W>Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

Кстати, а чем ваше условное клонирование отличается от обычного копирования?
У самого объекта есть конструктор копирования?

Здравствуйте, andrey.desman, Вы писали:

AD>Кстати, а чем ваше условное клонирование отличается от обычного копирования?

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

Здравствуйте, Went, Вы писали:

W>Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

Если это специальный смартпоинтер из этой самой библиотеки, и его ожидаемое поведение именно такое, как ты описал, то почему бы и нет. ИМХО, вполне.

Здравствуйте, Went, Вы писали:

W>Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

У unique_ptr семантика перемещения. Копирования нет. Если ты к своему указателю при копировании клонирование прикрутишь (это потенциально дорого), то он, очевидно, будет клонировать в самых разных контекстах, например при передаче в функции по значению, возврате значения из функции и т.п. Реши, оно тебе надо, а?

W>>Здравствуйте. Просто мысли о правильном поведении уникального указателя. Допустим, у нас есть некая базовая библиотека, которая предполагает возможность корректного клонирования для любого объекта. Должен ли самописный уникальный указатель в этом случае реализовать собственное копирование через клонирование объекта, которым он владеет, или это концептуально неверно?

NB>имхо, в таком случае его нужно называть clone_ptr.

Шон Пэрен показал, почему это нельзя называть ptr.

Здравствуйте, rg45, Вы писали:
R>Как я догадываюсь, тем, что клонирование можно делать полиморфно, по указателю на объект виртуального базового класса
Да, конечно.

Здравствуйте, andyp, Вы писали:

A>У unique_ptr семантика перемещения. Копирования нет. Если ты к своему указателю при копировании клонирование прикрутишь (это потенциально дорого), то он, очевидно, будет клонировать в самых разных контекстах, например при передаче в функции по значению, возврате значения из функции и т.п. Реши, оно тебе надо, а?
Ну, довольно таки надо. Название "уникальный" говорит только о том, что он уникально владеет своим объектом и копирование через клонирование объекта этот принцип не нарушает, ведь так?
А для чего это надо... Ну, допустим, наш объект реализован через систему компонент:

class Car
{
  my::unique_ptr<Engine> engine; // Engine - базовый класс для разных видов моторов, и тут хранится один из них, понятное дело, уникальный для каждой машины

  // Плюс еще 100500 каких-то переменных-членов
}

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

Здравствуйте, Went, Вы писали:

W>Ну, довольно таки надо. Название "уникальный" говорит только о том, что он уникально владеет своим объектом и копирование через клонирование объекта этот принцип не нарушает, ведь так?
W>А для чего это надо... Ну, допустим, наш объект реализован через систему компонент:
W>

W>class Car
W>{
W>  my::unique_ptr<Engine> engine; // Engine - базовый класс для разных видов моторов, и тут хранится один из них, понятное дело, уникальный для каждой машины

W>  // Плюс еще 100500 каких-то переменных-членов
W>}
W>

W>И, допустим, я хочу мочь копировать этот объект, размножать. Если использовать стандартный уникальный указатель, мне придется писать конструктор копирования и присваивания и следить за его адекватностью, добавляя все новые и новые поля и вызывая код клонирования для engine руками. А если я использую свой, с автоматическим клонированием, то, очевидно, мне будет достаточно автоматически сгенерированного.

В чем ты тогда сомневаешься, я не пойму. Если тебе рельно это нужно — вот это и есть ответ на твой вопрос.

Здравствуйте, Went, Вы писали:

W>Ну, довольно таки надо. Название "уникальный" говорит только о том, что он уникально владеет своим объектом и копирование через клонирование объекта этот принцип не нарушает, ведь так?

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

Здравствуйте, Alexander G, Вы писали:

W>>Ну, довольно таки надо. Название "уникальный" говорит только о том, что он уникально владеет своим объектом и копирование через клонирование объекта этот принцип не нарушает, ведь так?

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

Признаться, не вижу я здесь никакого сюрприза. Чего еще можно ожидать от unique_ptr, допускающего копирование?

Для пущей надежности его можно определить как-то так:

template <typename, typename = void>
class UniquePtr;

template <typename T>
class UniquePtr<typename T, std::enable_if_t<IsCloneable<T>::value>>
{
// . . .
};

Ну или по-модному:

template <typename T>
class UniquePtr
{
  static_assert(IsCloneable<T>::value, "T shall be cloneable");
// . . .
};

Причем, ИМХО, слово "unique" является ключевым для описания семантики, поэтому я бы даже не искал ему замену. Просто unique, допускающий копирование — и этим все сказано, по-моему.

Здравствуйте, Went, Вы писали:

W>...И, допустим, я хочу мочь копировать этот объект, размножать. Если использовать стандартный уникальный указатель, мне придется писать конструктор копирования и присваивания и следить за его адекватностью, добавляя все новые и новые поля и вызывая код клонирования для engine руками. А если я использую свой, с автоматическим клонированием, то, очевидно, мне будет достаточно автоматически сгенерированного.

Наверное, имеет право на жизнь.

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

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

Здравствуйте, rg45, Вы писали:

R>Признаться, не вижу я здесь никакого сюрприза. Чего еще можно ожидать от unique_ptr, допускающего копирование?

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

Назвать можно было бы, например, deep_copy_ptr, или, если главный акцент на unique, то unique_ptr_copyable.

Здравствуйте, Alexander G, Вы писали:

AG>Назвать можно было бы, например, deep_copy_ptr, или, если главный акцент на unique, то unique_ptr_copyable.

Ну, если длина названия не смущает, то конечно, лучще, когда вся специфика явно обозначена. Только я бы переставил "copyable" в начало — copyable_unique_ptr — больно уж непривычно видеть "ptr" в середине.

Здравствуйте, σ, Вы писали:

σ>Шон Пэрен показал, почему это нельзя называть ptr.

Хорошо бы ссылку привести. И как тогда называть эти штуки?

Здравствуйте, Went, Вы писали:

W>Здравствуйте, andyp, Вы писали:

A>>У unique_ptr семантика перемещения. Копирования нет. Если ты к своему указателю при копировании клонирование прикрутишь (это потенциально дорого), то он, очевидно, будет клонировать в самых разных контекстах, например при передаче в функции по значению, возврате значения из функции и т.п. Реши, оно тебе надо, а?
W>Ну, довольно таки надо. Название "уникальный" говорит только о том, что он уникально владеет своим объектом и копирование через клонирование объекта этот принцип не нарушает, ведь так?
W>А для чего это надо... Ну, допустим, наш объект реализован через систему компонент:
W>

W>class Car
W>{
W>  my::unique_ptr<Engine> engine; // Engine - базовый класс для разных видов моторов, и тут хранится один из них, понятное дело, уникальный для каждой машины

W>  // Плюс еще 100500 каких-то переменных-членов
W>}
W>

W>И, допустим, я хочу мочь копировать этот объект, размножать. Если использовать стандартный уникальный указатель, мне придется писать конструктор копирования и присваивания и следить за его адекватностью, добавляя все новые и новые поля и вызывая код клонирования для engine руками. А если я использую свой, с автоматическим клонированием, то, очевидно, мне будет достаточно автоматически сгенерированного.

Я тоже предлагаю подумать, где и как может применяться этот "указатель" (в полях класса, в параметрах функций, ...). Насколько нужно слово unique в названии, если он только и делает, что клонирует. Если окажется, что этот "указатель" нужен только чтобы помочь клонировать поля класса, может эту штуку стоит назвать как-нибудь clonable_slot?

σ>>Шон Пэрен показал, почему это нельзя называть ptr.

VT>Хорошо бы ссылку привести. И как тогда называть эти штуки?

http://sean-parent.stlab.cc/presentations/2017-01-25-better-code/2017-01-25-better-code.pdf#page=110

Здравствуйте, σ, Вы писали:

VT>>Хорошо бы ссылку привести. И как тогда называть эти штуки?

σ>http://sean-parent.stlab.cc/presentations/2017-01-25-better-code/2017-01-25-better-code.pdf#page=110

Блин, логично. Нарушение принципа наименьшего удивления:

const clone_ptr<Obj> p1(new Obj(args...));
const auto p2 = p1;
assert(p1 != p2);