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

lpd>Я бы не ставил знак равенство между авторами стандартов, которым интересен язык программирования как объект исследования, и индустрией, которая решает прикладные задачи на C++.

Интересно было бы понять, что вы этим пытаетесь сказать: что вы-то уж точно "индустрия", которая решает прикладные задачи и знает что почем? В отличии от всяких там авторов-теоретиков.

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

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

lpd>>Я бы не ставил знак равенство между авторами стандартов, которым интересен язык программирования как объект исследования, и индустрией, которая решает прикладные задачи на C++.

S>Интересно было бы понять, что вы этим пытаетесь сказать: что вы-то уж точно "индустрия", которая решает прикладные задачи и знает что почем? В отличии от всяких там авторов-теоретиков.

То, что в стандарте появились новшества вроде rvalue-reference, не значит, что все сразу должны их везде применять. Этого и не происходит, ибо пользы от этих усложнений немного.

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

lpd>То, что в стандарте появились новшества вроде rvalue-reference, не значит, что все сразу должны их везде применять. Этого и не происходит, ибо пользы от этих усложнений немного.

Складывается впечатление, что вы выдумали себе какой-то странный мир и пытаетесь с ним упорно бороться, попутно рассказывая окружающим о своих ощущениях и успехах. Хотя окружающие воспринимают ваши слова как заурядные заблуждения, уж простите.

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

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

lpd>>То, что в стандарте появились новшества вроде rvalue-reference, не значит, что все сразу должны их везде применять. Этого и не происходит, ибо пользы от этих усложнений немного.

S>Складывается впечатление, что вы выдумали себе какой-то странный мир и пытаетесь с ним упорно бороться, попутно рассказывая окружающим о своих ощущениях и успехах. Хотя окружающие воспринимают ваши слова как заурядные заблуждения, уж простите.

Я уже не раз встречал этот комментарий где-то на просторах livejournal. Что у вас разговорник тролля какой-то есть?

N> Ну и работа с сетью boost::asio

работа с сетью == boost:asio ? что это за тулкито-поклонство.

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

[]

Б>Напомню тема разговора не что лучше C или C++ а стоит ли писать сложные вычисления (такие как декодирование видео) на C++ и если да, какие преимущества это дает.

Декодирование видео это далеко не только сложные вычисления, как это многие себе представляют. Вычислений там, конечно хватает, но есть еще куча всякого, типа —
1. устойчивость к кривым входным данным и куча эмпирики вокруг этого. чисто одна обработка ошибок на исключениях может дать буст в районе 5%
2. распараллеливание — мало кому нужен кодек, который долбит в один поток (кроме референса, конечно). управление всем этим добром на С — горе. а с учетом того, что рано или поздно это выливается в некий шедулер с управлением пула потоков, зависимостями и прочими радостями уже для всего пайплайна (напр. транскодирование) — горе вдвойне
3. поддержка кучи разных фич, в рамках одно стандарта. напр. разные цветовые пространства (RGB, YUV), разный сабсэмплинг (420/422 ...), разный memory layout — planar/interleaved ..., разный bit depth. все это добро нужно поддерживать и зачастую все это добро достаточно прозрачно для собст. алгоритмов — шаблоны рулят
4. низкоуровневая оптимизация (инлайн, симды, кэш и прочее). компайл тайм монстры на define — чудовища, порожденные именно С.

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

Б>Я все ещё не могу понять, как на это повлиял именно C++?
Б>В целом мне кажется Pzz прав насчет того, что какие то критичные по времени выполнения вещи стоит писать в процедурном стиле с использованием собственных специально оптимизированных под задачу структур данных. В таком подходе, скорее всего, многие возможности С++ не будут использоваться.

Что ты подразумеваешь под "процедурным стилем" и какому стилю ты его противопоставляешь?
STL это по-твоему какой стиль? Возможности C++ в нём используются очень интенсивно, что даёт удобство и скорость. Если смотреть на аналоги на C — например GLib — то сразу в глаза бросаются тормоза и неудобство, которые вытекают как раз из отсутствия возможностей C++

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

Б>Мне сложно тут что-то комментировать так как с OpenCV дела не имел. Но это все равно выглядит как ошибки проектирования изначальной библиотеки. Потом пришли более грамотные специалисты и сделали все красиво, а C++ тут уже был вторичен, на мой взгляд.

Возьми одну простую функцию — qsort — и покажи какой бы у неё был интерфейс на C будь он сделан "красиво грамотными специалистами", да так чтобы по возможностям не уступал std::sort.

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

Pzz>На мой взгляд, нигде. Но меня не поймут и наставят минусов
Попробуй переписать на С вот это http://www.antigrain.com/

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

lpd>Просто есть разница между моделированием объектов реального мира с помощью классов в энтерпрайз приложении, и алгоритмом, который описывает низкоуровневые вычисления. Возьми любой современный кодек, и ты увидишь, что C++ там есть но только на самом высоком уровне интерфейса кодека. В принципе, от этого есть некоторая польза, но меньшая, чем польза от ООП для обычных приложений.
lpd>Например, в реализации IP-стека обработку входящего или исходящего пакета можно реализовать последовательностью фильтров для каждого из уровней протоколов TCP/IP. А в сжатии видео так сделать в результате не получится, т.к. на последнем уровне обработки может понадобиться доступ к данным низших уровней.

Ладно, раз "возьми любой современный кодек", возьму вышедший в мае этого года ScreenPressor 3. Открываю ф-ю декодирования Р-кадра DecompressP, вижу например строчку

ptype = ec.decodeP(ptypetab[lastptype]);

тут декодируется тип пикселя, т.е. это код уровня обработки одного пикселя, не что-то "на самом высоком уровне интерфейса кодека". Смотрю, что такое тут "ec" (entropy coder) и "ptypetab". Оказывается:

template<class EC>
class ScreenPressor: public IScreenPr, public ISquadJob {
...
    EC ec; //entropy coder: range coder for v2, ANS coder for v3
...
    typename EC::CtxP ptypetab[6]; //pixel type, context = previous value

Т.е. тип энтропийного кодера является параметром шаблона, а тип элементов массива ptypetab со статистикой типов пикселей зависит от того параметра шаблона тоже. В частности, в качестве ЕС используются

struct UseRC {
...
    template<int L> struct FixedTab { uint tab[L]; ... }

    typedef FixedTab<7> CtxP;
    int decodeP(CtxP& ptab) {... }
...

и

struct UseANS {
...
    template<int NSym> struct FixedSizeRansCtx { ... }

    typedef FixedSizeRansCtx<6> CtxP;
    int decodeP(CtxP& ptab) { ... }
...

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

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

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

DM>Т.е. тип энтропийного кодера является параметром шаблона, а тип элементов массива ptypetab со статистикой типов пикселей зависит от того параметра шаблона тоже.

Если ты о типах пикселей YUV444/YUV422/...,то реально в памяти для кадра хранятся не совокупности пикселей разных цветов для каждой точки, а 3 плоскости разного размера для каждого цвета. Поэтому польза от такого шаблона может быть только при чтении или сохранении в поток, если в потоке пиксели разных плоскостей хранятся вместе.

DM>в результате один и тот же код компрессии-декомпрессии работает с разными реализациями энтропийного кодера и даже типы и размеры данных, которые он ему отдает, отличаются для двух этих случаев. Такой вот полиморфизм, причем без виртуальных методов, все статически компилится и инлайнится где надо. На Си пришлось бы или писать код два раза, или городить очень неприятные макросы, чтобы подобную подстановку кодера осуществить.

В моем кодеке тип энтропийного кодека тоже был полиморфным — но это был единственный полиморфизм в кодеке.
Я не призываю писать кодеки совсем на С, я говорю, что в этой области пользы от C++ меньше, чем в других.
Если ты возьмешь распространенный формат H.264, то в нем базовый вариант(MotionEstimation/БПФ/квантование) можно красиво реализовать на ООП. Но в стандарте также есть множество дополнений, которые желательно поддерживать, и которые немного улучшают сжатие или добавляют возможности при передаче потока. И при добавлении в кодек поддержки этих дополнений все ООП сломается.
В исходниках нескольких кодеков H.264/H.265 которые я смотрел ООП немного присутствует, но присутствуют и функции в тысячи строк.

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

lpd>Если ты о типах пикселей YUV444/YUV422/...,то реально в памяти для кадра хранятся не совокупности пикселей разных цветов для каждой точки, а 3 плоскости разного размера для каждого цвета. Поэтому польза от такого шаблона может быть только при чтении или сохранении в поток, если в потоке пиксели разных плоскостей хранятся вместе.

Судя по названию кодека ScreenPressor и ключевому слову lossless можно судить, что никакого YUV444/YUV422 там нет. Это с одной стороны.
С другой — нет ничего сложного в том, чтобы работать с тремя плоскостями и параметризовать это шаблонами.

lpd>В моем кодеке тип энтропийного кодека тоже был полиморфным — но это был единственный полиморфизм в кодеке.
lpd>Я не призываю писать кодеки совсем на С, я говорю, что в этой области пользы от C++ меньше, чем в других.

Практика показывает, что больше. Я в попиксельном алгоритме вычитания фона все низкоуровневые операции с пикселями также делал в виде шаблонов. И по мелочи паттерны от Александреску использовал (это было больше 10 лет назад). Получался компактный код, который также работал с разными цветовыми пространствами (YUV в том числе), а также на этапе компиляции специализировался различными по размеру смесями Гауссиан (тоже уровень одного пикселя). Всё работало быстрее конкурентов.
И да, там не было виртуальных функций.

lpd>Если ты возьмешь распространенный формат H.264, то в нем базовый вариант(MotionEstimation/БПФ/квантование) можно красиво реализовать на ООП. Но в стандарте также есть множество дополнений, которые желательно поддерживать, и которые немного улучшают сжатие или добавляют возможности при передаче потока. И при добавлении в кодек поддержки этих дополнений все ООП сломается.
lpd>В исходниках нескольких кодеков H.264/H.265 которые я смотрел ООП немного присутствует, но присутствуют и функции в тысячи строк.

Ты тоже путаешь понятия ООП и языка С++. После стандарта 2003 года С++ двигается в другую сторону. Степанов, Александреску — эти люди ещё тогда показывали, как эффективно можно использовать классы и шаблоны, при этом избегать замедления кода (а зачастую он становится быстрее за счёт большей информированности компилятора). И вообще избегать создания таблицы виртуальных функций при наследовании, например. Можно писать код так, чтобы избегать наличия виртуальных функций, деструкторов в том числе. Вот это и есть эффективное использование С++.

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

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

lpd>>Если ты о типах пикселей YUV444/YUV422/...,то реально в памяти для кадра хранятся не совокупности пикселей разных цветов для каждой точки, а 3 плоскости разного размера для каждого цвета. Поэтому польза от такого шаблона может быть только при чтении или сохранении в поток, если в потоке пиксели разных плоскостей хранятся вместе.

N>Судя по названию кодека ScreenPressor и ключевому слову lossless можно судить, что никакого YUV444/YUV422 там нет. Это с одной стороны.
YUV422 это способ хранения несжатых данных, и вполне может поддерживаться этим кодеком.

N>Практика показывает, что больше. Я в попиксельном алгоритме вычитания фона все низкоуровневые операции с пикселями также делал в виде шаблонов. И по мелочи паттерны от Александреску использовал (это было больше 10 лет назад). Получался компактный код, который также работал с разными цветовыми пространствами (YUV в том числе), а также на этапе компиляции специализировался различными по размеру смесями Гауссиан (тоже уровень одного пикселя). Всё работало быстрее конкурентов.
N>И да, там не было виртуальных функций.
Попиксельный алгоритм вычитания это далеко не сжатие. Если бы кому-то удалось работать эффективно с не отдельно с каждой цветовой плоскостью, а с тройкой пикселей сразу, и сжимать их в энтропийном кодере как одно 24-битовое число, это было бы большим достижением(по моему мнению). Но в H.264/MPEG такого нет.

N>Ты тоже путаешь понятия ООП и языка С++. После стандарта 2003 года С++ двигается в другую сторону. Степанов, Александреску — эти люди ещё тогда показывали, как эффективно можно использовать классы и шаблоны, при этом избегать замедления кода (а зачастую он становится быстрее за счёт большей информированности компилятора). И вообще избегать создания таблицы виртуальных функций при наследовании, например. Можно писать код так, чтобы избегать наличия виртуальных функций, деструкторов в том числе. Вот это и есть эффективное использование С++.
Я точно не стал бы использовать шаблоны или избегать полиморфизма только ради ускорения кода, по крайней мере во всей программе(сколько долей процента ускорения это бы дало?). Это допустимо только для отдельных критичных к скорости участков, и в этих участках я бы использовал plain структуры и массивы, а не шаблоны. Для меня использование всех последних фич стандартов не является самоцелью, и я предпочту простоту кода его сокращению.

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

N>>Судя по названию кодека ScreenPressor и ключевому слову lossless можно судить, что никакого YUV444/YUV422 там нет. Это с одной стороны.
lpd>YUV422 это способ хранения несжатых данных, и вполне может поддерживаться этим кодеком.

Хорошо, покажи мне устройство, которое выводит данные в этом формате. Мы же говорим про захват с экрана?
Переконвертация же из RGB(A) в YUV неизвежно приведёт к потере данных, что противоречит заявленному lossless.

lpd>Попиксельный алгоритм вычитания это далеко не сжатие. Если бы кому-то удалось работать эффективно с не отдельно с каждой цветовой плоскостью, а с тройкой пикселей сразу, и сжимать их в энтропийном кодере как одно 24-битовое число, это было бы большим достижением(по моему мнению). Но в H.264/MPEG такого нет.

Потому что оно и не нужно? Это с одной стороны.
С другой: вектор из смесей Гауссиан на пиксель + зависимость от соседей на трёх плоскостях — это тоже не так примитивно.

N>>Ты тоже путаешь понятия ООП и языка С++. После стандарта 2003 года С++ двигается в другую сторону. Степанов, Александреску — эти люди ещё тогда показывали, как эффективно можно использовать классы и шаблоны, при этом избегать замедления кода (а зачастую он становится быстрее за счёт большей информированности компилятора). И вообще избегать создания таблицы виртуальных функций при наследовании, например. Можно писать код так, чтобы избегать наличия виртуальных функций, деструкторов в том числе. Вот это и есть эффективное использование С++.
lpd>Я точно не стал бы использовать шаблоны или избегать полиморфизма только ради ускорения кода, по крайней мере во всей программе(сколько долей процента ускорения это бы дало?). Это допустимо только для отдельных критичных к скорости участков, и в этих участках я бы использовал plain структуры и массивы, а не шаблоны. Для меня использование всех последних фич стандартов не является самоцелью, и я предпочту простоту кода его сокращению.

"plain структуры и массивы" и "шаблоны" — эти понятия не противоречат друг другу!!!
"Для меня использование всех последних фич стандартов не является самоцелью" — этому стандарту уже 14 лет! Шаблоны и большая часть плюсов от их использования появилась ещё в 2003 году. Я же не просто так пишу "Степанов, Александреску". Видимо, кто-то плоховато знает С++

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

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

lpd>>Попиксельный алгоритм вычитания это далеко не сжатие. Если бы кому-то удалось работать эффективно с не отдельно с каждой цветовой плоскостью, а с тройкой пикселей сразу, и сжимать их в энтропийном кодере как одно 24-битовое число, это было бы большим достижением(по моему мнению). Но в H.264/MPEG такого нет.

N>Потому что оно и не нужно? Это с одной стороны.
N>С другой: вектор из смесей Гауссиан на пиксель + зависимость от соседей на трёх плоскостях — это тоже не так примитивно.
БПФ выполняется на пикселях каждой плоскости отдельно. Поэтому в распространенных кодеках в памяти плоскости хранятся отдельно.

N>"plain структуры и массивы" и "шаблоны" — эти понятия не противоречат друг другу!!!
N>"Для меня использование всех последних фич стандартов не является самоцелью" — этому стандарту уже 14 лет! Шаблоны и большая часть плюсов от их использования появилась ещё в 2003 году. Я же не просто так пишу "Степанов, Александреску". Видимо, кто-то плоховато знает С++
Александреску я действительно не читал, поскольку уже насмотрелся того, что любители шаблонов постят в форум С++ и мне этого хватило.
Я считаю, что основные качества хорошей програмы это алгоритм и архитектура. Язык программирования должен быть достаточным для выражения архитектуры, и при этом простым. Мне хватает классического C++, как баланса между мощностью и сложностью,(хотя я не отрицаю пользы лямбд, std::thread и шаблонов для контейнеров), и я не сторонник излишнего использования шаблонов ради сокращения программы на 100 строк или ускорения на 0.1%.

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

lpd>Мне хватает классического C++

Можно ли услышать определение "классического C++"? А то ведь Степанов представил миру STL, емнип, еще в 1993-ем году. И это было обобщенное программирование в полный рост, без "классического" ООП.

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

DM>>Т.е. тип энтропийного кодера является параметром шаблона, а тип элементов массива ptypetab со статистикой типов пикселей зависит от того параметра шаблона тоже.

lpd>Если ты о типах пикселей YUV444/YUV422/...

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

lpd>Я не призываю писать кодеки совсем на С, я говорю, что в этой области пользы от C++ меньше, чем в других.

Для меня основная польза от С++ в кодеках и обработке видео это:
1) переопределение операторов, чтобы математика с векторами, пикселями и их группами (SIMD) выражалась легко и понятно, а не нагромождением вызовов ф-й.
2) Арифметика в параметрах шаблонов, когда размер блока изображения закодирован в типе или например точность вектора (в каких единицах он выражен). Это сразу и корректность обеспечивает (не сложишь полупиксельный вектор с четвертьпиксельным по ошибке, не попытаешься запросить блок не того размера), и анроллинг циклов, ибо компилятор, зная размер блока, может более оптимально организовать его обработку.
3) Статический полиморфизм, вроде выбора энтропийного кодека выше или работе с разным числом бит на канал.

Это все мало отношения имеет к ООП, зато много отношения к фирменным фичам С++.

lpd>Если ты возьмешь распространенный формат H.264,

То его быстрая реализация x264 вообще на ассемблере по сути написана. Ибо с векторизацией у компиляторов всегда хреново было, и даже при использовании интринсиков были проблемы с неоптимальным использованием SIMD регистров, увы.

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

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

lpd>>Мне хватает классического C++

S>Можно ли услышать определение "классического C++"? А то ведь Степанов представил миру STL, емнип, еще в 1993-ем году. И это было обобщенное программирование в полный рост, без "классического" ООП.

Похоже, что вы уже занимались троллингом в этом топике, не понимая о чем речь. Само по себе это забавно, но как с вами вести диалог я не знаю.

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

lpd>>>Мне хватает классического C++

S>>Можно ли услышать определение "классического C++"? А то ведь Степанов представил миру STL, емнип, еще в 1993-ем году. И это было обобщенное программирование в полный рост, без "классического" ООП.

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

Очень хочется услышать от вас что-либо более предметное, нежели "Мне хватает классического C++...", "...я не сторонник излишнего использования шаблонов ради сокращения программы на 100 строк или ускорения на 0.1%", "Я точно не стал бы использовать шаблоны или избегать полиморфизма только ради ускорения кода...", "...я бы использовал plain структуры и массивы, а не шаблоны" и прочие подобные проявления сугубо вашего личного мнения.

Вот расскажите, что такое "классический C++"? Ибо, если кратко пробежаться по истории C++, то:

• С++ вышел в свет в 1985-ом году, без множественного наследования, пространств имен, шаблонов и исключений;
  
• в 1988-ом году в C++ добавилось множественное наследование, const-методы, protected-модификатор;
  
• в 1990-ом в C++ добавили пространства имен, шаблоны и исключения. Где-то через год-полтора после этого Степанов выбрал C++ в качестве языка для своих экспериментов в области обобщенного программирования (используемые до этого Степановым Scheme и Ada оказались недостаточно(!) выразительными для этого);
  
• в 1993-ом году про STL Степанова стало известно и начались работы по включению STL в стандарт C++;
  
• в 1994-ом году выходит "Design and Evolution of C++", в которой Страуструп говорит о C++, как о мультпарадигменном языке программирования. И о том, что не следует относиться к C++ как к "чисто объектно-ориентированному" или "чисто процедурному" языку программирования;
  
• где-то в 1994-1995-годах в C++ случайно открыли такую штуку, как template metaprogramming. Что дало старт теме программирования на C++ных шаблонах;
  
• в 1998-ом году зафиксирован стандарт C++98, в котором оказался STL от Степанова (причем и сам STL был доработан, и C++ был "дотянут" до того, чтобы уметь поддерживать STL);
  
• в 1999-ом году началось развитие Boost-а. В качестве полигона для новых идей для C++. Откуда затем в стандарт C++ придут shared_ptr и пр.;
  
• в 2001-ом году вышла книга Александреску "Modern C++ Design", которая максимально популяризировала тему программирования на C++ных шаблонов (этой теме к тому времени уже было порядка 7 лет);
  
• в 2003-ом году был зафиксирован корректирующий стандарт C++03. Приблизительно тогда же более-менее полные реализации C++98 стали доступны на большинстве платформ;
  
• 2003-й год: в Boost попадает MPL -- фреймворк для метапрограммирования на шаблонах;
  
• 2004-2005-й годы: Boost становится двигателем новых библиотек в стиле Modern C++, изрядная часть Boost-а представляет из себя header-only библиотеки шаблонов;
  
• 2011-й год: стандарт C++11. Целая куча нововведений, расширяющих возможности шаблонов и метапрограммирования: variadic templates, constexpr, auto, decltype, ...;
  
• 2014-й год: стандарт C++14. Еще больше возможностей для шаблонов и метапрограммирования, в частности, снятие ряда ограничений для constexpr, более простой auto для функций;
  
• 2015-2016: появление библиотек вроде Boost.Hana;
  
• 2017-й: зафиксирован драфт стандарта С++17, значительная его часть уже доступна в GCC и Clang, часть проектов уже активно использует C++17 в продакшене.

Можете сказать хотя бы в какой временной интервал попадает этот ваш "классический C++"?

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

S>Очень хочется услышать от вас что-либо более предметное, нежели "Мне хватает классического C++...", "...я не сторонник излишнего использования шаблонов ради сокращения программы на 100 строк или ускорения на 0.1%", "Я точно не стал бы использовать шаблоны или избегать полиморфизма только ради ускорения кода...", "...я бы использовал plain структуры и массивы, а не шаблоны" и прочие подобные проявления сугубо вашего личного мнения.

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

S>Вот расскажите, что такое "классический C++"? Ибо, если кратко пробежаться по истории C++, то:
S>

S>
• в 1998-ом году зафиксирован стандарт C++98, в котором оказался STL от Степанова (причем и сам STL был доработан, и C++ был "дотянут" до того, чтобы уметь поддерживать STL);
  S>
• в 1999-ом году началось развитие Boost-а. В качестве полигона для новых идей для C++. Откуда затем в стандарт C++ придут shared_ptr и пр.;
  S>

S>Можете сказать хотя бы в какой временной интервал попадает этот ваш "классический C++"?

Меня устраивает C++98 + отдельные фичи поздних стандартов: лямбды, std::thread, atomic, некоторые другие. STL на шаблонах, безусловно, вещь полезная, а внутренности STL меня интересуют слабо.
Как уже писал, rvalue-reference считаю ненужным усложнением. В тех редких случаях, когда нужен выигрыш в скорости от исключения копирования, лучше оптимизировать код и расположение данных в памяти вручную, в том числе обычными C-массивами.
У shared_ptr замысел хороший, но на практике проще освободить память вручную, чем вручную же заботиться о круговых ссылках + громоздкий синтаксис.