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

lpd>>>Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++.
_>>Ну естественно в ffmpeg написанном на C (и ассемблере) не используются последние новинки C++. ))) А как ты хотел то? )
lpd>Скорость копирования DDR-памяти порядка 10Гбайт/сек, и делать move всех мелких объектов нет никакого смысла. Речь о том, что ffmpeg это тот самый редкий случай, когда затраты времени на копирование могут играть роль. И там простые буфера памяти — даже не классы контейнеров. Мы видим, что в реализациях алгоритмов, где move-семантика может понадобиться, ей нет места, и может не быть места даже ООП.

Если ты хочешь добиться максимально возможной для процессора производительности обработки массивов данных (я кстати работал вот прямо с такими цифрами), то единственный путь — это использование SIMD (кстати в ffmpeg всё как раз на этом и построено). Вне зависимости от используемого языка. Если говорить про C++, то в нём есть несколько интересных оригинальных техник, облегчающих работу с SIMD.

lpd>Я не могу придумать ни одного примера программы, для которой move-семантика была бы реально нужна.
lpd>Кроме того, помним, что ООП нужен для моделирования объектов — в основном, для наглядности архитектуры. Понятие указателя наглядно, как наглядно и понятие ссылки. А что такое rvalue-ссылка? Это какой-то синтаксический хак, позволяющий поставить && и изменить поведение программы.

Показываю конкретный и довольно известный случай. У тебя есть некий объект, который содержит некие тяжёлые ресурсы (большой объём памяти или ещё что-то) и автоматически управляет ими (в конструкторе/деструкторе). Так вот, расскажи как ты реализуешь создание и возврат (через return) данного объекта из функции без семантики перемещения? Чтобы и не надо было руками следить за временем жизни указателя и не было бы потери эффективности.

lpd>Может не нужно реализовывать в C++ нереализуемое, и оставить и объекты, и старое доброе ручное управление памятью — для тех случаев, когда оно нужно? C++, в том числе, ценен схожестью c C и близостью к ассемблеру/оборудованию — и в этом его конек с точки зрения эффективности.

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