А был ли мальчик? (помянем плюсы)

[Мальчик-Одуванчик]

3. заменить shared_ptr -> unique_ptr.

???

In collections.

Ну, shared_ptr в collections точно работает, а вот предлагаемая замена...

auto_ptr не работает.

[AndreyT]

Ну, shared_ptr в collections точно работает, а вот предлагаемая замена...

Одной из причин разработки unique_ptr как раз и было предоставление не-shared "умного указателя", совместимого (в отличие от auto_ptr) со стандартными контейнерами. Функциональность shared_ptr избыточна (и, поэтому, его реализация более громоздка и менее эффективна) в ситуациях, когда никакого sharing-а фактически нет.

[Prosche]

Кстати да, интересно было бы понять как именно развивается язык С++.

Вроде новые стандарты принимаются - 11, 14, 17й...

У меня вот коллега всё ратует на новый стандарт перейти. Я вроде бы не против - практический Boost можно бы было выкинуть, от shared_ptr избавиться, но не настолько мне это нужно, чтобы калории на это тратить...

Дык а зачем переписывать, начните использовать в новом коде, а старый оставьте как есть. Или вы на древнем компиляторе? -std=c++11 и вперед!

[Medium-rare]

Одной из причин разработки unique_ptr как раз и было предоставление не-shared "умного указателя", совместимого (в отличие от auto_ptr) со стандартными контейнерами. Функциональность shared_ptr избыточна (и, поэтому, его реализация более громоздка и менее эффективна) в ситуациях, когда никакого sharing-а фактически нет.

Если std::unique_ptr устраивает в контейнере, то до тех пор, пока программист не пытается выполнить над ним одну из кучки законных операций. А избыточный std::shared_ptr просто всегда на его месте устроит. Не то, чтобы я призывал то или другое использовать в котейнерах.

[AndreyT]

Одной из причин разработки unique_ptr как раз и было предоставление не-shared "умного указателя", совместимого (в отличие от auto_ptr) со стандартными контейнерами. Функциональность shared_ptr избыточна (и, поэтому, его реализация более громоздка и менее эффективна) в ситуациях, когда никакого sharing-а фактически нет.

Если std::unique_ptr устраивает в контейнере, то до тех пор, пока программист не пытается выполнить над ним одну из кучки законных операций.

Это о каких именно "законных операциях" идет речь?

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

[M. Ridcully]

Кстати да, интересно было бы понять как именно развивается язык С++.

Вроде новые стандарты принимаются - 11, 14, 17й...

У меня вот коллега всё ратует на новый стандарт перейти. Я вроде бы не против - практический Boost можно бы было выкинуть, от shared_ptr избавиться, но не настолько мне это нужно, чтобы калории на это тратить...

Дык а зачем переписывать, начните использовать в новом коде, а старый оставьте как есть. Или вы на древнем компиляторе? -std=c++11 и вперед!

С компиляторами всё в порядке.
Код у нас, в-принципе, один.
Пока речь шла просто о том, чтобы изменить Makefiles и убедиться, что не регрессий. _Теоретически_, вроде, их быть не должно. Но вот вроде у всех пока есть чем заняться, и просто оправдать это усилие ради довольно эзотерической цели (ИМХО) мне сложно.

[Prosche]

С компиляторами всё в порядке.
Код у нас, в-принципе, один.
Пока речь шла просто о том, чтобы изменить Makefiles и убедиться, что не регрессий. _Теоретически_, вроде, их быть не должно. Но вот вроде у всех пока есть чем заняться, и просто оправдать это усилие ради довольно эзотерической цели (ИМХО) мне сложно.

Хеххх. Усилия... Я вот заканчиваю щас миграцию солюшенов из Студии (msbuild) на симейк+нинзя. Самый большой из которых на 498 плюсовых, питоновских и шарповских проектов, вот это переход, а у вас так, работы на полдня с перекурами.

[Medium-rare]

Это о каких именно "законных операциях" идет речь?

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

Code: Select all

static std::vector<std::unique_ptr<int>> vctA;

void blah()
{
    /// enjoy
    std::vector<std::unique_ptr<int>> vctB(vctA.begin(), vctA.end());
}

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

Это предложение предлагает правильность идеи использования unique_ptr в контейнерах? Но постараться...

[AndreyT]

Это о каких именно "законных операциях" идет речь?

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

Code: Select all

static std::vector<std::unique_ptr<int>> vctA;

void blah()
{
    /// enjoy
    std::vector<std::unique_ptr<int>> vctB(vctA.begin(), vctA.end());
}

Ну то есть эта попытка завершилась безуспешно. Поэтому не совсем понятен комментарий "enjoy".

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

Это предложение предлагает правильность идеи использования unique_ptr в контейнерах? Но постараться...

Не совсем понятно, что вы здесь хотите сказать.

[Medium-rare]

AndreyT,
Как тип для помещения в контейнер:

shared_ptr удовлетворяет все операции над контейнерами.
unique_ptr удовлетворяет часть операций над контейнерами.

Более ничего.

[ksi]

AndreyT,
Как тип для помещения в контейнер:

shared_ptr удовлетворяет все операции над контейнерами.
unique_ptr удовлетворяет часть операций над контейнерами.

Более ничего.

Чем плохи обычные пойнтеры, кроме того, что надо следить за памятью? Ну и хорошо, что надо, обычно это как то дисциплинирует и заставляет продумывать дизайн. А что новое дают те же ламбды функции в отличии от С указетелей на функции по большому счету? Только что можно лениться и не передавать лишние параметры, как аргументы? Что все же принципиально нового есть в C++ 11, 14, ... что нельзя было сделать раньше и что значительно расширяет возможности? На мой вкус единственный бесспорный кандидат это vector и иже с ними. Ну невозможно работать с fixed sized array. Ну и операции со строками. Threading по прежнему примитивный, что совсем не согласуется с требованиями сегодняшнего дня.

[Medium-rare]

не согласуется с требованиями сегодняшнего дня.

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

[M. Ridcully]

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

А что именно вам от threading не хватает?
ИМХО самое главное достоинство - что он там, наконец, появился, как средство самого языка / стандартной библиотеки.

А вообще ваш ответ - не про threading, а выше - наглядная демонстрация того, что плюсам, возможно, пора на свалку истории. Нельзя бесконечно добавлять фичи, не убирая их. Когда над одним кодом работают люди с весьма разным представлением о том, что такое правильный C++ код, это неизбежно рождает монстров. Никакие линты не помогут.

[ksi]

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

А что именно вам от threading не хватает?
ИМХО самое главное достоинство - что он там, наконец, появился, как средство самого языка / стандартной библиотеки.

А вообще ваш ответ - не про threading, а выше - наглядная демонстрация того, что плюсам, возможно, пора на свалку истории. Нельзя бесконечно добавлять фичи, не убирая их. Когда над одним кодом работают люди с весьма разным представлением о том, что такое правильный C++ код, это неизбежно рождает монстров. Никакие линты не помогут.

Threading это отдельная тема, у нас очень серьезные и нестандартные задачи с точки зрения threading, еоторые просто невозможно имплементировать стандартными средставими типа мьютексов (без огромной потери перформанса), поэтому встроенные средства C++ бесполезны, у нас свои библиотеки. Стандарнтые средства как бы слишком примитивны.

С++ важен своим быстродействием. Быстрей ничего еще не придумали. А это очень важно во многих сферах. Главное это не убить

[M. Ridcully]

Threading это отдельная тема, у нас очень серьезные и нестандартные задачи с точки зрения threading, еоторые просто невозможно имплементировать стандартными средставими типа мьютексов (без огромной потери перформанса), поэтому встроенные средства C++ бесполезны, у нас свои библиотеки. Стандарнтые средства как бы слишком примитивны.

Ну а на основе чего эти ваши самые библиотеки сделаны?
Если вы про lock free и проч., то это тоже можно на основе теперь стандартных средств C++ делать.
Но вообще я вам сочувствую. Сколько раз ни сталкивался с "нестандартным тредингом", всегда в конечном счёте это было болью. Даже в тех случаях, когда работало.

Честно говоря думал, что вы имели в виду что-то вроде того, что в Golang. Там действительно с точки зрения threading что-то новое, более-менее.

С++ важен своим быстродействием. Быстрей ничего еще не придумали. А это очень важно во многих сферах. Главное это не убить

Как сказать, на C тоже можно писать довольно быстро.