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

[AndreyT]

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

???

Речь, по-видимому, идет о том, что в Boost нет unique_ptr, по каковой причине раньше они везде использовали shared_ptr, даже там где по идее достаточно было unique_ptr.

Теперь, с появлением unique_ptr, имеет смысл выборочно поменять shared_ptr на unique_ptr: именно и только там, где по сути изначально нужен именно unique_ptr.

[M. Ridcully]

Речь, по-видимому, идет о том, что в Boost нет unique_ptr, по каковой причине раньше они везде использовали shared_ptr, даже там где по идее достаточно было unique_ptr.

Теперь, с появлением unique_ptr, имеет смысл выборочно поменять shared_ptr на unique_ptr: именно и только там, где по сути изначально нужен именно unique_ptr.

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

[Medium-rare]

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

???

In collections.

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

[M. Ridcully]

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

???

In collections.

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

А что не так?

Но я слишком коротко / не совсем точно написал. AndreyT выше написал правильней. Контейнеры - это просто частный случай.

[Medium-rare]

Наткнулся на два или три параллельных обсуждений когда-то. Вроде такого. Ну очень частный случай.

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

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 тоже можно писать довольно быстро.

[AndreyT]

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

И что?

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

Во-вторых, ожидание доступности всех операций контейнера - это некий С++98-стиль мышления. В С++98 первичен был сам контейнер: доминировали жесткие требования контейнера, а элемент вынужден был волей-неволей под них подстраиваться, даже если это больше нигде никому не было нужно. И это, вообще-то, плохо, ибо с точки зрения здравого смысла должно быть как раз таки наоборот - свойства элемента контейнера должны быть первичны. И они должны прозрачно проноситься (форвардиться) сквозь контейнер в окружающий мир, также как это работает с "рукописными" голыми массивами, списками и т.п.

Причем в С++98 такое жесткое доминирование правил контейнера сделали отнюдь не потому что это считалось "правильным", а просто потому, что в языке не было адекватных средств для того, чтобы сделать по-другому. Это стало возможно только в С++11. Но даже и в С++98 допустимые операции над контейнером зависели от определенных свойств элемента, хотя бы на интерфейсном уровне - например, возможность или возможность конструкции по умолчанию для элемента влияла на большое количество возможностей вызова методов контейнера.

[AndreyT]

Что все же принципиально нового есть в C++ 11, 14, ... что нельзя было сделать раньше и что значительно расширяет возможности?

Ну с такой точки зрения ничего не "расширяет возможности". Все что есть в С++ можно и всегда будет можно написать и на С, то есть тут как ни старайся, "возможностей" не "расширишь".

Тем не менее, поддержка rvalue references и move semantics - это огромное "расширение возможностей". А также есть auto, возможности делегировать конструкторы... нет смысла копипастить то, что так уже сто раз копипастено.

[Pantigalt]

Ой, а дайте хороший линк где почитать про лямбды в С++ ?
А то лямбды отдельно знаю, в контексте Скалы = знаю, потом и Джавы тоже, а в контексте С++ - нет. Чувствую много пропустила

А чего там знать? Лямбда и в Африке - лямбда. Прочитать один раз синтаксис достаточно: http://en.cppreference.com/w/cpp/language/lambda

Вы неправы.
Не знаю как в Джаве но в C# lambda передают только по ссылке.
В С++ 11 можно по значению и по ссылке. При этом используется конструктор копирования.
В С++ 14 можно указывать как именно перемешать обьект в лямбду - copy или move конструктором.
Можно указывать модификаторы.

По мне так большая разница.

[AndreyT]

Ой, а дайте хороший линк где почитать про лямбды в С++ ?

Ну тут в первую очередь надо понимать, что лямбды в С++ - это (с небольшой натяжкой) просто syntactic sugar, надстроенный над обычными классами. Т.е. лямбда - это просто более компактный синтаксис для локального объявления некоего "безымянного" класса и локального объекта этого класса (closure object). С этой точки зрения можно сказать, что "лямбды" в С++ существовали всегда (опять же, с небольшой натяжкой). Просто раньше для создания "лямбды" надо было выписывать этот локальный класс вручную, используя обыкновенный синтаксис. А теперь то же самое просто записывается более компактно, через новый компактный shorthand синтаксис лямбда-выражения.

Материалов, описывающих эту естественную взаимосвязь, найти можно много
https://eli.thegreenplace.net/2011/11/1 ... das-in-c11

Понимание этого факта существенно облегчает понимание того, что такое лямбда в С++. Поэтому тут встает вопрос: а понимаете ли вы уже все, что нужно, для "ручной" реализации такого класса средствами "классического" С++? Если да, то бОльшая часть понимания того, что такое лямбда, у вас уже есть.

[Pantigalt]

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

По поводу обычных указателей ну вот навскидку:
1. В больших проектах вы за всеми указателями не уследите.
2. Код проще если есть обертка над указателем, в случае исключений хочется чтобы память освобождалась автоматически.

Лямбды
1. Эффективнее чем указатели на функцию (если не используется контекст).
2. Удобнее в использовании