LINUX.ORG.RU
Ответ на: комментарий от stevejobs

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

донской табак еще не весь скурил?

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

Откуда ты jetbrains взял?

Так я про неё говорил, если ты за нитью проследуешь. Мне для CLion не хватает ресурсов ноута.

А для MS Visual Studio, Qt Creator, и для виртуалок (macOS, Win10, ArchLinux) — ноута хватает за глаза.

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

Сейчас же у меня в проекте C++ код собирается около 5 минут на минимальном наборе файлов (и 20 на полном), но уже на самом топовом железе. Никакие средства горячей замены тут не работают. Выключение LTO помогает минимально (но при этом мешает разработке). Ощущение гнева и желания разбить компьютер ногами, каждый раз когда ты поправил три строчки и оно ушло на пересборку - дичайшее!

Не пробовал пересмотреть структуру проЭкта для уменьшения зависимостей? :)

то ли дело свой собственный код

что же могло пойти не так...

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

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

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

Поправил три строчки, пересобрал проект несколько раз - и день закончился

Крестопродуктивность во всей красе.

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

в данный момент уже не нужна.

с IMode, IEditor, вкладками Designerа я разобрался сам, как работает диалог новых объектов приблизительно понял, а на текстовом редакторе плюнул на эту кучу безумного говна.

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

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

i36_zubov
()

Есть ли смысл на неё переходить с Geany? 🙂

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

а что тогда входит в овер 3 гиговый образ студии? кофемашина, цистерна водки и бордель?

всего-то в трехгиговый? Там еще онлайн-инсталлятор, не забывай :) Добросил в список компонентов еще одну версию Windows SDK (они там параллельно ставятся), и объем установки на гиг увеличился (или скорей - пошел качаться гиг апдейтов). То же самое про все остальные категории (не про ветку C++) - например, не забывай что из меню установки вижуалки устанавливается андроид вместе с исходниками и эмулятором (всеми версиями эмуляторов какие есть), установщики SDK для шиндовс-мобайла, итп. Если ты поставишь галку «установить всё, прям вообще всё», объем установленного должен тебя позабавить

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

Ну а какая ещё нужна. Там же все просто в отличии от студии и кдевелопа.

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

исключения в деструкторах считаются говнокодом только в С++. И угадай почему? Потому что кресты - убогие, в них не смогли так сдизайнить исключения и деструкторы, чтобы они друг к другу подходили. В результате крестовый код убьется на stack unwinding, а вот если ты сделаешь исключение в джавовском finalize - не произойдет ничего плохого вообще (в документации к Object#finalize так прямо и написано: Any exception thrown by the finalize method causes the finalization of this object to be halted, but is otherwise ignored.)

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

Да нет, даже наоборот, только радует.

То отсылка к

оZZии

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

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

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

«Нормальность» — относительное понятие. С одной стороны, если оборудование выполняет мои задачи, то оно нормальное.

С другой — разработка на C++ принципиально не изменилась за долгие годы, даже несмотря на новые стандарты. И почему некоторые IDE стали есть память гигабайтами — я не могу представить, разве что наплевательским отношением к ресурсам пользователя и к разработке в целом.

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

Вот и отсюда главный вопрос: зачем мне брать новое оборудование за сотни баксов? Чтобы поощрять разработчиков говнософта, которому мало гигабайта? И поощрять экономику потребительства?

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

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

Кстати да, поддержку. Со маленькими и средними проектами (больших у меня пока не было) вполне удобно работать в Emacs. Да и в Vim наверняка тоже. Как пример - открыт Emacs с кучей буферов, увешанный всякими цацками и плагинами, на втором мониторе Firefox с ютубом и пяток сайтов с документацией. Никогда не видел, чтобы общее потребление памяти выходило за 1.5 Гб.

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

И почему некоторые IDE стали есть память гигабайтами — я не могу представить, разве что наплевательским отношением к ресурсам пользователя и к разработке в целом.

Потому что их пишут всякие хипстеры на Java, и простите за выражение, Electon'е с JavaScript'ом.

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

В данном случае показатель качества продукта - это количество фич

Пойми конфликт - нельзя одновременно и пилить фичи, и радикально увеличивать качество

Посмотри на новые релизы IntelliJ IDEA - каждый новый релиз содержит кучу новых фич. А в следующем будут еще, и еще, и еще. И они всё равно не успевают с той скоростью, с которой появляются новые фреймворки и языки, и добавляются новые фичи в старые

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

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

А так как у C++ всё очень костыльно (начиная с синтаксиса языка, продолжая методами программирования основанными на конвенциях), логично что его анализ занимает просто невероятное количество ресурсов0

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

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

Да не при чем тут вообще Java, на C++ скорость будет такая же, если не медленней

Например, как работают «тэги», которые используются во всяких вимах для автодополнения. Они просто бегут по тексту, и ищут регулярками паттерны типа «function NAME(params...) { ... }», и дальше NAME появляется в автодополнении

Понятно что результат работы такого алгоритма - полная чушь.

Вместо этого нормальные IDE должны полностью скомпилировать на лету весь проект, и дойти в компиляции до стадии построения финального высокоуровневого AST. Так как IDE понимает не весь AST, оно трансформирует его до понятного подмножества - «модели выполнения» сформулированной в терминах «модели языка».

Так как ты можешь в любой момент вызвать не только свой код, но и любой системный - нужно на лету компилировать не только твой проект, а вообще всю нижележащую платформу. Для C++ это означает - собрать весь линукс со всеми прикладными библиотеками нужными в проекте

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

Плюс в проекте может быть несколько языков (например бэкенд на C++ с фронтом на node.js). Плюс каждый новый фреймворк вводит новую терминологию и по сути создает дополнительный язык. Возможно, проект нужно «перекомпилировать» в разрезе сразу нескольких языков!

Плюс всё это многопоточно

Плюс что угодно из этого может поменяться, в том числе в режиме отладки

Считай сам, сколько это стоит ресурсов, и где тут бутылочное горлышко. По мне так оно в первую очередь в необходимости непрерывно ИНДЕКСИРОВАТЬ ВЕСЬ МИР, и потом держать его в кэше, мгновенно перестраивая кэш в самых скотских условиях. Имхо, по сравнению со сложностью задачи, разница между тем, реализовано это на крестах или жабе - меркнет (вот было бы на питоне или жабоскрипте - да, задница).

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

вот сразу видно, что человек - жабист, и зачем сделаны деструкторы он не понимает.

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

Анус свой забань

Язабан еще раз.

Кстати, ты случаем не фанат BraZZers?

Как ты угадал? А ты?

Valman_new
()

Пока нормальной поддержки cmake не будет - нинужно.

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