LINUX.ORG.RU

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

 , ,


6

12

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

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

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

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

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

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

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

под валгриндом тормозить

всё равно быстрее питона

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

Да нет, вчера был вебинар по Conan. Нормальный такой менеджер пакетов

Такое бывает когда работает инстинкт заполнения головы информацией: если новые данные не с чем сравнить, то возникает эйфория и чувство получения «потаённых» знаний и им сразу же навешивается ярлык «правильно». Есть, допустим, имеешь число 7500 - много это или мало? Питонщинк, как и человеческая ЦНС, сразу скажет, что много:

>>> 7500 > None
True
А должно быть None: данные можно оценивать только в контексте существующих других данных.

... остаюсь при своём мнении по поводу возможности создания стандартного менеджера ... мне он очень нужен.

Из нужности чего-либо тебе лично и какой-то незначительной группе единомышленников не следует нужности всем. Тут тебя снова подводит ЦНС позволяя положительно оценивать важность в отрыве от контекста из-за недостатка знаний.

Мне хочется подгружать зависимости легко и непринуждённо.

Ну да, пока не вылез за пределы hello world и не перестал писать разовые приложения.

Почему я должен вечно жрать кактус, оглядываясь на какую-то мифическую философию C++, или на корпорации мирового уровня

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

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

Всё верно понимаешь, но не до конца. За шубой в магазин идёт не торгаш, а потребитель, думает как бы ничего не делать и поиметь систему торгаш, а инженер - как из частей сделать целое. Инженер за свою жизнь может быть в разных ролях, даже в нескольких одновременно - например, может быть инженером и потребителем если покупает инструмент необходимый для сборки чего-то в целое.

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

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

Из vim и сопутствующих инструментов не нужно готовить IDE, это инструменты _вместо_ IDE - ими сразу нужно пользоваться.

Вот, по теме! А почему ты иногда вспомогательное гогнецо пишет на питоне?

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

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

Если очень хочется, можно так:

class A {
    A(){}
    virtual ~A(){}
    virtual void a(int n){
        std::cout << n << std::endl;
    }
};
class B {
    B(){}
    virtual ~B(){}
    virtual a(int n) = 0;
    virtual b(int n) = 0;
}

//main
auto *a = new A;
B *b = (B*)a;

a.a(3); // OK
b.a(3); // OK
b.b(3); // FAIL

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

B *b = (B*)a;

С дуру можно и х%й сломать.

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

вдруг вы начнёте с уважением и заботой относиться

Потому, что «от их имени выражают нам презрение»? У меня есть плохая новость, человеческая психика так не работает :)

решать в первую очередь _их_ задачи

«мы» и решаем их задачи. Быстрее, если допустимо «умолчательное» поведение.

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

Из vim и сопутствующих инструментов не нужно готовить IDE, это инструменты _вместо_ IDE - ими сразу нужно пользоваться.

ещё скажи что там без документации можно пользоваться этим якобы редактором текста.

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

Такое бывает когда работает инстинкт заполнения головы информацией

Логика принята.

если новые данные не с чем сравнить.

Совершенно верно. Но вот прикинь. Ты находишься в пещере и хочешь покушать чего-то горячего. Но об огне ты ещё не знаешь, а горячего хочется, потому что холодно вокруг, пещера. И тут появляются пришлые люди, которые показывают тебе коробок спичек. О существовании огня ты ничего не знал, то есть тебе «не с чем сравнивать», но тебе просто хотелось горячей пищи здесь и сейчас. Согласился бы заполучить спички? Или предпочёл бы додумываться, что такое огонь и как его можно добыть без спичек, но самостоятельно? Напоминаю, кушать хочется, желудок ноет, коренья и жуки уже надоели. Не знаю, как ты, а я бы взял спички в этой ситуации.

>>> 7500 > None

А должно быть None

Не согласен. Должно быть Undefined.

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

Не следует, но я никому и ничего не навязываю. Я всего лишь хочу есть мясо, а не жрать коренья.

Тут тебя снова подводит ЦНС позволяя положительно оценивать важность в отрыве от контекста из-за недостатка знаний.

Нет, моя ЦНС торгаша здесь ищет решения, чтобы покушать. Как ни странно. И решения здесь три: искать что-то доступное и готовое; придумывать что-то свое; ждать когда «все» осчастливят меня и/или группу единомышленников своим нужным для всех решением. Т.к. мне хочется кушать прямо сейчас, третий вариант отпадает однозначно. На второй вариант мне жалко времени. Так что я предпочту искать готовое решение.

Рассуждаешь про стандартную инфраструктуру, а не про свои личные предпочтения.

А всё начинается из чьих-то личных предпочтений. Ну и сам C++ начинался из личных предпочтений Страуструпа. Захотелось ему писать на C как на Simula. Результат ты знаешь. Вот и другие люди берут уже C++ и свои личные предпочтения пытаются сделать стандартными. Это нормально.

Получилось так потому что не разбираешься в инструментах разработки, для тебя есть единственный инструмент в виде монолитной и неуклюжей IDE

В таком случае, ты не разбираешься в людях, с которыми общаешься. Потому что IDE не является единственным моим инструментом. У меня богатый опыт использования Emacs, например. И мне уж точно не по наслышке известно, насколько Emacs уступает коммерческим IDE для C++. То же самое и с Vim.

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

По итогу получаем, что идеальная ситуация, когда в языке нет UB (как в питоне) и есть нормальные типы (в идеале, лучше чем в C++).

В ответе получаем или Java (для утят, ушибленных C++) или Scala/Haskell/Ocaml/Typed Racket (если к синтаксису не привязываться).

monk ★★★★★
()

Pyhton позволяет говнокодить продуктивнее чем C++. Из-за динамической типизации. Поэтому ученые и примкнувшие к ним академики его любят.

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

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

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

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

Внезапно скорость не важна для всех. Ученые используют готовые поделки.

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

Совершенно верно. Но вот прикинь. Ты находишься в пещере и хочешь покушать чего-то горячего. Но об огне ты ещё не знаешь, а горячего хочется, потому что холодно вокруг, пещера. И тут появляются пришлые люди, которые показывают тебе коробок спичек. О существовании огня ты ничего не знал, то есть тебе «не с чем сравнивать», но тебе просто хотелось горячей пищи здесь и сейчас.

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

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

Мало кому готовые поделки годятся.

А вообще, есть Octave, R, maxima и уйма узскопециализированных вещей (те же MIDAS, IRAF и т.п.). Зачем этот дебильный пхытон использовать?

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

«Утята, ушибленные C++» на Java никогда не посмотрят из-за её неэффективности и отвратного синтаксиса. А Scala/Haskell/Ocaml/Typed Racket никому не нужны по тем же причинам + вдобавок маргинальны. Я лично считаю что пока будущее за Go как новым питоном и Rust как новым C/C++, но пока они подберутся к Python/C++ по популярности, последние сами успеют заметно развиться.

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

Go как новым питоном и Rust как новым C/C++

Go лучше питона только для «утят, ушибленных C++». Для питонщиков фигурные скобки — серьёзный недостаток. А отсутствие классов, метаклассов, переопределения операций и прочих удобных штук вообще хоронит его.

Называть синтаксис Java отвратным и вместо него предлагать Rust? Шутишь? Любую программу на Java программист на C++ прочитает без проблем. И даже чтобы писать на Java после С++ переучиваться почти не требуется. А на Rust читается лишь немногим легче, чем на Haskell. Кроме того, Rust с unsafe наследует UB от C++.

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

Для питонщиков фигурные скобки — серьёзный недостаток

У вас какое-то странное представление о разработчиках на питоне. Для адекватных людей скобки или отступы - монопенисуально.

Любую программу на Java программист на C++ прочитает без проблем. И даже чтобы писать на Java после С++ переучиваться почти не требуется.

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

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

go — отстойная быдлоподелка хуже пхытона. У раста строки по дефолту в хрюникоде 32-битном — нафиг этот график? И синтаксис у него дебильный: тут в С++ черт ногу сломит (особенно с последними наворотами), а в расте вообще трешняк!

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

go — отстойная быдлоподелка хуже пхытона

Аргументы профессионала, чо. Я на нём сам пока не писал, но этот комментарий принижает вас, а не язык.

У раста строки по дефолту в хрюникоде 32-битном — нафиг этот график?

Именно и только так должно быть в любом нормальном языке. Или что вы предлагаете? С текстом в UTF-8 нельзя работать быстро, его нужно сначала мучительно побайтно парсить во всё те же 32битные кодпоинты (не забывая обработать невалидный случай!), потом их уже обрабатывать (например, перевести в lowercase по таблице), потом закодировать обратно. А если вам не нужно работать с текстом - так и используйте байтовый тип с utf-8, ascii, koi8-r и чем хотите. Я искренне надеюсь, у вас хватит ума не предлагать utf-16 или 8-bit как формат строк в языке.

И синтаксис у него дебильный: тут в С++ черт ногу сломит (особенно с последними наворотами), а в расте вообще трешняк!

Ну вон сверху Haskell упомянули и ничего. Не вижу больших проблем с синтаксисом лайфтаймов, а больше там ничего такого трешового и нет.

Чисто ради интереса, а что для вас сейчас нормальный язык? Python, C++, go и rust вы опустили.

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

Пользуюсь КОИ8-Р уже с 2002 года и мои волосы чистые и шелковистые ☺

а что для вас сейчас нормальный язык?

С, естественно.

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

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

Не хочешь использовать IDE для Java, чтобы писать на Java? Странно. А почему?

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

нельзя работать без поддержки IDE и я с этим полностью согласен.

А мне норм, хехе

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

Для адекватных людей скобки или отступы - монопенисуально.

Так по всем остальным характеристикам Го объективно хуже Питона: классов нет, декораторов нет, метаклассов нет, интроспекции нет, вроде даже перегрузки операторов нет. Для сишников бонусом идут фигурные скобки, для питонщиков они в лучшем случае неважны, в худшем — недостаток (так как отступы в Го не обязан соответсвовать структуре программы).

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

А на Си++ Вы принципиально пищите без IDE? И это удобно?

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

Не вижу больших проблем с синтаксисом лайфтаймов, а больше там ничего такого трешового и нет.

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

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

Если это примат, не видевший огня, то он он и не знает о горячей, сваренной, жареной пище.

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

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

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

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

Он никогда не найдёт огонь в пещере

пещерность (древних приматов) - это ошибка наблюдения археологических останков иследователями 19 века - так как в пещерах вероятность уцелеть случайным следам древних приматов выше чем следам регулярного обитания в тех местах где приматы приматили

---------

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

--------------------

по основному топику: в С++ при его неосторожном использовании всегда существует опасность скатывания в С(в плохом смысле) , а С(в плохом смысле) это структурный ассемблер - следовательно отличие не по назначению используемого С++[ от по назначению используемого С++(который может быть питоном при очень высокой дисциплине разработчика который продуманно приготовит бойлерплейт прячущий от него же машинерию)] в излишнем (для случая написал и забыл) микроменеджменте ресурсами исполнителя.

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

пещерность (древних приматов) - это ошибка наблюдения археологических останков иследователями 19 века

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

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

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

По итогу получаем, что идеальная ситуация, когда в языке нет UB (как в питоне) и есть нормальные типы (в идеале, лучше чем в C++).

В ответе получаем или Java (для утят, ушибленных C++) или Scala/Haskell/Ocaml/Typed Racket (если к синтаксису не привязываться).

А чем ушиблена крылатая ЦА Scala/etc...?

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

А чем ушиблена крылатая ЦА Scala/etc...?

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

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

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

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

У раста строки по дефолту в хрюникоде 32-битном

https://doc.rust-lang.org/std/primitive.str.html

String slices.

The str type, also called a 'string slice', is the most primitive string type. It is usually seen in its borrowed form, &str. It is also the type of string literals, &'static str.

Strings slices are always valid UTF-8.

https://doc.rust-lang.org/std/string/struct.String.html

A UTF-8 encoded, growable string.

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

И где нормальные 8-битные кодировки?

На свалке истории.

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

У раста строки по дефолту в хрюникоде 32-битном — нафиг этот график?

Нет. По умолчанию там UTF-8.

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

У вас какое-то странное представление о разработчиках на питоне.

Довольно распространённое.

RazrFalcon ★★★★★
()

На чем тебе продуктивнее писать, на том и пиши.

xDShot ★★★★★
()

Вот сегодня в C++ уже не надо думать об освобождении памяти, так как есть умные указатели

Ложь

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

больше там ничего такого трешового и нет

Текущие макросы ужасны. Но их планируют выкинуть.

Да и лайфтаймы скоро порежут. Нужно будет их реже указывать.

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

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

Первый раз вижу, чтобы кто-то хвалил плюсовые шаблоны. Тем более в сравнении с растом.

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

Так по всем остальным характеристикам Го объективно хуже Питона

Если проследить за хайпом, то большая часть гоферов - бывшие питонщики. Почти без исключений. Что наталкивает на мысли, что они выбирали питон не из-за фич языка. Так как у Го фич нет в принципе.

Го шустрый, чем и привлекает питонщиков, на этом его достоинства заканчиваются.

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

Тут про пакетный менеджер C++ под названием Conan, существование которого лучше, чем ничего.

По сравнению с Cargo он ещё в каменном веке.

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

А Java наследует UB от C++, ибо JVM на плюсах.

Для Java написали свой компилятор, а для Rust использовали плюсовый. Поэтому вызывается невызываемая функция, например. Можешь попробовать сочинить на Java аналог того, что по ссылке на Rust.

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