Здравствуйте, MTD, Вы писали:
MTD>Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal?
Спагетти и говнокод внутри?
MTD>А что же предложило С++ комьюнити в качестве альтернативы?
Не мумить себе мозги разбуханием стандартов путём добавления туда всего подряд.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Непонятно, почему наличие в бинарнике отдельной статической секции, в которую компилятор положит информацию об использованных в программе типах, убъет всю оптимизацию на корню. CC>Не это убивает производительность, а изменения в бинаре, которые позволят к любому из этих типов снаружи в любой момент доступаться.
Ну сама по себе рефлексия будет чего-то стоить. Но я не понимаю, почему остальной код, не использующий рефлексию, должен хоть что-то за это платить.
Pzz>> Собственно, даже секция такая есть, debug info называется, осталось договориться об общепринятом интерфейсе к ее содержимому. CC>Ты давно пробовал дебажить релизный бинарь с этими символами?
Ну вот например у gcc информация, необходимая для раскрутки стека в случае исключения дублирует часть информации, нужной отладчику. Соответственно, в бинарник она кладется в одном экземпляре, и отладчит и рантайм ее используют.
Не понимаю, почему с рефлексией так нельзя поступить.
Это место может и не называться debug info, чтобы нервных барышень не смущать. Я хочу сказать, что вся инфраструктура для его генерации давно имеется.
Похоже, что коммитет по стандартизации до сих пор делает вид, что C++ реализован, как когда-то было при царе Иване Грозном, в виде препроцессора к Си, и использует имеющуюся сишную инфраструктуру. Хотя это давно уже не так.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну сама по себе рефлексия будет чего-то стоить. Но я не понимаю, почему остальной код, не использующий рефлексию, должен хоть что-то за это платить.
Что такое "остальной код" в этом контексте?
Pzz>Ну вот например у gcc информация, необходимая для раскрутки стека в случае исключения дублирует часть информации, нужной отладчику. Соответственно, в бинарник она кладется в одном экземпляре, и отладчит и рантайм ее используют.
Как ты будешь отлавливать в каком месте что лежит по регистрам? А в случае оптимизации jump inside function минуя общую шапку?
Pzz>Похоже, что коммитет по стандартизации
... просто не хочет лезть в детали имплементации.
Потому что стандартизировать такие вещи крайне геморно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Ну сама по себе рефлексия будет чего-то стоить. Но я не понимаю, почему остальной код, не использующий рефлексию, должен хоть что-то за это платить. CC>Что такое "остальной код" в этом контексте?
Код (а не данные), который не использует рефлексию.
Pzz>>Ну вот например у gcc информация, необходимая для раскрутки стека в случае исключения дублирует часть информации, нужной отладчику. Соответственно, в бинарник она кладется в одном экземпляре, и отладчит и рантайм ее используют. CC>Как ты будешь отлавливать в каком месте что лежит по регистрам? А в случае оптимизации jump inside function минуя общую шапку?
Так же, как осуществляется доступ к членам структуры по указателям.
Pzz>>Похоже, что коммитет по стандартизации CC>... просто не хочет лезть в детали имплементации. CC>Потому что стандартизировать такие вещи крайне геморно.
Ну вообще-то, в коммитете сидят представители контор, которые делают основные компиляторы, и стандарт — это результат торга между ними. Детали имплементации эти люди, разумеется, хорошо знают.
Здравствуйте, Pzz, Вы писали:
Pzz>сидят представители контор, которые делают основные компиляторы, и стандарт — это результат торга между ними. Детали имплементации эти люди, разумеется, хорошо знают.
Я тут как раз с clang чуваками ругаюсь по поводу одного из их нововведений, которое заставляет компилятор втихаря(!) генерить не то, что написал программер а заведомо неверный код, который потом в рантайме у юзеров взрывается.
Они меня лечат что это правильно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Ну я вот такой "неопытный плюсовик" и плевать я хотел, что вы там на своих кошерных языках пилите, поплёвывая с высокой колокольни на нас, "болезных".
Мне тупо платят деньги за мою работу. А переписывать тонны легаси кода только, потому что "у кого-то уже всё круто работает стописят лет на языке XYZ" — мой работодатель не такой дурак.
Разумеется, в команде имеются гораздо более опытные плюсовики, с 10+ лет опыта работы в индустрии, я не один по кнопкам стучу.
Куда стандарту рулить — это определяют ТНК с прибылью в десятки миллиардов (на которые инженеры и работают), через своих представителей, а не только титулованные доктора от компьютер-недосайнс.
Не нравится Буст — не используй. Не нравится C++11/14/17 — не используй.
Просто надо понимать, как работают корпорации на частично монополизированном, но всё ещё супер-конкурентном рынке. Просто так выкидывать армии плюсовиков на улицу, нанимать жабистов-хаскеллистов, говоря заказчику "подождите, мы тут типа апгрейд делаем, приходите через полгодика" — так в крупных конторах не делается. Эксперименты можно только на пилотных проектах ставить, устоявшийся технологический процесс просто так никто в здравом уме не перетрахивает.
Здравствуйте, so5team, Вы писали:
V>>icu -> Boost.Locale S>Дык сам ICU же на C++ написан
Тем более, спасибо, я даже не интересовался этой либой, бо напрямую никогда её не использовал.
S>о чем речь вообще?
О юношеском нигилизме, т.е. о подзадержавшемся пебуртате, когда хочется прям "восстать" против устоявшегося мейнстрима.
В нашей реальности против С++.
Тогда сгоряча можно даже пытаться противопоставлять С и С++. ))
Здравствуйте, CreatorCray, Вы писали:
CC>Я тут как раз с clang чуваками ругаюсь по поводу одного из их нововведений, которое заставляет компилятор втихаря(!) генерить не то, что написал программер а заведомо неверный код, который потом в рантайме у юзеров взрывается. CC>Они меня лечат что это правильно.
У линуха есть три большие компоненты: gcc, ядро и libc. Периодически между ними возникает публичный срач на тему толкования стандартов. Поэтому твое сообщение меня совершенно не удивляет.
Здравствуйте, MTD, Вы писали:
V>>То вам подавай навороченный С++ MTD>Ты меня с кем-то путаешь. Я ценю простоту, удобство, надежность.
Ты высказываешься в той ветке, где С++ ругают за недостаточную навороченность.
MTD>Я их привел по одной причине — это индустриальный стандарт
Индустриальных стандартов много, как и комитетов по стандартизации.
Разумеется, С++ такой же индустриальный стандарт.
MTD>на С++ нет ничего подобного, что идет вразрез с твоими словами, что все либы есть на С++.
Де-факто есть, ссылки я тебе дал.
V>>не под все архитектуры процов существуют компиляторы с навороченного С++. MTD>Давай больше конкретики, а то опять начинается разговор про сферического коня в вакууме.
Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51
MTD>Кстати, отличный С++ фреймворк — Qt работает на самых разных железках, даже с древними компиляторами.
За что его и ругают, кстате.
Отличный пример, спасибо.
MTD>Обертки, обертки, обертки, причем местами делающие хуже и добавляющие своих глюков.
В отличие от оберток для других языков, С++ обертки бесплатны. Код С компилируется непосредственно.
Поэтому, не обертка, а импрувмент. ))
MTD>Где плюсовые проекты такой-же зрелости?
Во-первых, "такой же зрелости" — это спекуляции.
Язык С банально старше.
Во-вторых, примеров зрелых С++ проектов овердохрена.
Любые физические движки, любые комплексные аудио+2d+3d фреймворки, типа SDL. Или даже простейшая SFML.
Такие вещи, как KDE, v8, node.js, XUL и прочее — всё ведь на слуху и является сегодня мейнстримом.
Любой законченный, готовый к употреблению фреймворк сегодня плюсовый.
А исключения навроде GTK+ — именно что исключения, по состоянию на сегодня.
Но, опять же, проект GTK начал развиваться тогда, когда С++ был еще во младенчестве.
Т.е. возраст проектов играет не последнюю роль, ес-но.
MTD>Вот так и выходит, что на С++ мы только и заняты тем, что одно оборачиваем в другое.
Ну ты бы сначала вопросом поинтересовался бы, потом выводы делал.
В С++ оборачивается обычно ничтожная часть АПИ любой сишной библиотеки.
Вот только те объекты, которые отвечают за ресурсы, те и оборачиваются, потому что ради RAII.
Но гораздо больше объектов никакого оборачивания не требуют.
Здравствуйте, MTD, Вы писали: V>>Только все-равно нелепость выходит. Неужели ты не в курсе про устоявшийся отродясь способ взаимодействия С/С++? V>>libcurl -> www.curlpp.org V>>icu -> Boost.Locale V>>zlib -> Boost iostream zlib filters V>>OpenGL, OpenAL, OpenES -> OpenGL++, OpenAL++, OpenES++ V>>ffmpeg -> ffmpeg DirectShow filter
MTD>Обертки, обертки, обертки, причем местами делающие хуже и добавляющие своих глюков. Где плюсовые проекты такой-же зрелости? Вот так и выходит, что на С++ мы только и заняты тем, что одно оборачиваем в другое.
А в других языках оно типа не через обёртки сделано, и каким-то магическим образом из сишечки в код на языке Х попадает?
Или нужно непременно, чтобы на плюсах сразу было, без сишечки, и начиная с самого аппаратного драйвера — иначе не по-пацански? Ну DirectX на плюсах изначально был. Он хоть и не промышленный стандарт, как OpenGL, но для геймдева в мире Wintel, на равных шёл с OpenGL, тем более что DirectX готовый для игродела фреймворк, в отличие от OpenGL. Помню, в конце 90х игры иногда даже выходили с реализацией как на OpenGL, так и на Direct3D.
А проекты "сравнимой зрелости" есть, просто они не "чисто айтишные", а нишевые и проприетарные, поэтому тот, кто в этих нишах не работал, просто не мог о них ничего слышать.
То, во что вкладывались деньги в самом начале 2000-х, и что работает до сих пор на плюсах, пилится дальше на плюсах, пока не переведутся плюсовики по приемлемой цене.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, MTD, Вы писали:
MTD>>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
SVZ>А альтернативы всё равно нет. SVZ>Можно было бы развивать D, но с ним всё как-то вяло. Может уже издох?
Нет, живой. Более того, корифеи C++ тоже на него переключились.
Здравствуйте, vdimas, Вы писали:
V>Такая стандартизация для устоявшихся и востребованных вещей есть. V>Всё остальное — cutting-edge. V>Т.е. не включается в стандарт по причине своей активной разработки в настоящее время.
Ты в самом деле пытаешься доказать, что чёрное — это белое?))) Ну удачи.
Открываем стандарт, смотрим что стандартизовано. Итого есть:
1) вектор
2) парочка алгоритмов
3) не эффективное io
4) так, по мелочи
5) ой, чуть не забыл — комплексные числа — это самое важное!111
Как бы и всё. Если для тебя то, из чего состоит 99% приложений — cutting-edge, то у меня для тебя плохие новости.
V>Есть прикольное фундаментальное противоречие для технологий навроде аудио-видео...
Ага, то есть в остальных языках есть стандартные средства для работы со звуком-видео без фундаментальных противоречий, а С++ в этом плане импотент. Всё верно? Так и записывать?
V>Откуда я заключаю, что ты в профессии относительно недавно...
До NuGet в дотнете нужно было предпринимать столько же телодвижений...
Да судя, что у тебя ещё не прошёл период снобизма — я явно гораздо дольше тебя в разработке.
Причём тут пакетные менеджеры? Тебе говорят, что надо делать кучу телодвижений для вещей, для которых в других языках вообще ничего делать не надо. Почувствуй разницу.
(А то, что ты открыл для себя пакетные менеджеры — это конечно похвально, но они не походят для текущего состояния плюсов. Смотри, как он должен выглядеть для плюсов — vcpkg. Бери и пользуйся, учу бесплатно. Там ещё много чего надо доделать, это наколенная версия — но идея верная, в отличии от остальных пакетных менеджеров.
Но всё это костыли. Надо менять дизайн языка, нужны модули, надо двигаться в сторону компонентной модели. Надо много чего стандартизировать.)
Здравствуйте, vdimas, Вы писали:
V>С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны?
Оу, мдааа. Ещё раз посмотри .Net. Вот нужно по тому же сценарию. Развернуть интерфейс либ из положения "раком" в удобное для использования. Адаптировать их к совместному использованию:
1) однообразный подход к проектированию интерфейса
2) отсутствие бесконечного количества промежуточных действий по конвертированию данных из одного формата в другой, чтобы использовать их в другой либе.
Был бы у тебя опыт прикладной разработки, мне бы не приходилось растолковывать очевидные вещи.
V>Смишно. До того, как объекты из Boost.Thread попали в стандарт, они пережили 4 (ЧЕТЫРЕ, Карл!!!) серьёзные смены архитектуры. И вот когда процесс смен архитектур превратился в затухающий, тогда и добавили наработки в стандарт.
Действительно смишно. Приняли 1 в 1 бустовские, заменяешь "boost" на "std" — и вот, готово. И всё равно их надо переделывать.
А требовалось:
1) Сделать удобный интерфейс
2) Сделать биндинги для API
Раньше, когда каждый колхозил свои потоки, это делалось одним человеком за вечер.
Здравствуйте, so5team, Вы писали:
S>Стандартные на уровне ISO-стандарта? Это в каких языках? Можно примеры?
Не все заморачиваются с ISO. Но так есть у всех. Чисто для общего образования почитай про любой современный язык — ты очень удивишься, что там есть и насколько плюсы отстали.
Есть у всех в кого не плюнь: Delphi, C#, Python, Java и т.д. В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
Здравствуйте, push, Вы писали:
S>>Стандартные на уровне ISO-стандарта? Это в каких языках? Можно примеры?
P>В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
Здравствуйте, push, Вы писали:
V>>С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны? P>Оу, мдааа. Ещё раз посмотри .Net. Вот нужно по тому же сценарию. Развернуть интерфейс либ из положения "раком" в удобное для использования.
Не вижу никакого удобства. Вижу прибитие гвоздями к интерфейсам базовой библиотеки. Вижу такое положение дел, что чуть что — слишком много надо делать ручками в дотнете, в отличие от плюсов. Причём, реально много кода получается даже по мелочам. Любая задача в дотнете, для которой нет решения в стандартной либе, требует в несколько раз больше объема исходников, чем в плюсах.
P>1) однообразный подход к проектированию интерфейса
На плюсах уже давно однообразный подход. Просто ты его не понимаешь.
P>2) отсутствие бесконечного количества промежуточных действий по конвертированию данных из одного формата в другой, чтобы использовать их в другой либе.
В какой другой?
Если у тебя файл mp3, а тебе надо позиционировать 3D-звук некоей либой. Разумеется, тебе надо перевести mp3 в сырое представление.
В общем, если ты про данные, то формат данных определяется самими данными, а не АПИ некоей библиотеки. А если ты про оперируемые библиотекой типы, то последние лет 15 библиотеки С++ обычно проектируют так, что они ожидают на входе внешних АПИ не конкретные типы, а концепты. К тому же, легко настраиваемы через typedef, policy и traits. Дотнету такая гибкость и не снилась, разумеется.
P>Был бы у тебя опыт прикладной разработки, мне бы не приходилось растолковывать очевидные вещи.
Ты и не можешь растолковать, бо у тебя пока вообще никакого опыта нет и прилично ты с дотнетом еще не трахался. Если бы ты работал с ним всерьёз, ты бы не писал всей этой чудовищной чуши, сорри.
V>>Смишно. До того, как объекты из Boost.Thread попали в стандарт, они пережили 4 (ЧЕТЫРЕ, Карл!!!) серьёзные смены архитектуры. И вот когда процесс смен архитектур превратился в затухающий, тогда и добавили наработки в стандарт. P>Действительно смишно. Приняли 1 в 1 бустовские
Буст затем и был создан, чтобы обкатывать решения.
Но 4 варианта — это разве не показатель? Похоже, ты не сосредоточился на логике аргументации оппонента. ))
А тот факт, что дотнет постоянно переписывают, потому что то это забудут, то то. То тут АПИ кривое, то там, ы?
То вообще непонятно как обеспечивать совместимость и какой выбрать таржет, если у нас идут подряд сразу 4 плохосовместимые дотнетные версии 4.5.1, 4.5.2, 4.5.3, 4.6?
Так какую из версий АПИ дотнетных либ из перечисленных вкулючать в стандарт, ы?
А какой таржет ты выберешь прямо сейчас?
Вопрос не праздный, а ставящий разработчиков в тупик, и это еще мягко говоря.
В нейтиве проще, там в конечном продукте зависимостей минимум или отсутствуют.
P>А требовалось: P>1) Сделать удобный интерфейс
АПИ в плюсах на многие порядки удобнее дотнетного. Дотнетные АПИ, к большому сожалению, диктуют вполне определённый стиль построения графа объектов в памяти и этот стиль на сегодня является самым неэффективным из всех возможных. В плюсах же у тебя есть выбор.
P>2) Сделать биндинги для API
Это вам надо сделать биндинги, а у нас всё напрямую работает. ))
P>Раньше, когда каждый колхозил свои потоки, это делалось одним человеком за вечер.
Потоки даёт не колхоз, а нижлежащая ОСь
==============
Мде. Страшно далеки они от народа. (С)
Здравствуйте, push, Вы писали: P>Ты в самом деле пытаешься доказать, что чёрное — это белое?))) Ну удачи. P>Открываем стандарт, смотрим что стандартизовано. Итого есть: P>1) вектор P>2) парочка алгоритмов P>3) не эффективное io P>4) так, по мелочи
В дотнетном стандарте CLI тоже был примерно такой же списочек.
Вот уж не ожидал от тебя, что ты будешь путать стандарты с идущими в поставке либами.
MS в поставке даёт довольно-таки внушительный SDK, на котором можно сбацать ПРОИЗВОЛЬНЫЕ приложухи под последние Видны. Причём, такие, которые дотнету и не снились, разумеется.
P>Как бы и всё. Если для тебя то, из чего состоит 99% приложений — cutting-edge, то у меня для тебя плохие новости.
Это у меня для тебя плохие новости — ты умудрился заблудиться в 3-х соснах. ))
V>>Есть прикольное фундаментальное противоречие для технологий навроде аудио-видео... P>Ага, то есть в остальных языках есть стандартные средства для работы со звуком-видео
Нету. Есть только некое жалкое подобие, крайне бедненькое и кривенькое, через которое вообще НИЧЕГО нельзя сделать, ну разве что тупо "бибикнуть" звуковым файлом, да и то, из очень узкого списка его поддерживаемых форматов.
В стандарт С++ такой бред тащить не стоит, разумеется.
С другой стороны, именно в С/С++ живут все самые навороченные современные аудио-фреймворки.
Вот уж точно, ты в пылу спора побежал называть черное белым и наоборот.
Де-факто аудио мейнстрим на сегодня — это DirectShow (угу, там не только видео), VST и AU (под маком).
Это всё компонентные плюсовые технологии.
А на низком уровне для обработки аудио требуется:
— матричные библиотеки
— свертки/FFT/обратные FFT
— забудь про сказанное из предыдущего пункта, на современных файлах импульсной характеристики в реалтайме через FFT не справляется даже мой навороченный комп. Поищи по проблематике "real-time convolution long impulse responses". Требуются более хитрые алгоритмы. Люди их разрабатывают и продают за деньги в виде аудиоплагинов или музыкального софта. Это всё самый что ни на есть cutting eddge, всегда был и будет. А ты хочешь всё это бесплатно в стандарт? Ты хочешь остановить прогресс, я правильно тебя понял? ))
P>без фундаментальных противоречий, а С++ в этом плане импотент. Всё верно? Так и записывать?
Про себя так запиши. Для С++ обязательно идут SDK под платформу, дающие к ней полный доступ. А вот у тебя такого нет, верно? В этом плане ты полный импотент, бо не в состоянии воспользоваться возможностями комьютера.
V>>Откуда я заключаю, что ты в профессии относительно недавно... P>До NuGet в дотнете нужно было предпринимать столько же телодвижений... P>Да судя, что у тебя ещё не прошёл период снобизма — я явно гораздо дольше тебя в разработке.
Нет никакого снобизма, есть ржака не самого высокого полёта. Потому что не по причине чьего-то остроумия, а из-за плохо контролируемой клоунады. Наверно ты именно с этой целью являешься тут полным анонимом, верно? Т.е. чтобы нести вот эту всю херню и совершенно не париться.
Понимаю, очень удобно, нигде не жмёт.
Здравствуйте, mrTwister, Вы писали:
T>Зачем говорить на русском, если можно придумывать свои собственные слова!
Так и придумывают. Целый воз с запада притащили. Кодеры, Менеджеры, Дизайнеры, Девопсы, Тестеры, Имиджмейкеры, Продюсеры, Продакт Плейсмент, Фичи, Баги, Дальше Продолжать?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
