Информация об изменениях

Сообщение Re[8]: Visual C# vs C++. Надо сравнить перспективы. от 07.01.2017 20:48

Изменено 07.01.2017 20:55 lpd

Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:

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


lpd>>Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++.

_>Ну естественно в ffmpeg написанном на C (и ассемблере) не используются последние новинки C++. ))) А как ты хотел то? )

Скорость копирования DDR-памяти порядка 10Гбайт/сек, и делать move всех мелких объектов нет никакого смысла. Речь о том, что ffmpeg это тот самый редкий случай, когда затраты времени на копирование могут играть роль. И там простые буфера памяти — даже не классы контейнеров. Мы видим, что в реализациях алгоритмов, где move-семантика может понадобиться, ей нет места, и может не быть места даже ООП.
Я не могу придумать ни одного примера программы, для которой move-семантика была бы реально нужна.
Кроме того, помним, что ООП нужен для моделирования объектов — в основном, для наглядности архитектуры. Понятие указателя наглядно, как наглядно и понятие ссылки. А что такое rvalue-ссылка? Это какой-то синтаксический хак, позволяющий поставить && и изменить поведение программы.
Может не нужно реализовывать в C++ нереализуемое, и оставить и объекты, и старое доброе ручное управление памятью — для тех случаев, когда оно нужно? C++, в том числе, и ценен схожестью c C и близостью к ассемблеру/оборудованием.
Re[8]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:

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


lpd>>Например, отсутствие копирования было бы полезно при разработке видео-кодеков. Но ffmpeg написан вообще на C, и я не вижу в подобных приложениях применения последним стандартам С++.

_>Ну естественно в ffmpeg написанном на C (и ассемблере) не используются последние новинки C++. ))) А как ты хотел то? )

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