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

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

lpd>>что я и обосновал, т.к. мне доводилось писать кодеки с нуля и я сталкивался с возникающими проблемами.
S>Пока ничего не обосновал.

Повторю:

Дело не в RAII и перегрузке операторов, а в том, что математические алгоритмы плохо ложатся на объектную модель, в отличии от моделей типичных предметных областей. В том числе в реальном кодеке сжатия видео к данным одних объектов все время будет нужен доступ и изменение из других, и это нарушит все ООП.

Если ты считаешь, что объектность и классы не основное в C++, из-за чего его и применяют, то у нас разное видение этого вопроса.

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

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

Там, AFAIK, нет такой проблемы, т.к. в таких условиях стандартная библиотека C++ не используется, как и часть языковых возможностей (вроде исключений, для поддержки которых нужна stdlib).

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

lpd>Повторю:
lpd>

lpd>Дело не в RAII и перегрузке операторов, а в том, что математические алгоритмы плохо ложатся на объектную модель, в отличии от моделей типичных предметных областей. В том числе в реальном кодеке сжатия видео к данным одних объектов все время будет нужен доступ и изменение из других, и это нарушит все ООП.

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

Ты, может, удивишься, но с тобой также не согласен Степанов — автор STL. Почитай его книги: Elements of Programming (Начала программирования), From Mathematics to Generic Programming (От математики к обобщенному программированию). Откроешь для себя много нового.
Кроме всего прочего ты в курсе, зачем Страуструп придумал С++? Чтобы было удобнее заниматься математическим моделированием.
Так что рекомендую для начала ознакомиться с матчастью.

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

lpd>Повторю:
lpd>

lpd>Дело не в RAII и перегрузке операторов, а в том, что математические алгоритмы плохо ложатся на объектную модель, в отличии от моделей типичных предметных областей. В том числе в реальном кодеке сжатия видео к данным одних объектов все время будет нужен доступ и изменение из других, и это нарушит все ООП.

Давай пойдем по кругу, я тоже повторю:

Вы видать хотите втянуть учение Гради Буча туда куда не надо.

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

Вообще правильный вопрос в этой ветке должен звучать так: "почему стоит применять С, если есть возможность применять С++?"

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

N>Кроме всего прочего ты в курсе, зачем Страуструп придумал С++? Чтобы было удобнее заниматься математическим моделированием.

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

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

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

Б>>Я знаю что быстрее, std::sort это любимый пример адептов шаблонов. Сортировка это слишком примитивный пример.
S>Так на других примерах все будет еще хуже для С. Можешь взять любой алгоритм из boost.graph сравнить его со своей реализацией на С с поддержкой произвольных структур данных.

Кстати, приходилось сравнивать алгоритм с бинарном графом на boost::graph и на своем простом графе. boost::graph отстал на 30%, что вообщем то неплохо, однако было недостаточно хорошо, т.к. расширенные фичи буст мне были не нужны.

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

S>Вообще правильный вопрос в этой ветке должен звучать так: "почему стоит применять С, если есть возможность применять С++?"

Основная причина в все еще совместимости. Код на C может напрямую вызываться из C++ — обратное неверно. А ядра многих ОС(например, Linux) написаны на C, поэтому желательно не усложнять использование кода напрямую из ядра.

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

lpd>Можно написать программу с простой и расширяемой архитектурой на "C с классами", а можно нагородить шаблонов и r-value reference, в которых сам автор через пол года не разберется, не получив никакого выигрыша. Первый вариант будет лучше.

Есть и 3-й вариант. Например, STL. Разобраться легко, шаблоны есть, "С с классами" нет. Работает хорошо.

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

lpd>Однако я понимаю, почему для вычислительных алгоритмов обычно используют обычный C: там обычно несколько длинных функций, часто параллельных. И, в отличие от прикладных приложений, объектно моделировать нечего. C++ больше подходит для больших программ, к которым потом эти вычисления на C при необходимости легко подключить.
Приведи же пример того, что обычно используют С для алгоритмов! Где? Для каких таких алгоритмов?

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

Хватит уже этого голословия. Проекты на С в области алгоритмов — это древность типа ffmpeg. Их просто на С++ не переписывают. Всё остальное — это С++ и всё. Я приводил примеры из своей области компьютерного зрения, где С++ библиотеки вытесняют С-библиотеки. Другой пример? gcc! Блин, сам компилятор языка С переписали на С++ из-за возросшей сложности.

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

lpd>Основная причина в все еще совместимости. Код на C может напрямую вызываться из C++ — обратное неверно. А ядра многих ОС(например, Linux) написаны на C, поэтому желательно не усложнять использование кода напрямую из ядра.
Этот аргумент однозначно принимается.

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

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

lpd>>А с кодеками еще хуже. В принципе, свой кодек я написал на C++, и там были несколько классов(кадр, битовый энкодер, сам кодек), но этим и ограничилось, т.к. при добавлении более низкоуровневых классов неизбежно на каждом шагу нарушалась инкапсуляция.
N>С кодеками всё намного хуже. Они так сложны, что их пишут на С++. Покажи мне современный кодек на С.

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

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

S>>Так на других примерах все будет еще хуже для С. Можешь взять любой алгоритм из boost.graph сравнить его со своей реализацией на С с поддержкой произвольных структур данных.
lpd>Кстати, приходилось сравнивать алгоритм с бинарном графом на boost::graph и на своем простом графе. boost::graph отстал на 30%, что вообщем то неплохо, однако было недостаточно хорошо, т.к. расширенные фичи буст мне были не нужны.

PavelCH:

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

Насколько я знаю, для потокобезопасной статической инициализации ничего особенного делать не нужно, "обёртки" появляются, когда имеет место динамическая инициализация статических объектов. Однако в C инициализатором объекта со static или thread storage duration может быть только константное выражение или строковый литерал, а динамическая инициализация таких объектов там не предусмотрена в приципе. Т.е. в C "лишнего кода" от динамической инициализации статиков не будет не потому, что она там реализована более эффективно, а потому что воспользоваться таковой там вообще нельзя.

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

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

Опять про ООП! С++ != ООП. Его в математике используют с перегрузками функций, функторами, обобщёнными вычислениями и т.д. и т.п. Автор стандартной библиотеки С++ является также известным критиком ООП. Мы живём уже давно в 21 веке!

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

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

lpd>>Основная причина в все еще совместимости. Код на C может напрямую вызываться из C++ — обратное неверно. А ядра многих ОС(например, Linux) написаны на C, поэтому желательно не усложнять использование кода напрямую из ядра.
S>Этот аргумент однозначно принимается.

Это почему? В user space использование C++ из C также просто как и наоборот. В kernel space не работают стандартные библиотеки как C так и C++, так что не весь код на C там можно использовать.

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

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

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

N>Опять про ООП! С++ != ООП. Его в математике используют с перегрузками функций, функторами, обобщёнными вычислениями и т.д. и т.п. Автор стандартной библиотеки С++ является также известным критиком ООП.

Значит, в этом мы расходимся.
Возвращаясь к кодекам — открой любой современный кодек на C++ и ты увидишь макароны кода внутри больших функций, за небольшим фасадом ООП.

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

A>Это почему? В user space использование C++ из C также просто как и наоборот.
Это как? нужно писать С-обертки для методов классов.

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

N>>Опять про ООП! С++ != ООП. Его в математике используют с перегрузками функций, функторами, обобщёнными вычислениями и т.д. и т.п. Автор стандартной библиотеки С++ является также известным критиком ООП.
lpd>Значит, в этом мы расходимся.
Это не "мы" расходимся, а ты и вся индустрия со всеми С++ стандартами.

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

lpd>Это как? нужно писать С-обертки для методов классов.

Это если целью является методы классов из C вызывать. Мне обычно нескольких функций, внутри которых живет C++, хватает. Да и в этом случае ничем не хуже просто C получается — ты ж из C вызываешь, вот он наименьшее общее используемое подмножество и диктует.

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

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

N>>>Опять про ООП! С++ != ООП. Его в математике используют с перегрузками функций, функторами, обобщёнными вычислениями и т.д. и т.п. Автор стандартной библиотеки С++ является также известным критиком ООП.
lpd>>Значит, в этом мы расходимся.
N>Это не "мы" расходимся, а ты и вся индустрия со всеми С++ стандартами.

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