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)
Ответ на: комментарий от tailgunner

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

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

Не вопрос, вот: всегда можно сделать этого пруф.

okay, теперь давай объем кода для верификации в случае C/C compiler only и с C++ и еще (кстати ниразу не мелким и простым) компилятором плюсов сравним, прикинем по деньгам, поймем что это дольше и дороже, а с учетом что бенефитов от этого ровным счетом никаких - то ну его нафик? или фанатизм плюсовый изо всех щелей ? :)

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

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

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

Сильно подозреваю, что конструкции вида «struct GTY(()) alias_set_entry» тоже транслируются в что-то плюсовое.

Учитывая, что там внутри есть поле «hash_map<alias_set_hash, int> *children;», то, да, это гарантированно С++-ый класс.

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

Так от плюсов там остается ... погоди ... а, нифига там не остается

Так от плюсов там остается ... погоди ... а, то, что разрешено стандартом кодирования.

Напомни, что ты пытаешься доказать - что никогда не видел RT на Си++ или что-то другое?

давай объем кода для верификации в случае C/C compiler only и с C++ и еще (кстати ниразу не мелким и простым) компилятором плюсов сравним, прикинем по деньгам

И снова - что ты пытаешься доказать? Если то, что компилятор Си++ дороже верифицировать, то да, конечно, дороже.

меня всегда доставляют фанатики, им говоришь - тут ваше средство ok применять

Я не стану спрашивать, куда доставляют тебя фанатики и как ты оттуда выбираешься. Скажу просто - фанатики, которые утверждают, что Си++ нельзя использовать для написания RT и ядер ОС, настолько малограмотны, что над ними даже смеяться грех.

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

Да, именно о них. Но, похоже, я ошибся и ничего Си++-специфического в расширении GTY нет.

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

Я не стану спрашивать, куда доставляют тебя фанатики и как ты оттуда выбираешься. Скажу просто - фанатики, которые утверждают, что Си++ нельзя использовать для написания RT и ядер ОС, настолько малограмотны, что над ними даже смеяться грех.

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

Таки на этом все, с хамоватыми фанбоями крестиков все понятно. Таки над вами надо смеятся, насколько вы не опытны, малограмотны и упороты, и не понимаете что у каждого инструмента есть свои ниши, свои плюсы и минусы, продолжайте дальше в том же духе вдалбливать себе в гладенький мозг что плюсы удобно применять везде от слова совсем. Но это не смешно, тк тоже самое орут фанбои Java, JS, <подставь что то еще>, да и фанбои C.

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

мой посыл - нафига ?

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

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

Таки на этом все, с хамоватыми фанбоями крестиков все понятно

Лан. Но чтобы на этот раз - точно всё.

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

Божечки, да вас плющит похлеще ТС (если вы, конечно же, не его виртуал). Продолжайте в том же духе. Настолько отмороженных кадров я давно не видел.

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

Да, тут публика подобралась как на заказ. Еще бы царя и о большем можно было бы и не мечтать :)

А ты уверен, что его тут нет? :-) Лол :-)

anonymous
()

Надо бы ещё какую-нибудь тему про цепепе :-) Только немного позже :-)

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

Настолько отмороженных кадров я давно не видел.

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

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

Очевидно, ты не передал аргументы и поэтому в argv[х] всякая дрянь до стека в виде переменных окружения )

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

Давайте уточним: «чем меньше кода - тем легче его воспринимать» - это ложь?

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

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

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

Прекрасно понимаю о чем речь. Как раз последние два дня занимался устранением последствий копипасты.

Я где-то говорил, что копипаста _никогда_ не ведет к фейлам? Я говорил, что не любая.

Простой код с копипастой всегда является бомбой замедленного действия.

Я указал основной критерий «опасности» копипасты - когда она появляется _в разных местах_. Тогда это действительно хороший претендент на то, чтобы убрать дублирование. И это сразу ликвидирует вот эту возможность:

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

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

Где вы там увидели сложный код, неочевидные зависимости и невыводимость из контекста?

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

Скажите честно: вы просто дебил или захотелось пофлеймить на форуме?

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

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

Я говорил, что не любая.

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

Если же копипаста в пределах одного экрана - то проблем не бывает

Вы уж определитесь, если то, что в пределах одного экрана не проблема, то с какого вы доколупались до handle_halign? Там вообще все в пределах видимости.

Зависимость от внешней переменний vertical, о которой в коде вообще ничего не сказано.

Вы на плюсах вообще хоть пару строчек написали? vertical — это не переменная, это член класса TextSource, который явтоматически виден во всех методах класса TextSource. И лямбда handle_halign ведет себя как локальный метод этого же класса, поэтому и обращение к vertical в ней такое же нормальное, как и во всех других методах.

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

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

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

Бредовость заявления никак не связана с тем, констатирует оно истину, ложность или неопределенность. Она связана только с состояниеи сознания автора высказывания.

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

На практике разница между «любой» и «не любой» выясняется постфактум.

Зачем же постфактум? Я сформулировал вполне четкий и ясный критерий, который легко проверяется еще до того, как ты код начал писать.

Вы уж определитесь, если то, что в пределах одного экрана не проблема, то с какого вы доколупались до handle_halign?

Ты, видимо, потерял нить разговора? _копипаста_ в пределах одного экрана не проблема. Причем тут handle_align?

Вы на плюсах вообще хоть пару строчек написали? vertical — это не переменная, это член класса TextSource, который явтоматически виден во всех методах класса TextSource.

То есть, переменная, область видимости которой - контекст класса.

И лямбда handle_halign ведет себя как локальный метод этого же класса, поэтому и обращение к vertical в ней такое же нормальное, как и во всех других методах.

Ты, видимо, не слышал про инкапсуляцию, да? Если писать без инкапсуляции, то поле класса ничем не отличается от глобальной переменной, точно так же порождает невнятный control flow. ООП и инкапсуляцию придумали за тем, чтобы ограничить область видимости переменных и работать с ними предсказуемым, понятным способом (т.к. модули в сишку завести трудно). Это, однако, не означает, что можно в один класс напихать кучу говна, нет - надо придерживаться определенной дисциплины. Метод (и, соответственно, лямбда внутри класса) либо должны поддерживать определенные инварианты, либо указывать на зависимости. Иначе последствия обычно такие, что и махровая копипаста в разных местах - детский лепет. Вот я прочитал твою портягу кода, в ней использование вертикал не указано, я ожидаю, что оно там не используется. А потом ловлю совершенно невнятный баг.

Я не понимаю, где вы там все эти захваты увидели.

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

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

И каким образом ты по нейтральному заявлению судишь о состоянии сознания автора?

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

Еще бы царя

Боже, царя храни... А с другой стороны, анархия - мать порядка... А с третьей - еще есть и демократия... :)

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

Вот я прочитал твою портягу кода, в ней использование вертикал не указан

Ты чем смотрел? А это что по-твоему: [&]?

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

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

А ты не путаешь инкапсуляцию и сокрытие членов? :-)

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

Инкапсуляцию придумали в качестве средства, благодаря которому внесение изменения в единицу проектирования (будь то класс или модуль) не приводит к нарушению кода, который от неё зависит :-)

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

Я сформулировал вполне четкий и ясный критерий, который легко проверяется еще до того, как ты код начал писать.

Этот четкий и ясный критерий нужно засунуть автору в задницу. Ибо он не защищает от проблем, а лишь создает видимость безопасности. Попробуйте с исходном примере добавить по еще одной операции в каждую ветку if-а внутри switch-а. И поймете о чем идет речь.

Хотя нет, не поймете.

_копипаста_ в пределах одного экрана не проблема.

Это заблуждение. Но вы пока еще на себе этого не ощутили.

Причем тут handle_align?

При том, что если вам хватает мозгов разобраться с копипастой на одном экране, то должно хватить мозгов разобраться и с наличием handle_halign. Там ведь 5 строчек сама лямбда и 3 строки с ее использованием. Но вони развели на весь LOR.

Ты, видимо, не слышал про инкапсуляцию, да?

Когда чувак на вопрос «Вы на плюсах вообще хоть пару строчек написали?» начинает срать простынями текста про инкапсуляцию, ООП и control flow, то это дальше разговор можно не продолжать.

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

операция индексации по адресу же. а ты — неосилятор

А, точно :-) Префиксное разыменование по адресу закрывающей квадратной скобки :-)

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

У тебя опять проблемы с пониманием контекста?

А в чём проблем взятия адреса от квадратной скобки? :-)

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

А в чём проблем взятия адреса от квадратной скобки? :-)

Ну возьми, если сможешь.

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

rust - запрещает то, что реально работает.

Спустя 2-3 недели копательства в std и статьям приходит просвещение: borrow-checker жить не мешает, а помогает, просто некоторые вещи принято делать иначе.

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

Кстати, откуда тянется эта привычка писать в с89 стиле?

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

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

:(

Ну простите, что я мануалы не приложил и «--help» не обработал.

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

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

Простите великодушно :-) Но зачем же писать функции с полутора десятками локальных переменных? :-) Неужели нельзя написать N функций c 15/N переменных на каждую в среднем? :-)

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

Но зачем же писать функции с полутора десятками локальных переменных

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

Неужели нельзя написать N функций c 15/N переменных на каждую в среднем

Одноразовые короткие функции ради функций тоже бьют по читаемости кода.

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

отследить число локальных переменных становится существенно сложнее.

А зачем его отслеживать? :-)

Одноразовые короткие функции ради функций тоже бьют по читаемости кода.

Это смотря как функции называть :-) Как говорится: «как корабль назовёшь...» :-)

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

А зачем его отслеживать?

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

Это смотря как функции называть

Да как ни назови.

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

Один из звоночков на разбиение — большое число локальных переменных.

Ну об этом и речь, собственно :-)

Да как ни назови.

Хм :-) Лично мне прочитать count_of_red_items(x) легче чем какой-нибудь сферический for (; i < sz; i++) { if (items.color == red) count++; } :-)

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

Хм :-) Лично мне прочитать count_of_red_items(x) легче чем какой-нибудь сферический for (; i < sz; i++) { if (items.color == red) count++; } :-)

Комментарии к отдельным блокам кода читать еще легче. Впрочем согласен, что 15 локальных переменных в одной функции должны быть редким исключением.

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

Комментарии к отдельным блокам кода

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

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

Когда код говорит сам за себя, никакие комментарии не нужны

Код говорит, что делается, но не объясняет почему.

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

Код говорит, что делается, но не объясняет почему.

Объяснение всегда одно - потому что надо автору :-)

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

некоторые вещи принято делать иначе

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

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

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

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

Боже, царя храни... А с другой стороны, анархия - мать порядка... А с третьей - еще есть и демократия... :)

Анархия и есть прямая демократия.

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

которые я б легко вычистил бы сам с моим то опытом

В строю неадекватов пополнение.

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

Лол, криокамера подъехала. У каждого языка есть свои best practices, совершенно отличные от других. Я же не про принципиально новые паттерны проектирования говорю, ну.

mersinvald ★★★★★
()

Тема закрыта :-)

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