LINUX.ORG.RU
ФорумTalks

[размышления]Так ли убог C++ как его малюют?

 


0

4

Стандартный набор аргументов хаяльщиков C++ следующий:

небезопасный, нет сборщика мусора; можно попортить память и сидеть много лет под дебаггером.

В любых более-менее серьезном проекте, не важно какой язык Java/C++/Lisp/whatever, пишут документацию и тесты (лисперы ведь пишут тесты, правда?). Так что у ошибок вида delete NULL и пр. нет шансов. А если какой-то тест падает - то тем проще найти и исправить: какая-нибудь JAVA просто многозначительно промолчит и в релиз войдет бага.

шаблоны == синтаксический сахар, ООП сложен и для гиков.

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

Мое ИМХО: ругают C++ исключительно ниасиляторы, продвигая вперед тем самым маркетинговые машины всяких Java c .NET-ами. А создание действительно качественного софта, будь то C++/Java/.NET, соизмеримы как по деньгам, так и по срокам. Другое дело что ынтерпрайз порой клал на качество... среднее и низкое качество на Java/.NET наверное выходит дешевле.

Ы?


Ответ на: комментарий от Divius

Там лучше asm, инфа 100%. Очен ьудачное решение для тех, кто не может определить, когда нужны скриптовые языки, а когда компилируемые.

На ARM Вы тоже asm собрались переносить?

maxkit
()
Ответ на: комментарий от slackwarrior

> Тебя послушать - у программистов С++ ноги от постоянных выстрелов заканчиваются, а потом пенсия по инвалидности, ага.
Старые программисты на С++ бывают двух видов. Те, кто без ног - и те, кто научился стрелять в нужном направлении до того, как ноги кончились.

svu ★★★★★
()
Ответ на: комментарий от maxkit

А что? Если упарываться - то по полной. Нормальные-то люди для таких задач скриптовые языки используют...

Divius ★★
()
Ответ на: комментарий от Divius

А что? Если упарываться - то по полной. Нормальные-то люди для таких задач скриптовые языки используют...

Толсто. Если Вы пишете процедуру backup-а, типа, сделать дамп базы, куда-то её залить, и т.д. - тут понятно, что написать её на sh - и дело с концом, потому что на производительности это не скажется вообще никак. Но вот в той же системе управления пакетами Gentoo - уже несколько заметно. Я понимаю, что такое скорость разработки, понимаю, что не надо компилировать. Но всё-таки иногда целесообразно, чтобы разработчик затратил вдвое больше времени, но при этом пользователи экономили человеко-часы.

maxkit
()
Ответ на: комментарий от maxkit

Но вот в той же системе управления пакетами Gentoo - уже несколько заметно.

Туфта. Это как миф про то, что перекомпиляция под свой процессор сильно увеличит скорость работы. Я это всё уже проходил.

Но всё-таки иногда целесообразно, чтобы разработчик затратил вдвое больше времени, но при этом пользователи экономили человеко-часы

Это свободное ПО, здесь разработчик = пользователь. Для них эти мнимые 100-200 человекомиллисекунд не стоят геморроя. Вот винда - та чисто на плюсах (по крайней мере была до дотнета), что это ей помогает не тормозить?

Divius ★★
()
Ответ на: Об утечках памяти от linuxfan

> В плюсах же единожды осилив RAII, просветленный спасается практически ото всех видов утечек любых ресурсов (в том числе и памяти).

Ога, то-то valgrind с memcheck'ом придумали. 8)))

И да, RAII от утечек спасает ещё меньше, чем GC (который тоже не панацея, что мы, кажется, и наблюдаем в указанном примере). Хотя скорее всего кто-то набыдлокодил и просто не подчищает данные в каком-нибудь контейнере - чем тебе RAII-то поможет? Сожрать память малость побыстрее? 8))

kemm
()
Ответ на: комментарий от Divius

Туфта. Это как миф про то, что перекомпиляция под свой процессор сильно увеличит скорость работы. Я это всё уже проходил.

Так смотря что компилировать и смотря как это реализовано в коде. В ffmpeg это ощутимо, например.

Это свободное ПО, здесь разработчик = пользователь. Для них эти мнимые 100-200 человекомиллисекунд не стоят геморроя. Вот винда - та чисто на плюсах (по крайней мере была до дотнета), что это ей помогает не тормозить?

Разработчик один, а пользователей много.

Кто Вам эту чепуху про «чисто на плюсах» сказал? К тому же, я тут уже неоднократно приводил пример. Запустите «7z b -mmt=1» в Windows и в Linux на одинаковом железе и удивитесь, когда обнаружится, что в Windows быстродействие чуть ли не на треть выше.

maxkit
()
Ответ на: комментарий от maxkit

Кто Вам эту чепуху про «чисто на плюсах» сказал?

Твоя версия? Расскажи.

Запустите «7z b -mmt=1» в Windows и в Linux на одинаковом железе и удивитесь, когда обнаружится, что в Windows быстродействие чуть ли не на треть выше.

А тебя не смущает, что ты сравниваешь быстродейтсвие двух разных программ (хоть и с одним названием)?

Divius ★★
()
Ответ на: комментарий от Divius

Твоя версия? Расскажи.

В ядре там почти чистый Си. Плюсы в драйверах - не запрещаются, но и не поощряются (информация с сайта MS по поводу написания драйверов). Код - очень разнообразный. Есть свидетельства даже кода на паскале. Хотя, в последнее время это, вроде бы, почистили уже. Плюсы были в основном в относительно старых системах типа XP. Если бы Linux по части интерфейса, окон и прочего (то, что на плюсах как раз) «тормозил» так же, как XP «тормозит» - уже бы коммунизм наступил, в хорошем смысле этого слова.

Новые системы Windows - интерфейс переписан в основном на .NET и прочих технологиях, типа WPF. Насколько они более медлительны можно увидеть даже невооружённым глазом, если отключить всякие aero-эффекты и просто сворачивать/разворачивать окна. То, что в XP происходит мгновенно, в Vista/7 «прорисовывается» медленнее, чем в Metacity без проприетарных драйверов.

А тебя не смущает, что ты сравниваешь быстродейтсвие двух разных программ (хоть и с одним названием)?

Нет, не смущает, потому что я качал исходники и компилировал лично. В первом случае, с помощью GCC, во втором - с помощью MSVC. Результат получился абсолютно таким же, как если ничего не компилировать, а просто скачать готовый бинарник для Windows и для Linux, что и не удивительно.

maxkit
()
Ответ на: комментарий от Waterlaz

> Паскаль? Паскаль от Си не так сильно и отличается. По крайней мере то, что из Паскаля сделал Борланд в свое время, Си, только в профиль.

Да я ж про стандарт, а не про извращения вокруг него.

alexmaru
()
Ответ на: комментарий от maxkit

> Нет, не смущает, потому что я качал исходники и компилировал лично. В первом случае, с помощью GCC, во втором - с помощью MSVC. Результат получился абсолютно таким же, как если ничего не компилировать, а просто скачать готовый бинарник для Windows и для Linux, что и не удивительно.

Да поди скомпилено неоптимально, какие флаги там и там?
Или тупо разный код используется для Windows/Linux версий с кучей ifdef.

yytreop
()
Ответ на: комментарий от yytreop

Да поди скомпилено неоптимально, какие флаги там и там?

Или тупо разный код используется для Windows/Linux версий с кучей ifdef.

Вот Вы думаете, что я о флагах ничего не знал, да? Флаги были очень разнообразные. Это уже не говоря о том, что если в MSVC начинать играться с оптимизациями - то там вообще разрыв сумасшедший получается. В Windows 32 в основном всё компилируется для i386, а в 64 - безо всяких SSE4 или аналогов -O3. Да, для меня это тоже было очень неприятной новостью, но зато это объясняет, почему один и тот же HD-контент без аппаратной акселерации (без vdpau и прочего) в Linux тормозит, а в Windows - «летает».

maxkit
()
Ответ на: комментарий от Gorthauer

Надо будет заняться этим, самому интересно.

maxkit
()
Ответ на: комментарий от maxkit

Я не говорю что ты ничего о флагах не знал, я говорю подобраны неоптимально:)
Я сам как-то случайно сравнил простенькую прожку для сортировки, результат примерно одинаковый получился, но только с -fomit-frame-pointer, без него линух сливал ~5%.

yytreop
()
Ответ на: комментарий от LORd

> Тесты, тесты, тесты... сразу видно что проект был без тестов ;)

Серебряная пуля ... я знал, я верил, что она существует.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

>> Тесты, тесты, тесты... сразу видно что проект был без тестов ;)

Серебряная пуля ... я знал, я верил, что она существует.

То, что ты будешь мыть руки, не означает, что ты проживешь вечно. Аналогия понятна?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Нет. Автор явно ждёт от тестов чего-то большего. На грани с магией.

ugoday ★★★★★
()
Ответ на: комментарий от kemm

>Ога, то-то valgrind с memcheck'ом придумали. 8)))

Значит хреново в некоторых проектах примитивы в RAII оборачивают. Упомянутый выше почтовый бакенд чудесным образом не течет, и работает месяцами без остановок. А все потому что нигде нет new, вокруг которого не стоял бы *_ptr.

linuxfan
()
Ответ на: комментарий от maxkit

>Так смотря что компилировать и смотря как это реализовано в коде. В ffmpeg это ощутимо, например.

В ffmpeg куча написанных вручную ассемблерных вставок, написанных вручную под конкретные типы процессоров (точнее говоря, под конкретные наборы инструкций). Автоматической векторизации в компиляторах нет, поэтому преимущества i686-кода перед кодом для core i7 в его исполнении ничтожно малы. А icc может отжечь, если в коде интенсивно используются операции с плавающей точкой.

linuxfan
()
Ответ на: комментарий от linuxfan

А все потому что нигде нет new, вокруг которого не стоял бы *_ptr.

Иногда в фабриках *_ptr таки не годится делать. Впрочем фабрику тогда стоит воспринимать как прокачаный оператор new. Да и вообще как можно в плюсах без RAII писать? Оо я в таком стиле писал даже тогда, когда слово такого не знал, мне казалось это очевидный подход.

Gorthauer ★★★★★
()
Ответ на: комментарий от maxkit

Подожди, что ты компилировал для двух платформ: программу, которая под юникс или которая под виндовс. Это 2 разные программы: 7zip и p7zip.

Если бы Linux по части интерфейса, окон и прочего (то, что на плюсах как раз) «тормозил» так же, как XP «тормозит»

Не приведи ктулху! Я не хочу и под линуксом часами свой проект компилять!!

Divius ★★
()
Ответ на: комментарий от Divius

Подожди, что ты компилировал для двух платформ: программу, которая под юникс или которая под виндовс. Это 2 разные программы: 7zip и p7zip.

p7zip, конечно. Как Вы представляете себе компиляцию GUI-шной windows программы под UNIX?

Не приведи ктулху! Я не хочу и под линуксом часами свой проект компилять!!

Это почему? MSVC компилирует не медленнее, чем GCC, на мой взгляд.

maxkit
()
Ответ на: комментарий от RedPossum

Качество формовки все еще заставляет пользоваться неким гибридом 3D-принтера и координатно-фрезерного станка. Так что поле для выстрелов в ногу и прочей оптимизации конечностей остается. Можно, например, совершить самоубийство с прецизионными допусками и посадками)

slackwarrior ★★★★★
()
Ответ на: комментарий от maxkit

p7zip, конечно.

Компиляторы какие? Флаги и прочая?

Как Вы представляете себе компиляцию GUI-шной windows программы под UNIX?

man libwine

Это почему? MSVC компилирует не медленнее, чем GCC, на мой взгляд.

Значительно медленнее, в разы. По крайней мере проект на Qt. Сравнивал GCC 4 и MSVS 2008 и 2010. Впрочем, тот же MinGW ещё в разы медленнее то же компиляет.

Divius ★★
()
Ответ на: комментарий от Divius

Компиляторы какие? Флаги и прочая?

MSVC и GCC. Флаги - пробовал разные. В лучшем для GCC случае получил его отставание на 17% в худшем - уже не помню точной цифры, но что-то около полутора раз.

man libwine

Я спросил «компиляцию», а не запуск. Это разные вещи.

Значительно медленнее, в разы. По крайней мере проект на Qt. Сравнивал GCC 4 и MSVS 2008 и 2010. Впрочем, тот же MinGW ещё в разы медленнее то же компиляет.

Это очень и очень странно. QT с его moc и в Linux/BSD крайне медленно компилируется. Какие-то 3 Мб исходников на c2d 1.8 могут компилироваться минут 30 в Gentoo. Замеров с Windows по компиляции QT специально не проводил, поэтому сейчас не готов назвать точных времён.

maxkit
()
Ответ на: комментарий от linuxfan

> Упомянутый выше почтовый бакенд чудесным образом не течет, и работает месяцами без остановок. А все потому что нигде нет new, вокруг которого не стоял бы *_ptr.

Мужыг, я тебе ещё раз говорю - от подобных ошибок RAII не спасает. Вообще никак. Перловый gc хоть и тупой подсчёт ссылок (т.е., по сути, все те же проблемы, что и с плюсовым RAII), но там хоть физически не может быть объекта вне сборщика, в отличие от отсутствия обёртки в смарт-пойнтеры. И да, я готов поспорить на ящик пива, что в той говноперловке логическая утечка, а не косяк gc (точнее, это совершенно точно не косяк gc, максимум набыдлокодили циклические ссылки и забыли разорвать).

Быдлокодеров надо тщательнЕе подбирать, аднака!

kemm
()
Ответ на: комментарий от maxkit

MSVC и GCC. Флаги - пробовал разные. В лучшем для GCC случае получил его отставание на 17% в худшем - уже не помню точной цифры, но что-то около полутора раз.

Верю. Но это не исключает нюансы реализации.

Я спросил «компиляцию», а не запуск. Это разные вещи.

Ещё раз говорю, man libwine и libwine-dev

Это очень и очень странно.

А ещё это очень утомительно!=(

Divius ★★
()
Ответ на: комментарий от Divius

man libwine и libwine-dev

Боюсь, что тогда придётся ещё и Visual Studio туда как-то ставить, потому что GUI-шный 7-zip ею компилируется.

maxkit
()
Ответ на: комментарий от tia

> Если задача выполняется 1 сек на цпп и 2 сек на пайтоне, то скорость выполнения не будет играть такой роли.

Если мобилка будет жить 8 часов при общении в асечке, написанной на цпп и 4 часа при общении в асечке, написанной на питоне, выбор пользователя будет однозначен :-)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Вот в точности то-же самое хотел написать, даже числа. Хайвмайнд.

legolegs ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.