LINUX.ORG.RU

Продуктивность разработки на C++.

 , ,


6

12

Уважаемые программисты!

Предлагаю порассуждать о продуктивности разработки на C++ по сравнению с так называемыми скриптовыми языками. Вот, принято считать, что языки на вроде Python позволяют работать программисту более продуктивно по сравнению с C++. И что, дескать, на C++ надо писать только узкие места и всё такое.

Мне же хочется четкого понимания. Может быть это миф? А может быть это просто инерция, потому что так вот принято считать и все тут. Вот сегодня в C++ уже не надо думать об освобождении памяти, так как есть умные указатели. Сегодня есть уже более-менее нормальные IDE для C++. Так? Так.

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python? Какие будут рассуждения? Может быть есть какие-то реальные обоснования на этот счёт, кроме как «в конторе Y так делают, значит смысл есть, они умные, им виднее». А может быть есть какие-то рецепты по продуктивности работы на C++?

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

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

Ламер ты и есть ламер :-) Выбирать «самый оптимальный» среди множества оптимальных по разным критериями - это так же сильно, как сравнивать вафли с табуретками :-) Если ты даже в такой элементарщине застрял, то какой там тебе цепепе с его отмороженным аппаратом типов :-) Сходи в школу для начала :-) Лол :-)

На вот, почитай что такое критерии оптимальности и расскажи нам всем как ты собрался искать «самый оптимальный» среди оптимальных по разным критериям :-) Ох и бред :-) Бгг :-)

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

Вот смотрим. Как действует данная малоразвитая амёба. Амёба ни на что не отвечает - всё игнорирует. Она выкатила какой-то несвязный бред про школу, ты ламер потому что ламер. «Это как вафли с табуретками». Естественно, что данный мусор никогда ничего конкретного не напишет. Он никогда не ответит в своих потугах на вопрос «почему?». Потому что это балаболка, она понимает, что она никчёмна, что она уже слилась. Поэтому она и пытается нести несвязный, неконкретный бред.

На вот, почитай что такое критерии оптимальности и расскажи нам всем как ты собрался искать «самый оптимальный» среди оптимальных по разным критериям :-) Ох и бред :-) Бгг :-)

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

Почему это табуретка это написало? Потому что она понимает, что напиши она что-то конкретно - тут же обделается, как и до этого.

Поэтому она пастит левую ссылку. Ничего не объясняя, не делая ни единого вывода, никак не опровергая ни одного моего утверждения.

Она просто пастит дерьмо, в надежде на то, что какой-то мимокрокодил увидит эту ссылку и подумает «ба, да эта табуретка смогла ссылку спастить - она сто процентов понимает что она постит и зачем». Человек просто подумать не может о том, что эта просто идиот.

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

Да нет, именно это и будет делать эта табуретка. Т.к. ничего иного она не может. В этом и суть её методики.

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

ни единого вывода

Вывод один - ты ламер и балабол :-) Сначала ты напердел лажу про «самый оптимальный» :-) Потом тебе дали понять, что оптимальным может быть только одно решение :-) Ок, ты приплёл критерии оптимальности, сопроводив это пердежом что «самый оптимальный» таки существует :-) Но ты не смог показать как ты собрался выбирать «самый оптимальный» из множества оптимальных по разным критериям :-) Слив засчитан :-) Лол :-)

anonymous
()

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python?

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

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

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

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

Если хочешь начать учить плюсы, прочти сначала вот эту новость: Члены комитета по стандартизации ISO/IEC C++ выступили с критикой нового стандарта языка C++17. С такой терминологией тебе придется иметь дело. Астановись пока не поздно!

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

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

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

В том то и дело, что промышленные проекты на С++ могут собираться несколько часов при первом билде
За это время на скриптовом языке ты уже успеешь

Давай порассуждаем. Вот ты вменяешь в вину C++ медленную компиляцию. Это факт. Но назови хоть один такой проект, пожалуйста, который компилируется «несколько часов» И который можно было бы переписать на скриптовом языке? Ну вот давай представим себе, что GCC, (который, к слову, компилируется на моей машине где-то полчаса), переходит на Python. Сколько потребуется времени на компиляцию ядра Linux таким компилятором?

Или давай попробуем себе представить миграцию Chromium на всё тот же Python. Или нет, давай возьмём Ruby - выразительный такой весь из себя язык. На этом же языке запилим виртуальную машину JavaScript. Ты себе представляешь эффект?

Я это к тому, что те проекты, которые на C++ собираются часами, немыслимы на скриптовых языках и подавно. Кто-нибудь мыслит себе такое?

azelipupenko
() автор топика
Ответ на: комментарий от sotlef

За это время на скриптовом языке

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

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

холодный расчёт сегодняшних опытных кодеров, знающих C++ и Python, когда они предпочитают второй первому.

Никогда. Крестокодер все пишет на крестах, даже если задача решается одной строкой в баше. Дело в том, что после постижения цепепе уже места в голове не остается. Вот если человек не практикующий кодер, а какой-нибудь научник, то другое дело. Там цепепе крайнее средство.

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

Тут признаюсь, что переложил опыт моих коллег, которые сопоставимый по объему код на С# собирают намного быстрее кода на С++. Имеется код на С++, который разрабатывается уже очень давно, примерно 20 лет, состоит из кучи модулей (более 100) и ядра. У кого-то он собирается 1.5 часа, у кого-то 2. Бывало, что при линковке я вечером в конце рабочего дня, когда дело доходило уже до линковки некоторых проектов, уходил домой, и она заканчивалась в середине ночи. Разработчики, которые переписывают сейчас проект на С# этой хуйней не страдают

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

20 лет проекту, а он до сих пор собирается. Вот это и есть один из плюсов c++. Можешь представить себе код на шарпе 20-летней давности? Нет, не можешь, потому что дотнету 15 лет всего. Ну и шарп не скриптовый всё же.

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

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

sotlef
()

python отлично подходит как и любой скрипт для «вызова библиотек». например одной строкой загрузить данные, второй строкой почистить их и третей строкой обучить лес деревьев. Это если правильно на нем писать. Если на пайтоне писать как на С++, а если в вашем коде есть цикл, то скорее всего вы пишете неправильно, то пайтон хуже с++.

Таким образом кита со слоном сравнивать не стоит.

i3draven ★★
()

Особо одаренные кодописатели, с ментальным возрастом 18 лет считают что программисты на C и C++ чуть ли не ключом радиста набивают единички и нули прямо на поверхности жесткого диска.

Они не слышали, например, о Qt где уже давно можно писать в 2 строки разные штуковины. И не видели нормальных IDE, коих для плюсов наплодилось огромное множество.

Например, никто видимо в глаза не видел тот же QtCreator где минимализм, где можно в два клика быстро создать проект и комбинацией клавиш «Ctrl+B» собрать его. В том же QtCreator из коробки поддерживаются qmake, Qbs, CMake. Особенно первый. QtCreator это еще министудия.

Извините господа, но судя по вашим комментариям вы дальше книги «С++ за 21 день» и изучения STL(которая никогда не отличалась функционалом) не дошли. У вас до сих пор все собирается ручками через вызов gcc в командной строке. Интересно! Люди вообще слышали о VisualStudio, например. Об Xcode.

У меня такие впечатления что тут одни сисадмины, которые ничего кроме make & make install

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

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

Потому что твои мапы раскладываются в тучу кода. Ты забыл что для ассоциативных массивов необходимо выполнять пробег по дереву либо массиву. У тебя поиск элемента в лучше случае будет логарифмическим.

А в Си и плюсах реализована семантика O(1). Если ты можешь за констатное время получить доступ к элементу массива, значит такие массивы будут присутствовать в языке. Все что O(1) уже засунуто в язык давным давно.

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

baist ★★
()
28 ноября 2018 г.
Ответ на: комментарий от rustonelove

Вдруг это я чего-то спустил.

Оговорочки по дяде Фрейду ;)) Жаль, банят акки быстро. Где драма?

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

Где драма?

Вот ща царь придёт и на кол посадит за некрофилию. И будет драма.

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