LINUX.ORG.RU

10 причин почему программист на С++ может выбить много денег


24

10

Список в конце поста написан Лавсаном 2 года назад. (2011-03-23 19:56:00) (источник)
Надеюсь, автор не подаст жалобу в Роспатент за перепечатку :-)
Кстати, sudo cast lovesan.

Чтобы проверить актуальность вопроса, всю последнюю неделю я долго и нудно использовал этот список в дискуссиях. Чтобы разобрать отдельные пункты отдельно.

Временное резюме: С++ всё еще актуален по историческим причинам. Еще есть мобилки (sudo cast mono), гиперкластеры для шиндовс 3.11 (sudo cast vromanov) и базы данных. Т.к. он актуален, но не предназначен ни для чего (см. выводы в конце списка) новых специалистов по нему должно быть мало. Маленькая конкуренция на огромной области применения — огромное лавэ $$$. Вот это и есть истинная причина использовать кресты — возможность срубить €€€.

Честно говоря, «хитрый план» мне уже очень надоел, поэтому пора открыть карты.

Заодним, крестопоклонники смогут выйти на последний и решительный бой, т.к. сегодня пятница и вечером будет время пообщаться. Поклонникам мамкиного борща тоже наверняка есть что добавить, конструктивно и аргументированно.

Вот этот список:

  1. Вырвиглазный синтаксис и контекстно-зависимая грамматика
    • медленная компиляция
    • частые «internal error» в компиляторах
    • код плохо читается и его сложно поддерживать
    • разбор кода различными инструментами, вроде IDE, и его генерация - сильно затруднены
  2. ручное управление памятью
    • неудобства при работе с динамической памятью
    • утечки памяти
    • висячие ссылки
    • сегфолты
    • стандартные средства, как то malloc/new, работают медленно
    • фрагментация кучи
    • велосипедные аллокаторы на каждом шагу
      • которые далеко не факт что эффективнее malloc/new

    • велосипедные счетчики ссылок на каждом шагу, опять же
      • медленная работа
      • перерасход по памяти

    • отладка затруднена
    • написание GC, по факту, невозможно, отчасти из-за (5), (7) и (8)
  3. Никакого ABI
  4. Нестандартизированный и непредсказумый name mangling
  5. Дублирование функционала Си
    • сами фичи из Си никуда не деваются при этом
      • отчасти из-за того, что по функционалу превосходят аналоги из C++

    • запутывает новичков
    • malloc - new/new[], free - delete/delete[]
    • препроцессор - шаблоны
    • указатели - ссылки
      • ссылка не может быть NULL, что способствует появлению висячих ссылок и сегфолтов

    • структуры - классы
    • stdio - iostream
  6. Стандартная библиотека убога
    • Отсутствует даже такой функционал, как вменяемая работа со строками и многомерные массивы
      • Юникод?

  7. Слабая типизация
    • способствует ошибкам
    • затрудняет отладку
    • const не дает абсолютно никаких гарантий
    • при этом система типов невероятно переусложенена
      • в основном из-за пунктов (2), (5) и (9)
      • медленная компиляция
      • частые внутренние ошибки в компиляторах

  8. объектая система убога
    • практически никакой интроспекции
      • отладка затруднена
    • передача объектов по значению
      • понятие идентичности объекта теряет смысл
      • добавляет сложностей в управлении памятью
      • добавляет сложностей при отладке
      • используется часто, по причине (2)
        • перерасход по памяти
        • медленная работа

    • множественное наследование неудобно в использовании
      • проблема ромба по дефолту не разрешается никак

    • исключения в конструкторах гарантированно влекут утечку памяти
      • исключения в деструкторах тоже, и просто утечку - еще в лучшем случае
        • коды ошибок деструкторы и конструкторы возвращать не могут
          • ошибки в них не обработать никак
            • поэтому ими стараются не пользоваться
              • раздувание кода

    • деструктор можно вызывать до выхода из блока кода, или до delete
      • гарантированная утечка ресурсов/сегфлот
      • это не предотвратить никак, деструктор обязан быть public

    • одиночная диспетчеризация
      • виртуальные методы в конструкторах не работают
      • реализована убого
        • pure virtual function call
        • сложности в случае с множественным наследованием
        • деструкторы обязаны быть виртуальными
          • по дефолту - не виртуальные

        • никаких интерфейсов, только классы

    • порядок инициализации статических членов классов не определен
    • private, public и protected не дают никаких гарантий сокрытия данных
      • к инкапсуляции же не относятся совершенно никак

    • отсутствие «свойств»
      • вынуждает городить getter'ы и setter'ы
        • раздувание кода
        • размывание интерфейса класса

    • неявно генерирумые конструкторы, деструкторы и операторы присваивания
    • «friend» нарушают инкапсуляцию
  9. шаблоны
    • очень сильно замедляют компиляцию
    • раздувание кода
    • обфускация кода
    • результат раскрытия плохо предсказуем
    • сложности в отладке
      • километровые и плохо читаемые сообщения об ошибках при компиляции

    • нарушают инкапсуляцию
      • обязаны содержать реализацию в заголовочных файлах

    • позволяют генерировать некорректный код
  10. исключения
    • отсутствие finally/unwind-protect
      • заставляет городить классы ради одних деструкторов
        • раздувание кода
        • медленная компиляция
        • медленная работа

    • конфликтуют с другими возможностями языка
      • конструкторы/деструкторы
      • ручное управление памятью

    • работают медленно
    • малофункциональны (ср. CL condition system)

По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования. А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 - и для прикладного.

У C++ нет области применения.

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

еще раз - зачем это? Я вообще скорее сторонник во внешних интерфейсах статического фасада, чем каких-либо классов.

vromanov ★★★
()

Все твои аргументы перевешиваются одним аргументом любого крестовика «я научился жрать кактус и другого ничего не ел, не ем и не буду есть». Или вариация на тему «оно же греет мне сердце».

А так да, что б уже этот С++ сдох

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

А зачем? Вот нахрена?

SWT и Swing
1) из коробки выглядят как говно. Насчет SWT - вопросы, но Swing — точно.
2) даже если бы они выглядели нормально в одиночестве, они всё равно выглядят странно/ненативно относительно конкретной платформы. Даже полунативный SWT выглядит странно. KDE4 — это Qt. Заставлять Swing выглядеть как Qt — это какая-то дисциплина специальной олимпиады.

Что есть С++ или Perl приложения, которые используют Swing?

по описанным выше причинам — наверное, нет. Ну, лучшая бесплатная IDE для C++ почему-то написана на SWT :)

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

Ну, лучшая бесплатная IDE для C++ почему-то написана на SWT :)

Xcode, Visual Studio Express и QtCreator на SWT??!

wota ★★
()
Последнее исправление: wota (всего исправлений: 1)
Ответ на: комментарий от vertexua

Все твои аргументы перевешиваются одним аргументом любого крестовика «я научился жрать кактус и другого ничего не ел

о да, я помню как ты говорил про «прямую» Java, а потом слился, так что ты описал как раз себя

А так да, что б уже этот С++ сдох

LOL

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

О, жавосрач.

Кстати, за эти 8 страниц в битве поучаствовали уже почти все стороны, кроме адептов Agda, Coq и что там щаз популярно из тяжелых наркотиков. Где же они, ау. Интересно было бы послушать их мнение, что они видят в крестах сквозь призму своих странных инструментов.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от vertexua

А вот и дрочеры плюсов подтянулись.

да нет, давно уже хочу с них свалить, но пока не на что

Не сломай себе ничего в твоем процессе фанатического экстаза.

эмоции к ЯП (вспоминаем эпичное «что б уже этот С++ сдох») - это удел обезьянок и фанатиков, для меня ЯП это просто инструмент

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

И после этого ещё кто-то наезжает на лисперов.

есть маленькая разница - это надуманный пример для С#, да и синтаксис C# гораздо более разнообразен, а в лиспе весь код такой ;)

wota ★★
()

исповедь рукожопа

«Никакого ABI» «исключения в конструкторах гарантированно влекут утечку памяти» «ошибки в них не обработать никак»

вот ей богу, писание на жабе как-то искривляет мозги.

ckotinko ☆☆☆
()
Ответ на: комментарий от stevejobs

Стало жутко интересно, решил попробовать.

#include <iostream>

const int a = 3;

using namespace std;

int main(){
	cout << a;
	int *x = &a;
	*x = 4;
	cout << a;
	return 0;
}
Если руками не далать каст (int*), то компилятор выдаст ошибку «tmp.cpp:9:12: ошибка: некорректное преобразование из «const int*» в «int*» [-fpermissive]». Так что если ты руками кастуешь const int* в int*, то это твоя проблема, а не компилятора.

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

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

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

Крестовики, как правило, знают и используют еще кучу языков.

Так какая альтернатива крестам-то?

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

Например, в вашем примере шаблонных функций и функций по указателю, вы их тоже сравниваете некорректно. Ведь когда пишут на си, то говорят - мы жертвуем временем разработки ради производительности. В соответствии с этим посылом, пишите руками десять (100, 1000, или сколько там у вас) вариантов функций на с, для каждого возможного случая, и сравнивайте уже их с шаблоном на плюсах. Вы же, сами того не осознавая, говорите - «мы не будем жертвовать временем разработки», умышленно придумываете пример в котором на си просто невозможно руками написать все за обозримое время, и получаете, по сути, результат к которому изначально стремились.

Так рост числа функций, которые нужно будет написать на Си вы себе представляете?

Банальный пример. Сравните qsort и std::sort. Как по понятности прототипа и простоте использования, так и по возможностям для встраивания и оптимизации. Си нужен только в двух случаях - нет компилятора или нет (нормальной) команды... В остальных случаях плюсы всегда лучше.

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

Ваши предложения по реализации обобщенного программирования для нативного языка? Дженерики нормально сделать(чтоб по капотом были не ссылки со стертыми типами, как в Java, а как в шарпе, например) можно только при наличии виртуальной машины и jit. Возможно, даже уровня llvm было бы достаточно. Но тем не менее, для переносимых нативных решений какие варианты? И да, для языка этого уровня возможность специализации так же важна.

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

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

void qsort (void* base, size_t num, size_t size,
            int (*compar)(const void*,const void*));

vs

template <class RAIterator, class Compare>
void sort (RAIterator first, RAIterator last, Compare comp);

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

То легендарности anonymous'а тебе далеко.

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

На одной полке с Золотцем, Наггумом и Луговским.

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

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

Ну если на Си используются qsort и другие алгоритмы с указателями на функции объем данных большой, то может вам переписать на С++. Вон по ссылкам выше разница в 2 раза почти даже на простых функциях.

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

Ну золотце то повыше рангом будет.

ты-то хоть знаешь определение множества и бесконечности?

stevejobs ★★★★☆
() автор топика

Читаю этот тред и удивляюсь. Откуда у вас столько фанатизма? Уверен, многие из вас отрицательно относятся к религии, но вы не заметили, что сами построили религию вокруг языков программирования?

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

Покажика мне сначала где в реальных задачах бесконечность, а потом будем разговаривать:3 Только ради ЗОЛОТЫХ тредов на нульче когда он уже скатился.

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

Можно. Но у нас сортировка вызывается редко и это не очень критично

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

Есть qsort на макросах. С -O2 даже быстрее чем std::sort, с -O3 чуть уступает. А вообще-то, у qsort и std:sort разные алгоритмы сортировки.

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

Хотел погуглить как канонично отвечать, но соответствующие треды смыло. Можешь дать линк на что-нибудь особо смачное?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от dvl36

Вроде и там и там быстрая сортировка.

На макросах - да, можно получить что-то похожее по производительности на С++. Но это ад в реальных задачах. Да и какой в этом смысл? Макросы еще хуже шаблонов. Так что... Вынужден согласится с мнением выше - Си нужен тогда, когда нет компилятора С++ или команда его не знает. С++ и быстрее и лучше.

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

Вроде и там и там быстрая сортировка.

В std::sort какой-то introsort применяется.

Но это ад в реальных задачах.

Ничего такого ужасного в этих макросах нет.

С++ и быстрее и лучше.

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

#include "qsort.h"

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

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

Вот кстати не заню он это или фейк http://ru-declarative.livejournal.com/108182.html?thread=1481878

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

В std::sort какой-то introsort применяется.

а не меняется ли там алгоритм в зависимости от ситуации?

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от dvl36

Вообще-то С быстрее,

Бредовое утверждение

а этот случай с сортировкой, один из немногих, где C++ что-то показывает

он показывает, что на С++ можно реализовать высокопроизводительные абстракции, в отличие от С.

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

а не меняется ли там алгоритм в зависимости от ситуации?

Да, как-то так. Я не вникал.

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

Бредовое утверждение

Я знал что кто-то это напишет :) Но дела в RL не всегда позволяют отгородить утверждение массой условий и длинно рассусоливать. Кто-то поймет, кто-то нет. Ну и ладно.

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

Он это, он. Золотце доставлял, пока были треды про бесконечности и матан, а вот когда начались евреи - все скатилось в сраное говно вместе с самим /c/. Который, судя по этому треду, полным составом переехал на лор, лол.

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

Да всем наплевать на твои идиотские мемы, тут их никто не понимает. Ты такой же чужеродный элемента для Development, как и drBatty. Пора бы от тебя тоже избавиться.

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

Вам только что было показано, что С++ может быть быстрее. А вот С быстрее С++ быть не может.

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

Вам только что было показано, что С++ может быть быстрее.

Да, может, особенно на разных алгоритмах. qsort и std::sort они разные. Understand?

А вот С быстрее С++ быть не может.

Вообще-то я нашел реализацию qsort-а на макросах, переделал под нее тест, по ссылке сверху, и «нарезал» «плюсы» так по-быстрому.

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

Да, может, особенно на разных алгоритмах. qsort и std::sort они разные. Understand?

Вы это уже доказали?

Вообще-то я нашел реализацию qsort-а на макросах, переделал под нее тест, по ссылке сверху, и «нарезал» «плюсы» так по-быстрому.

Нет. Это же код на С++ ;)

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