LINUX.ORG.RU

Ушат помоев в сторону крестолюбов

 , , ловите наркомана,


15

14

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

Последние 7 лет я пишу сугубо на C, и только под Linux (да, да -std=gnu99 и accept4, dup3, __attribute__((cleanup(dtor))) и прочие приятности, позволяющие сделать волосы шелковистее на 15.5%) и не понимаю, для чего вообще нужен C++? То, что на сишке делается красиво и элегантно, в крестах напоминает соитие парализованных дцпшников (к сожалению, утерял картинку, но именно этот образ всплывает в голове, когда вижу очередную порцию крестолапши).

Давайте посмотрим на типичного C++ разработчика: он использует STL, boost, многие любят Qt (не только для GUI), якобы чтобы «писать кроссплатформенный код». В итоге болезный не знает током ни WinAPI, ни POSIX — ничерта. Он абсолютно не разбирается, как работает целевая система, для которой пишет код! Крестокодер просто не осознает, какой лютый ужас кроется за его любимыми iostream-ами, какое лютое говно лежит в boost::filesystem::path, насколько убого-низкоуровневым является boost::asio в 2016 году.

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

Также эти убогие завистливо смотрят на type inference в языках, проектировавшихся не как «C на стероидах», и в ответ начинают лепить template и auto не к месту, от чего код адово пухнет и даже IDE перестает его понимать.

Серьезно, просто прекратите писать на этом языке. В следующий раз, начиная новый проект, выберите java (щютка)/go/swift/rust/c. Прекратите насиловать труп и отравлять зловонием все вокруг!

Перемещено true_admin из talks

★★★★

Последнее исправление: a1batross (всего исправлений: 2)

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

Ну а что мешает рассматривать CMake не по отдельности, а вместе со сборочной тулзой по вкусу?

Тем, что у меня, например, на основной рабочей машине (под Windows, да), только GCC-шных компиляторов 8 версий, плюс две версии VC++, плюс clang. Да и на Linux-овых машинах по несколько версии gcc и clang-а стоит. В таком зоопарке запариваешься CMake-ом под каждый тулсет набор родных сборочных файлов генерировать.

Вот не надо гнать на документацию, она в CMake отличная.

Ну значит я тупой. Ибо по всем нетривиальным вопросам приходилось искать ответы в Google.

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

В этом и проблема, что только сейчас. Теперь еще годик-другой будут интегрировать и вот потом заживём.

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

Значит, это проблемы каждой IDE. Зачем вообще парсить CMake? Если в EXPORT_COMPILE_COMMANDS есть недостатки, нужно их исправлять, а не плодить велосипеды.

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

ты «не спец» по оценке сложности алгоритмов

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

Тем, что у меня, например, на основной рабочей машине (под Windows, да), только GCC-шных компиляторов 8 версий, плюс две версии VC++, плюс clang. Да и на Linux-овых машинах по несколько версии gcc и clang-а стоит. В таком зоопарке запариваешься CMake-ом под каждый тулсет набор родных сборочных файлов генерировать.

А как ты предложил бы действовать? Предположим, ты проектируешь новую систему сборки с нуля.

Ну значит я тупой. Ибо по всем нетривиальным вопросам приходилось искать ответы в Google.

Не знаю, кто тупой, но я so far встретился только с одним случаем недостаточно документированного поведения — приведение PRIVATE к PUBLIC в зависимостях компоновки статических библиотек при транзитивной компоновке. Этого действительно нет в манах, пришлось идти в ML и мне там вроде бы даже пообещали исправить.

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

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

Вот не надо гнать на документацию, она в CMake отличная.

Сейчас хоть шрифты там нормальные сделали :-) Раньше надо было под лупой смотреть :-)

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

Я не большой фанат C++,

оно и видно

вот сейчас я разбираюсь в OBS Studio (официально рекомендованная софтина для твича), чтобы доработать её для себя и стримить летсплеи на ютуб

Вот тебе репа, пойди и охреней:
https://github.com/jp9000/obs-studio

Например, вот этот кусок говна разработчики посоветовали мне в качестве примера как писать плагины:
https://github.com/jp9000/obs-studio/blob/master/plugins/obs-text/gdiplus/obs...

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

А как ты предложил бы действовать?

Использовать инструменты, вроде SCons. Ну, собственно, я своим похожим велосипедом пользуюсь уже 12 лет. А недавно еще и возможность подтягивания зависимостей туда добавил, еще удобнее стало.

Из новых разработок любопытна система build2: https://build2.org/ Но она, походу, еще на самой ранней стадии развития находится.

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

Да почти по всем. Начиная от того, как правильно использовать этот самый ExternalProject_Add и заканчивая поиском возможностей задать построения so-шки и a-шки из одних и тех же исходников.

Почему-то в Google быстрее находится и пример, и пояснение к нему, чем в документации на сайте CMake.

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

Например, вот этот кусок говна разработчики посоветовали мне в качестве примера как писать плагины:

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

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

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

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

вирусы то на пэка тебе c++ не ставит случаем?

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

Это ты еще о связке C# + C++ не написал. Когда для вызова плюсового кода надо писать свой, особо уличный цпп, подчиняющийся подвальному монстру из микрософта.

maven

SpringMVC

Кто о чем, а вшивый о бане? :)

unt1tled ★★★★
()

Начал хихикать с этого места:

...сделать волосы шелковистее на 15.5%...

И закончил на этом:

Прекратите насиловать труп и отравлять зловонием все вокруг!

=))
Прекрасно!!!11 Аффтар безусловно гениален.
Сам сишнег, принимался за кресты несколько раз, но так и не осилил. Всякий раз начитало люто тошнить.
Однако, работодатели почему-то требуют Си++, и постоянные поиски работы заставляют пытаться вкуривать кресты снова и снова.
Кроме того, Win, мать их, API как бы намекают.

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

Например, вот этот кусок говна разработчики посоветовали мне в качестве примера как писать плагины:

При чем тут C++, не ясно. Говно там в первую очередь от WinAPI. Было бы изначально написано на Qt было бы красиво.

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

Да ладно. Вот такой код не зависит от того, Qt это, или WinAPI:

	switch (align) {
	case Align::Left:
		if (vertical)
			format.SetLineAlignment(StringAlignmentFar);
		else
			format.SetAlignment(StringAlignmentNear);
		break;
	case Align::Center:
		if (vertical)
			format.SetLineAlignment(StringAlignmentCenter);
		else
			format.SetAlignment(StringAlignmentCenter);
		break;
	case Align::Right:
		if (vertical)
			format.SetLineAlignment(StringAlignmentNear);
		else
			format.SetAlignment(StringAlignmentFar);
	}
От копипасты можно было бы избавиться так:
	switch (align) {
	case Align::Left:
		handle_halign(StringAlignmentFar, StringAlignmentNear);
		break;
	case Align::Center:
		handle_halign(StringAlignmentCenter, StringAlignmentCenter);
		break;
	case Align::Right:
		handle_halign(StringAlignmentNear, StringAlignmentFar);
		break;
	}
Где handle_halign — либо отдельный приватный метод, либо лямбда вида:
	const auto handle_halign = [&](auto vert, auto horz) {
		if (vertical)
			format.SetLineAlignment(vert);
		else
			format.SetAlignment(horz);
	};

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

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

В Си вообще нету хэш. таблицы. Вот нету и всё.

Ты хотел сказать «в стандарте языка C нет хэш таблицы»? Какое отношение это имеет к тому, что ни один из вас ничегошеньки не знает о поведении unordered_set/unordered_map?

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

Это не stl, буст это конечно мощная штука. Но такие очевидные и простые вещи должны быть в стандартной либе. Я не хочу тащить этого монстра из-за всякой фигни которую поленились разрабы стандарта впилить в std. Не хочу тащить QT ради того, что бы удобненько получать день недели. Я просто забью и сделаю это через костыли. Но язык и его стандартная либа от этого лучше не стали.

Dudraug ★★★★★
()
Ответ на: комментарий от alex-w

Приводить решение задачи B, когда было испрошено решение задачи A - это очень сильно.

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

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

Какое отношение это имеет к тому, что ни один из вас ничегошеньки не знает о поведении unordered_set/unordered_map?

Зачем мне знать о ее поведение? Ты вообще о инкапсуляции слышал? О том, что нельзя строить реализацию на основе имплементации. В стандарте описан контракт этой коллекции, там описано поведение хэш таблицы (O(1), лучший случай, худший случай, букеты, элементы в букетах и бла-бла, ресайз и рехэш, контроль за рехэшем и бла-бла-бла). Зачем мне знать что-то еще? Там все довольно очевидно. Ты про то как в твоем любимом Си был такой баг слышал Изменение поведения memcpy в glibc привело к странным ошибкам ?

Ребята просто знали как работает ну и решили заоптимизировать на основе этих данных.

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

У тебя портянка на элементарную задачу. Короткого аналога ты до сих пор не привел.

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

CMake вполне хорош.

Шаг вправо-шаг влево и начинается содомия в силу беспросветной убогости этого инструмента. Там, где для старого доброго make можно написать просте суффиксное правило, в cmake приходится неистово сношаться.

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

Вот не надо гнать на документацию, она в CMake отличная.

Не покажешь, где находится отличная документация по cmake? На офсайте и в составе пакета почему-то лежит убогое говно.

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

Не хочу тащить QT ради того, что бы удобненько получать день недели

Палю годноту: localtime (или gmtime, если UTC), есть в стандарте c89 => всегда доступен в крестах. Думаю, дальше догадашься, что к чему:

           struct tm {
               int tm_sec;    /* Seconds (0-60) */
               int tm_min;    /* Minutes (0-59) */
               int tm_hour;   /* Hours (0-23) */
               int tm_mday;   /* Day of the month (1-31) */
               int tm_mon;    /* Month (0-11) */
               int tm_year;   /* Year - 1900 */
               int tm_wday;   /* Day of the week (0-6, Sunday = 0) */
               int tm_yday;   /* Day in the year (0-365, 1 Jan = 0) */
               int tm_isdst;  /* Daylight saving time */
           };

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

Да ты совсем наркоман.

Ок, вот тебе простой пример: делаю проект, внутри которого используются различные лексеры/парсеры, генерируемые flex и bison. У лексеров расширение l, у парсеров — y. На make:

tool1: tool1_main.o parser1.y.o lexer1.l.o
    $(CC) -o$@ $(LDFLAGS) $^ $(LIBS)

tool2: tool2_main.o parser2.y.o lexer2.l.o
    $(CC) -o$@ $(LDFLAGS) $^ $(LIBS)

%.o: %.c
    $(CC) $(CFLAGS) -c $<

%.y.c: %.y
    $(BISON) -o $@ $<

%.l.c: %.l
    $(LEX) -o $@ $<

-include .deps
На CMake — можно сделать через жопу с custom target-aми, но так делают только мудаки. По-хорошему нужен add_executable, который также умеет специально обрабатывать файлы с расширениями .l и .y, но в cmake не завезли suffix rules, поэтому придется писать портянку, фильтрующую .l и .y файлы, добавляющую generated-файлы и custom-таргеты автоматом. Эта портянка раза в полтора длиннее приведенного makefile-а.

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

От копипасты можно было бы избавиться так:

А ничего что в этом случае код с копипастой проще и понятнее? Каргокульт какойто.

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

Но сборочный инструмент без поддержки IDE не нужен. Есть куча народу, которая не использует CMake именно поэтому.

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

А ничего что в этом случае код с копипастой проще и понятнее?

Он даже в таком виде не проще, и не понятнее. Для того, чтобы проверить, правильно ли выставляются значения, нужно проходить каждую ветку, т.к. парность вызова SetLineAligment и SetAligment, а так же аргументы для этих методов размазаны по коду.

Про сопровождение и развитие такого кода и говорить не приходится.

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

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

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

Он даже в таком виде не проще, и не понятнее.

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

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

И? Там больше половины кода на сишке.

Приведенный пример кода вполне себе нормальный? Да, видно что сишники писали, ну и что? Ничего катастрофического там нет.

GUI, который на Qt, совсем не по канону сделан, но это уже тараканы сишников. Хоть бы враппер для своей сишной либы сделали. А то получился си с классами.

Вы вон сорцы OpenCV посмотрите - вот там красота.

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

Так а как напечатать в человекочитаемом формате без дополнительного костыльного свича и самописной функции? В .net оно просто работает, без свич/кейса по интам.

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

Про сопровождение и развитие такого кода и говорить не приходится.

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

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

В каком «таком»?

В исходном. Там ведь не один такой switch, а два похожих подряд. Оба явно получены путем копипасты друг из друга.

заменили непонятной ф-ей с нетривиальной (зависящей от глобальной переменной) логикой.

Функция на 4 строчки с одним if-ом стала нетривиальной? Пожалуй, вы ошиблись профессией.

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

То что ег ов принципе можно в целом получше переписать

Ануткать. А мы поржом тут всем LOR-ом.

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

Если с копипастой проще - надо делать с копипастой, сэкономишь на сопровождении.

«Копипаста», «сэкономишь на сопровождении». Можно примеры подобного сочетания?

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

Использовать инструменты, вроде SCons.

Я спросил немного другое. Как, по-твоему, должен выглядеть хороший и удобный workflow в твоей задаче (там, где куча компиляторов)?

Начиная от того, как правильно использовать этот самый ExternalProject_Add

А чего его «правильно использовать»? Собираем статически, префиксы дефолтные, всё что нужно (путь к cmake, генераторы, тулчейн-файл) наследуем от себя, потом добавляем установочный префикс в туда, где его найдёт find_package() (т. е. в CMAKE_PREFIX_PATH). Альтернативно, делаем установочный префикс равным нашему собственному и собираем как угодно, тогда всё найдётся само.

Впрочем, я не любитель bundled dependencies и ни разу не использовал ExternalProject_*, так что мог какие-то мелкие тонкости проглядеть.

аканчивая поиском возможностей задать построения so-шки и a-шки из одних и тех же исходников

Два таргета с разными именами и вручную задать OUTPUT_NAME?

В экспортируемом Config-файле потом создаём INTERFACE таргет без суффикса и добавляем к нему в зависимости один из реальных согласно значению BUILD_SHARED_LIBS.

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

Хамишь и скатываешься до личностей. Видимо, я в точку попал.

Не вижу ничего плохого в фанбойстве. Я, например, ярый фанбой Линуса до тех пор, пока он не замахивается на божественную невидию. Извини, если обидел.

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

Ничего катастрофического там нет.

если будешь работать senior c++ developer, уверен что это будет последняя фраза перед твоим увольнением =)

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

Как, по-твоему, должен выглядеть хороший и удобный workflow в твоей задаче (там, где куча компиляторов)?

У меня под каждый toolset настроен свой набор переменных среды (PATH и т.д.). А запуск сборки или пересборки выполняется одной и той же командой, без генерации каких-то новых артефактов.

А чего его «правильно использовать»?

В том, что вы наговорили, чувствуется нехило прокачанное CMake-фу. Большая половина этих слов мне ни о чем не говорит.

Два таргета с разными именами и вручную задать OUTPUT_NAME?

+ еще добавить разные наборы defines для каждого из типов сборки.

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

Функция на 4 строчки с одним if-ом стала нетривиальной? Пожалуй, вы ошиблись профессией.

Таков тренд :-) Так, сейчас среди цепепе программистов функция на 2 строчки стала нетривиальной :-) Например, вот это

S::~S() // Explicit delete, uh, nontrivial!!1
{
  delete impl_;
  impl_ = nullptr;
}

считается нетривиальным :-) Надо писать так

S::~S() = default; // I'm fan of unique_ptr<>!!1

Видишь, было две строчки, а теперь просто = default !11 :-)

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

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

И ты тоже ни черта не знаешь о том как uthash работает по большому счету.

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

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

А еще, я чаще использую std::map, т.к. мне не надо иметь миллионы элементов и совершать поиск там миллион раз в секунду.

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

У меня под каждый toolset настроен свой набор переменных среды (PATH и т.д.). А запуск сборки или пересборки выполняется одной и той же командой, без генерации каких-то новых артефактов.

Не особо понятно тогда, чем здесь мешает тот факт, что «CMake — генератор мейкфайлов, а не полноценная сборочная тулза». Ну и запускай не scons, а cmake --build TOOLCHAIN_SPECIFIC_BUILD_DIR — даже тулчейн-файлы никакие не нужны, если ты в каждом случае $PATH переопределяешь.

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

Функция на 4 строчки с одним if-ом стала нетривиальной? Пожалуй, вы ошиблись профессией.

Из названия вообще непонятно что делает, безе перехода к объявлению/описанию вообще не ясно что там происходит.

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