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

_>>И так первое по теме, что я вижу, это модуль ossaudiodev. Уже смешно, т.к. помнится у меня даже под Линухом была ALSA (а не эта хрень)
_>>Больше ничего подходящего не вижу. Я что-то пропустил? Или Питон у нас теперь тоже негодный языка, как и C++? ) Перейдём к другому языку? )))
P>Ну нравится-не нравится, оно есть.

Где есть то? Вот у меня установлен Питон на компьютере (Windows), прямо сейчас. Как мне издать какой-нибудь звук с помощью него, без установки дополнительных библиотек? Кроме варианта типа os.system('start sound.wav') что-то больше ничего не приходит в голову... Но такое и в C++ есть. )))

P>Я не пойму какую мысль ты этим пытаешься дать? Что основные программные примитивы невозможно стандартизовать?

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

P>Серьезно? Ну вот во всех языках получается.

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

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

_>>Т.е. ты по сути просто за некую что ли стандартизацию популярных C/C++ библиотек, без переноса их в стандартную библиотеку языка? )
P>Я за стандартизацию основных програмных конструкций. А каким образом это будет выполнено — в виде одной библиотеки или набора — не суть важно. Чтобы я мог закладываться, что они есть в стандартной поставке.

Ну вот стандартная поставка — это как раз сомнительная идея.

P>На данный момент ситуация такая, что в других языках — "вот кирпичи, вот раствор, вот мастерок — строй", а в плюсах — "вот песок, вот глина, вот спички — строй, — а кирпичи? — ну иди на улице поищи, все опытные разработчики находят их на улице".

Поэтому не напрягаясь могут строить разные типы домов, из разных типов кирпичей. )

_>>Сейчас проблем никаких нет, т.к. каждый разработчик (ну или там команда) создаёт свою собственную коллекцию необходимых им библиотек, собранных под нужные им платформы. А вот если собрать все эти возможные варианты со всего мира в единую огромную библиотеку, то мы уже получим проблему, многогигабайтную)))
P>В том то и проблема, что каждый на свой лад решает одни и те же типовые задачи (десятки либ в плюсах на каждую типовую задачу, делающие по сути одно и то же) одними и теми же типовыми способами, которые кроме синтаксиса и вкусовщины ничем не отличаются. Это и является показателем, что данный програмный примитив необходим в стандарте.

Под создание собственной коллекции необходимых библиотек я подразумевал их скачивание и сборку, а не написание. )))

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

MTD>Ого, сколько жжение в заду заставило накатать. Читать эти потоки бреда обиженного я конечно не буду
Артёмка, отдай MTD его аккаунт

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

S>Ну тогда перечитайте, а то есть ощущение, что вы чего-то не поняли. Не мог Страуструп в "Дизайне и эволюции" писать одно, а в "Язык программирования C++" -- другое.

Взял книгу, открыл, читаю. Вижу:

— предисловие автора в к третьему русскому изданию — "Целью этих усилий было описать язык и библиотеку, которые будут исправно служить всем пользователям языка, не предоставляя каких-либо преимуществ одной группе пользователей, компании или стране перед остальными."

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

— там же — "Главной целью развития и расширения языка за эти шесть лет было стремление сделать C++ языком абстракции данных и языком объектно-ориентированного программирования в целом"

— там же — "C++ является языком общего назначения; его естественной сферой применения является системное программирование в самом общем смысле этого термина. Тем не менее, C++ с успехом используется и в других предметных областях."

И ничего, что это язык "для скорости" и вообще что это какой-то "нишевый" язык.
Так что это как раз вы суть С++ и не поняли. Теперь ваша очередь взять и перечитать.

P>>оО Это я противопоставляю? Вообще-то это вы противопоставили. Я пытаюсь донести, что это не верно.
S>Конечно вы...

Нет вы. Перечитайте тему. Это ваши слова, что С++ это нишевый язык с очень узкой нишей. Я показываю, что вы неправы, предоставляя логические выводы, показывая кучу исключений, давая цитаты автора языка.

S>Простите, вы это сейчас серьезно?

Что вас смущает? Принципиальная возможность использовать GC в плюсах? Наличие различных реализаций GC для плюсов? Существование книг с подробной теорией и реализацией GC на плюсах?

S>Вы знаете, что в некоторых прикладных нишах использование STL (т.е. стандартной библиотеки C++) находится под запретом (либо целиком, либо частично)?

Более того, работал под embeded. Но что вы хотели сказать данной фразой? Что создание STL — это катастрофическая ошибка?

P>>Как это исправить? Ну для начала хотя бы перенять опыт других языков.
S>Каких?
Мы ходим по кругу, перечитайте тему.

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

V>У остальных уже есть абстракция ostream и фреймворк фильтрации сверху в бусте.

Ну то есть ничего нет. Всё надо писать.

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

Ну под 90% задач абсолютно подходят — значит идеальные кандидаты на включении в стандартную поставку.

V>Велосипедить можно по-разному...

Главный вопрос: и что? Как наличие стадартных средств может помешать тому, кто всеми силами хочет велосипедить? Вообще не вижу проблемы.

V>А в языках с хорошей выразительностью велосипедостроительство — это основной вид деятельности.

Для хобби — это так. Но бизнесс с тобой не согласен. Потому и слили плюсы большинство своих областей применения.

V>Т.е. не обязательно выпускать готовые велосипеды, бо всем ты не угодишь.

оно и не нужно

V>Да чего уж там. Ты не угодишь даже половине. ))

да ладно, как минимум 90% будет довольно

V>Но можно выпускать отдельно номенклатуру колёс, отдельно цепей, рам и т.д.

это очень заманчивая мысль, но в данный момент это не сделать просто физически, должен быть хоть какой-то фундамент. Пока же ни колёс, ни цепей, ни рам. Всё, что есть — набор сторонних велосипедов.

V>Именно поэтому развитый базис, позволяющий комбинировать готовые "кирпичики", намного ценнее некоторого конкретного решения, которое практически невозможно на эти кирпичики разобрать.

Браво! Вот только где они, кирпичики? То, что предлагаются стандартом — кот наплакал.

V>Тенденции рынка чистой заказухи все последние 15 лет хреновые

Из того, что я вижу по заказам — это как раз рынок коробочных решений почти умер. А вот заказы от бизнеса всё ещё набирают обороты. Куча компаний только на этом поле и пасётся, не выпуская вообще никаких своих коробочных продуктов.

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

V>Т.е. твой моск, смотрю, пока еще изо всех сил борется с тем фактом, что огромный пласт задач (даже сугубо прикладных) сегодня на С++ решается заметно быстрее и проще, чем даже на C# 7.0.

Я был бы очень рад, если бы это видел на самом деле. Пока что дело обстоит так, что плюсы присутствуют только в узкой нише embeded и ресурсо-критичных задач.
Всё остальное делается заметно геморнее и дольше, чем на остальных языках. Видимо это тщательно скрывается от общественности.

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

V>Разве модули работы со звуком идут как стандарт языка? Или это всё-таки некие либы сверху?

Это идёт либо в стандартных средствах: либо в библиотеке, либо в поставляемом окружении.
Для плюсов — любой из этих вариантов сделал бы счастливыми невероятное количество людей.

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

_>Смотря что называть основными программными примитивами. Работу с аудио, видео, и т.п. я бы вряд ли таким назвал.

А что требуется для большинства задач? Проиграть аудио/видео, замедлить/ускорить/остановить. Это покроет большинство потребностей. Это не реализуемо в принципе на С++? Это невероятно сложно сделать?

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

_>Ну вот стандартная поставка — это как раз сомнительная идея.

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

_>Поэтому не напрягаясь могут строить разные типы домов, из разных типов кирпичей.)

Так а где ж кирпичи-то? Они не предусмотрены производителем.

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

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

S>>Ну тогда перечитайте, а то есть ощущение, что вы чего-то не поняли. Не мог Страуструп в "Дизайне и эволюции" писать одно, а в "Язык программирования C++" -- другое.

P>Взял книгу, открыл, читаю. Вижу:

Очевидно, не видите. И даже понятно почему.

P>И ничего, что это язык "для скорости" и вообще что это какой-то "нишевый" язык.
P>Так что это как раз вы суть С++ и не поняли. Теперь ваша очередь взять и перечитать.

Да уж. Ну держите, из "Дизайн и эволюция языка C++":

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

* хороший инструмент должен предоставлять средства организации программ, подобные имеющимся в Simula: классы, форму их иерархии, поддержку параллельности и сильный (т.е. статический) контроль типов, основанный на классах. Эти критерии представлялись мне тогда (да и теперь) существенными для поддержки процесса проектирования, а не для реализации программы;

* необходимо, чтобы он генерировал программы, работающие так же быстро, как написанные на BCPL, и обладал способностью BCPL объединять раздельно скомпилированные модули в единую программу. Должно быть простое соглашение о связях, чтобы удалось объединять модули, написанные на разных языках, таких как C, Algol68, Fortran, BCPL, ассемблер и т.д. Иначе программист будет вынужден бороться с ограничениями, присущими какому-то одному языку;

* инструмент должен обеспечивать переносимую реализацию. Мой опыт показал, что "правильная" реализация, остро необходимая мне сейчас, будет готова "не раньше следующего года", да и то на компьютере, которого у меня нет. Отсюда следует, что должно быть несколько источников реализации инструмента (никакой монополист не сможет поддерживать всех пользователей "редких" машин, а так же бедных студентов). Не должно быть так же сложной системы поддержки времени исполнения, которую трудно переносить, и допустима лишь очень ограниченная зависимость инструмента от операционной системы.

Обратите пристальное внимание на второй принцип, и ту часть третьего принципа, которая касается отсутствия сложной системы поддержки времени исполнения (отдельный привет безопасным языкам на базе JVM и .NET). Не говоря уже про явно обозначенную нишу языка (и если вы не верите, что "операционные системы" -- это ниша, для которой критична скорость и ресурсопотребление, то вам нужно a) лечиться и b) идти учиться).

Ну и еще оттуда же, про важность скорости генерируемого кода:

...Я считал принципиальным такой аспект: улучшение структуры не может достигаться за счет падения производительности по сравнению с С. Язык C with Classes не должен был уступать C во времени исполнения, компактности кода и данных. Однажды кто-то продемонстрировал систематическое трехпроцентное падение производительности новой версии по сравнению с С, вызванное наличием временных переменных, которые препроцессор C with Classes использовал в механизме возврата из функций. Недочет был признан неприемлемым и причину быстро устранили...

Другой важной целью работы было стремление избежать ограничений на области использования C with Classes. Идеал (кстати, достигнутый) — C with Classes может применяться везде, где использовался C. Отсюда следовало, что новая версия ни в коем случае не должна была уступать C в эффективности, но эта эффективность не могла достигаться за счет отказа от некоторых, пусть даже уродливых особенностей C. Это соображение (если хотите, принцип) приходилось снова и снова повторять тем людям (как правило, не работавшим постоянно с C with Classes), которые хотели сделать версию безопаснее, введя статический контроль типов а-ля Pascal. Альтернативу такой "безопасности" — вставку проверок в исполняемый код — решили реализовать в отладочных средах. В самом языке нельзя было организовать таких проверок, ибо тогда он безнадежно проиграл бы по скорости и расходу памяти...

И, кстати, говоря, ничего из этого не противоречит вашим цитатам, в частности:

— предисловие автора в к третьему русскому изданию — "Целью этих усилий было описать язык и библиотеку, которые будут исправно служить всем пользователям языка, не предоставляя каких-либо преимуществ одной группе пользователей, компании или стране перед остальными."

Что неудивительно, т.к. речь идет о совершенно разных вещах, а именно: язык C++ предназначен для задач, в которых важна скорость и ресурсоемкость, поэтому он не должен отставать от C в производительности. Но для тех пользователей, которым нужен C++, не должно быть ограничений по применению языка.

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

Вы не понимаете. С++ изначально создавался только под те ниши, для которых скорость и ресурсопотребление критичны. Но из-за того, что в промежутке между 1985-1995 мощность компьютеров была вообще никакая, скорость и ресурсоемкость была критична практически везде. Потому-то C++ и пихали куда не попадя. Но потом RAM и CPU стало хватать даже для софта, написанного на Ruby, так что надобность в C++ постепенно пришла в норму и C++ просто-напросто вернулся туда, где и должен был быть изначально.

P>Нет вы. Перечитайте тему. Это ваши слова, что С++ это нишевый язык с очень узкой нишей. Я показываю, что вы неправы, предоставляя логические выводы, показывая кучу исключений, давая цитаты автора языка.

Во-первых, вы ничего не показываете, кроме своих заблуждений. Во-вторых, вот ваши слова:

Если бы он создавался для скорости — то как минимум по умолчанию копирования небыло, не было бы и виртуальных функций, исключений, RTTI.
С++ позиционировался как язык общего назначения. Повторюсь, Старутруп сам пишет об этом в предисловии.

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

S>>Простите, вы это сейчас серьезно?

P>Что вас смущает?

Ваша способность вести осмысленный диалог, в частности.

P>Принципиальная возможность использовать GC в плюсах? Наличие различных реализаций GC для плюсов? Существование книг с подробной теорией и реализацией GC на плюсах?

Применимость всего этого в широкой практике. А не в отдельных, в основном, исследовательских, задачах.

S>>Вы знаете, что в некоторых прикладных нишах использование STL (т.е. стандартной библиотеки C++) находится под запретом (либо целиком, либо частично)?

P>Более того, работал под embeded. Но что вы хотели сказать данной фразой? Что создание STL — это катастрофическая ошибка?

То, что вы противоречите сами себе. Ибо:

Киллер-фича — это как раз стандартные библиотеки и инфраструктура.

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

быстро и легко набросать приложение из "стандартных кирпичиков"

P>>>Как это исправить? Ну для начала хотя бы перенять опыт других языков.
S>>Каких?
P>Мы ходим по кругу, перечитайте тему.

Если вы про вот этот феерический пассаж:

Есть у всех в кого не плюнь: Delphi, C#, Python, Java и т.д. В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.

то простите, по этому поводу все сказано. И если вы подразумеваете, что C++ должен подражать в плане библиотек C#, Python, Java и D, то разговаривать с вами просто не о чем.

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

V>>Разве модули работы со звуком идут как стандарт языка? Или это всё-таки некие либы сверху?
P>Это идёт либо в стандартных средствах: либо в библиотеке, либо в поставляемом окружении.
P>Для плюсов — любой из этих вариантов сделал бы счастливыми невероятное количество людей.

Для плюсов так и есть.
Как грится, откройте уже документацию.

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

V>>Т.е. твой моск, смотрю, пока еще изо всех сил борется с тем фактом, что огромный пласт задач (даже сугубо прикладных) сегодня на С++ решается заметно быстрее и проще, чем даже на C# 7.0.
P>Я был бы очень рад, если бы это видел на самом деле. Пока что дело обстоит так, что плюсы присутствуют только в узкой нише embeded и ресурсо-критичных задач.

Плюсы присутствуют вообще везде.
99.9% программ, которыми ты регулярно пользуешься — они на плюсах писаны.
И в последние годы скорость написания таких программ резко возросла.


P>Всё остальное делается заметно геморнее и дольше, чем на остальных языках. Видимо это тщательно скрывается от общественности.

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

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

V>>У остальных уже есть абстракция ostream и фреймворк фильтрации сверху в бусте.
P>Ну то есть ничего нет. Всё надо писать.

Или взять любую готовую.
log4j тоже не идёт в поставке Джавы, но является самой используемой либой для логирования на этой платформе.
Я проблемы не вижу, кароч.


V>>Всё прибито гвоздями друг к другу на основе 3-4-х основных интерфейсов. Такие либы сделаны по принципу аналогичных либ из джавы и дотнета и выглядят, мягко говоря, идиотизмом. Ну и эффективность соответствующая.
P>Ну под 90% задач абсолютно подходят — значит идеальные кандидаты на включении в стандартную поставку.

По указанным мною причинам — не идеальны.
А значит, достойны лишь существовать в виде сторонних библиотек.
Например, Boost.Log пока не готов для включения в стандарт.
Тем не менее, готов для использования нетребовательными разработчиками, вроде тебя.
Опять проблемы не вижу.


V>>Велосипедить можно по-разному...
P>Главный вопрос: и что? Как наличие стадартных средств может помешать тому, кто всеми силами хочет велосипедить? Вообще не вижу проблемы.

Ты не ответил на главный вопрос — зачем?
Ты в любом случае будешь пользоваться бустом, если пишешь под С++.
Другого сценария сегодня нет.


V>>А в языках с хорошей выразительностью велосипедостроительство — это основной вид деятельности.
P>Для хобби — это так. Но бизнесс с тобой не согласен.

Бизнес со мной согласен и поэтому пилит коробочное ПО на плюсах.


P>Потому и слили плюсы большинство своих областей применения.

Угу. Слили везде, кроме веба. На котором их и не было никогда. ))

В общем. В реальности ситуация обстоит наоборот. С++ потеснил в клиентской разработке огромный зоопарк технологий, который наблюдался еще в первой половине 90-х. Во второй половине 90-х и в начале 2000-х на клиенте пытались выстрелить джава и дотнет, но так и не выстрелили.

Сегодня С++ является де-факто монополистом на клиенте. Все остальные сдулись.
На серверных технологиях на связке С/С++ писана ВООБЩЕ ВСЯ инфраструктура, и только самый-самый высокоуровневый клей — это PHP/Java/.Net.

Поэтому, все утверждения о том, что плюсы слили — смешны.
Ты запускаешь наглухо плюсовую Ось, пишешь из плюсового браузера, случаешь музычку или смотришь видео через плюсовый плеер, играешь в игрухи, которые 100%-но писаны на плюсовых движках и т.д. до бесконечности. Других технологий для столь же ПОПУЛЯРНЫХ и МАССОВЫХ программ де-факто нет. Ну или напомни, а то я давно о таких не слышал. ))


V>>Т.е. не обязательно выпускать готовые велосипеды, бо всем ты не угодишь.
P>оно и не нужно

Верно. Не нужно. Стандарт языка — это стандарт языка. А библиотека — это библиотека.


V>>Да чего уж там. Ты не угодишь даже половине.
P>да ладно, как минимум 90% будет довольно

Будет меньше половины.
Иначе альтернативные логгеры давно бы умерли, ведь есть бустовский.

Просто пример. Реализация shared_ptr в Бусте хороша, поэтому альтернативные реализации умерли, а эта пошла в стандарт.
С библиотекой логгирования этого пока не произошло и это слишком очевидный индикатор. Игнорировать такой индикатор — напрашиваться на остракизм.


V>>Но можно выпускать отдельно номенклатуру колёс, отдельно цепей, рам и т.д.
P>это очень заманчивая мысль, но в данный момент это не сделать просто физически

Именно так реализован логгер в Бусте, если что.
Поэтому, народ часто делает СВОЙ логгер из запчастей бустовского.


P>должен быть хоть какой-то фундамент.

Нахрена заводу по производству оконных рам знать, какой будет фундамент в будущем доме?
Это задача инженера конкретного проекта — произвести расчёты и подобрать соотв. технологию реализации фундамента.


P>Пока же ни колёс, ни цепей, ни рам. Всё, что есть — набор сторонних велосипедов.

Ложь.


V>>Именно поэтому развитый базис, позволяющий комбинировать готовые "кирпичики", намного ценнее некоторого конкретного решения, которое практически невозможно на эти кирпичики разобрать.
P>Браво! Вот только где они, кирпичики? То, что предлагаются стандартом — кот наплакал.

Похоже, я начинаю догадываться, что происходит.
Ты забыл значение слова "стандарт". ))
Стандарт — это как ГОСТ.
Он определяет самые общие правила.
Но он не диктует, каким должен быть твой дом и уж тем более не даёт тебе готовых элементов дома.
Он лишь определяет некие нормы и правила.

А ты хочешь от "стандарта" странного.


V>>Тенденции рынка чистой заказухи все последние 15 лет хреновые
P>Из того, что я вижу по заказам — это как раз рынок коробочных решений почти умер.

Статистику тебе дали — ты её игноришь по принципу "ничего не хочу знать".


P>А вот заказы от бизнеса всё ещё набирают обороты.

Согласно сухой статистике — падают год от года.


P>Куча компаний только на этом поле и пасётся, не выпуская вообще никаких своих коробочных продуктов.

И эта куча довольно быстро сжимается в последние годы.

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

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

P>>Потому и слили плюсы большинство своих областей применения.

V>Угу. Слили везде, кроме веба. На котором их и не было никогда. ))

Если у тебя такая четкая позиция, то обьясни(не в конектсте спора), почему серверный софт повсеместно пишется на Java или .NET. Только из-за сборки мусора?

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

lpd>Если у тебя такая четкая позиция, то обьясни(не в конектсте спора), почему серверный софт повсеместно пишется на Java или .NET. Только из-за сборки мусора?

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

Дотнет и 1С писаны на плюсах, джава на С (по историческим причинам, скорее, бо её пилят с 91-го года).

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

P>А что требуется для большинства задач? Проиграть аудио/видео, замедлить/ускорить/остановить. Это покроет большинство потребностей. Это не реализуемо в принципе на С++?

Это ты действительно спрашиваешь, когда 99% подобных программ писаны на плюсах?


P>Это невероятно сложно сделать?

Раз на других языках такое не пишут, значит сложно.

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

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

lpd>>Если у тебя такая четкая позиция, то обьясни(не в конектсте спора), почему серверный софт повсеместно пишется на Java или .NET. Только из-за сборки мусора?

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

Когда я здесь ранее задавал этот вопрос, мне ответили про систему сборки и инфраструктуру(+сборку мусора). Не уверен, что это был точный ответ.
Однако, что ты подразумеваешь под трансформацией программы? Системы сборки или reflection?

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

_>>Ну вот стандартная поставка — это как раз сомнительная идея.
P>Чем? Пока что аргументов, кроме "оно не сможет решить мою узкоспециализированную задачу" и "это очень плохо", я больше не видел.

От тебя вообще никаких аргументов, кроме дайте мне кнопку "сделай мне заехорошо".
Или в литературном варианте "горшочек вари".

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


P>Так а где ж кирпичи-то? Они не предусмотрены производителем.

Производителем цемента?
Ты когда цемент покупаешь при строительстве дома, ругаешься с водителем миксера, что он тебе кирпичей к цементу не подвёз? ))

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

lpd>Когда я здесь ранее задавал этот вопрос, мне ответили про систему сборки и инфраструктуру(+сборку мусора). Не уверен, что это был точный ответ.
lpd>Однако, что ты подразумеваешь под трансформацией программы?

Постоянное изменение кода на всех уровнях, от общей архитектуры до конкретных бизнес-алгоритмов.


lpd>Системы сборки или reflection?

Если ты про сборку мусора — то да, она хороша при постоянной трансформации архитектуры, т.к. не надо фиксировать, кто кем владеет.

Reflection тоже позволяет автоматизировать часть ручных задач, требуемых ПОСЛЕ трансформации. Т.е., даже если Reflection автоматизирует ту часть трудоёмкости, которая при однократной реализации кажется смехотворной, в случае постоянного изменения кода этот инструмент уже начинает выглядеть натуральной киллер-фичей.

Хотя, тому же C# не хватает развитых ср-в compile-time рефлексии, в итоге ошибки в коде вокруг рефлексии надо отлавливать уже в runtime. (в последних стандартах чуть-чуть зашевелились в этом направлении)

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

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

_>>Смотря что называть основными программными примитивами. Работу с аудио, видео, и т.п. я бы вряд ли таким назвал.
P>А что требуется для большинства задач? Проиграть аудио/видео, замедлить/ускорить/остановить. Это покроет большинство потребностей. Это не реализуемо в принципе на С++? Это невероятно сложно сделать?

Вообще то это мягко говоря сложно, хотя бы потому что есть сотни разных нюансов реализации. Начнём с того, что указанный тобой процесс в реальности делится 3 отдельных процесса, для каждого из которых частенько используют отдельные библиотеки. А именно:

1. Парсинг форматов медиа-файлов. С одной стороны это задача достаточно тривиальная и однозначная, а с другой этих форматов такое огромное количество, что совершенно непонятно какие же всё же включать в стандарт. Тем более, что многие из них разрабатываются как отдельные библиотеки.
2. Декодирование сжатых потоов. Тут естественно тоже имеется огромное число кодеков, но это ещё цветочки, т.к. у каждого из них есть множество разных реализации: тупая, на ассемблере с simd, с ускорением на GPU, с ускорением на аппаратном декодере (типа Intel Quick Sync) и т.п. Причём естественно ещё не известно какое оборудование есть на компьютере пользователя.
3. Вывод декодированного потока на экран/колонки. Тут у нас имеется не меньший зоопарк API. Например если мы возьмём вопрос рендеринга видео под Винду, то как минимум сразу же автоматом идут DirextX, OpenGL, DirectShow, да и даже банальный GDI (не эффективный, но работающий везде). Но и это ещё не всё, перечисленные подходы тоже разделяются, т.к. в первых двух можно использовать различные шейдеры, а в DirectShow разные рендеры (VMR7, VMR9, EVR и т.д.).

И ты вот реально хочешь засунуть весь этот стек сложных технологий в стандартную библиотеку C++ с API вида playfile? )))

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