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

NB>есть реальные примеры?

Реальные NDA ясен пень

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

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

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

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

NB>есть реальные примеры?

Примерно из жизни:

class A{
    B _b;
public:
    A(B x):_b(std::move(x))
    {
       //всякий код, чтобы забыть про список инициализации членов
       x.do_smth(); //oops
    }
};

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

E>auto_ptr имел очень узкую область применения, так что на нормальный умный указатель он не особо тянул...
E>А уж всякие попытки расширения его области применения были просто грязными хаками.


Это ты про сценарии использования? А то, если подсчитать все случаи использования умных указателей, и посмотреть на долю unique_ptr, то у меня она составляет > 90% имхо.

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

NB>>есть реальные примеры?

A>Примерно из жизни:

С таким же успехом можно было написать

x.release();
//всякий код, чтобы забыть про release
x.do_smth();

ничего специфичного для мува.

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

Сорри, проглядел

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

NB>ничего специфичного для мува.

Чем богаты .

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

V>Сорри, проглядел

Вот и я проглядел, когда искал. Потом нашел, но уже запомнил .

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

A>Вот и я проглядел, когда искал. Потом нашел, но уже запомнил .

Согласен . Но это нисколько не является критикой самой концепции move. Это редкость, особенность С++ и невнимательность. С таким же успехом:

class A{
    C _c;
    B _b;
public:
    A(B x, C y) : _b(x), _c(_b.Ret_smth())
    {
    }
};

Согласитесь, если писать как попало, а классы, переменные и аргументы называть A, B, C, x, y, _c, _b — то наворотить можно многое.

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

V>Согласитесь, если писать как попало, а классы, переменные и аргументы называть A, B, C, x, y, _c, _b — то наворотить можно многое.

Это ж дистиллированный форумный трехстрочник. С названиями в боевом коде всё было норм, только это слабо помогло. Проблема-то в том, что в результате move незаметно (по крайней мере для меня, при инспекции кода) появился рукотворный зомбак, который в рамках move семантики всё еще считается объектом. В принципе, статический анализ мог бы отличать объекты без требухи при таких раскладах, но вот не было его под рукой. Тем более, это были времена msvc 2010.

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


A>Это ты про сценарии использования? А то, если подсчитать все случаи использования умных указателей, и посмотреть на долю unique_ptr, то у меня она составляет > 90% имхо.


И чем тогда тебе auto_ptr не годился?

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

A>Примерно из жизни:

A>

A>public:
A>    A(B x):_b(std::move(x))
A>    {
A>       //всякий код, чтобы забыть про список инициализации членов
A>       x.do_smth(); //oops
A>    }
A>

Это ещё что. Вот, например, когда move-семантику прикручивают к объекту, который сам себя подписывает/отписывает в каких-то сервисах...

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

A>>Это ты про сценарии использования? А то, если подсчитать все случаи использования умных указателей, и посмотреть на долю unique_ptr, то у меня она составляет > 90% имхо.
E>И чем тогда тебе auto_ptr не годился?

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

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

A>Невпихуемостью в контейнеры. Надо иногда. Ну и тем, что рука непроизвольно тянулась его покопировать . Можно же.

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

lpd>Объективно же в тех крайне редких случаях, когда есть смысл оптимизировать копирование какой-нибудь переменной, можно просто напрямую скопировать указатель на данные, по сути сделав то же самое, но без введения новых типов данных в язык.

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

E>Неконтролируемое применение семантики перемещения позволяет запутать код намного продвинутее, чем ассемблер

Любой инструмент можно использовать во вред. Перемещение, как и goto — это инструмент у которого есть своя ниша, где он полезен.

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

Ты же в курсе, что семантику auto_ptr давно исправили, а сам auto_ptr объявили устаревшим.

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

E>>Неконтролируемое применение семантики перемещения позволяет запутать код намного продвинутее, чем ассемблер

M>Любой инструмент можно использовать во вред. Перемещение, как и goto — это инструмент у которого есть своя ниша, где он полезен.

С этим не могу не согласиться...

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

lpd>>Объективно же в тех крайне редких случаях, когда есть смысл оптимизировать копирование какой-нибудь переменной, можно просто напрямую скопировать указатель на данные, по сути сделав то же самое, но без введения новых типов данных в язык.

M>C++ язык с ручным управлением памятью. Тут важно еще отслеживать, кто владеет объектом. При копировании указателя непонятно, что происходит с владением. При перемещении понятно.

В очень редких случаях когда копирование(10Гб/c для больших массивов было когда я 7 лет назад измерял) необходимо оптимизировать, можно разрулить владение вручную, как это всегда делалось, и незачем добавлять неитуитивные виды объектов к существующей простой и стройной системе.
Давайте тогда уж введем еще singleton reference — это тоже будет очень полезно. Предлагаю нотацию Type^.
Много чего можно придумать. Ну и корутины давайте в синтаксис языка вкорячим — иногда же ими пользуются.

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

E>Ну так потому и убогий. Но на мой взгляд, это косяк дизайна контейнеров STL, а то, что этот косяк не смогли выправить, а решили усугублять, пришлось и мув-семантику прикручивать такую, какую пришлось…


Ошибка имхо всё-таки в дизайне auto_ptr. Нечего было его копируемым делать. Всё одно, семантика его копирования левая. Когда копируешь, ожидаешь что

A a,b;
a = b;
assert(a==b);

Но это ж не про него.

В контейнер по тем временам всё равно не запихнешь. Могли бы просто специализацию swap предоставить, и запретить копирование.