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)

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

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

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

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

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

Чтобы анонимусы могли потроллить крестолюбов.

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

std::set<TPair> storage;

И у тебя появляется лишний O(log(n)) на вставку. Я не понимаю, оставить вектор и заменить указатели на индексы что, какирская гордость не позволяла? Ну, или дек заюзать.

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

У вектора при ресайзе указатели будут инвалидными, я в первой версии допустил эту ошибку. Ну а что бы избавиться O(log(n)) можно просто использовать std::unordered_set, там правда придется чуть повозиться. Один фиг у unordered_* структур указатели на ключи и данные валидны, всегда, а вот итераторы нет. А у обычных map/set и итераторы всегда валидны. В общем тут так-то пофиг, просто юзаешь unordered_set и дело с концом.

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

И получается ты должен постоянно таскать за собой вот эти твои «ToUpper/ToLower» независимо от необходимости их использования. Причем они должны корректно выполняться для всех языков и для всех символов. Ну для всяких там иероглифов будет возвращаться тоже самое. Хотя для некоторых новомодных эмодзи придется тоже реализовывать «ToUpper/ToLower». В данном случае гораздо экономней будет вынести «вот это вот все вот это» в отдельную микролибу и таскать ее с собой по мере необходимости что в крестах, что в божественной.

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

Хотя не, std::unordered_set не катит, там надо хэш функцию писать. ну тогда std::list и дело с концом.

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

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

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

У вектора при ресайзе указатели будут инвалидными

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

ну тогда std::list и дело с концом.

Тут, действительно, уж лучше list, чем set. Но deque - ещё лучше, меньше аллокаций и меньше всякого сопутствующего мусора.

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

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

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

Хотя есть одно но, std::set/unordered_set помогут дублей избежать. Но таки тогда да, надо юзать unordered_set и писать хэш-функцию.

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

Ну icu можно было бы и разбить на несколько либ. Приставка «микро» что я писал там неспроста. Но вообще получается что эти ваши шарпики и таскают с собой эти «шысят-с-чемто-метров» аналогичного кода (ведь разработчики icu не анекдотов туда положили). Такое же для времени/дат, ФС и прочего. Если ты пишешь комбайн в этом смысл есть. Если пишешь что-то простое - то лучше не тянуть тонны хлама.

А то с такими товарищами получаем установочные пакеты драйверов под оффтопик с требованиями к ДОТНЕТ-ПОСЛЕДНИЙ!!11, весом в сотни мегабайт и временем установки минут пятнадцать на последнем коре7 и SSD. Уныло как-то это все ...

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

Я больше писал про то, что не всякому софту нужная стдлиб со ВСЕМ-ВСЕМ-ВСЕМ-НА-СВЕТЕ и соответствующими требованиями.

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

А потом мне рассказывают, что пакетный менеджер не нужен...

Я хз почему icu идёт целиком, скорее всего из-за того, что в C/C++ работы с зависимости как таковой нет, поэтому приходится сооружать комбайны/фреймворки.

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

нононо, это уже критика кода на с++.

Нет, это критика «пихнем values в set, поэтому нам нужен operator< на values». <шепотом>А в list не судьба?</шепотом>

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

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

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

Toupper/ToLower, Contains, StartsWith,EndsWith, получения дня недели - это имхо как раз часто используемые фичи. Возможно если ты можешь вызововом методов/свойств получить день недели, дату, месяц, год, час и т.д., то ты вообще никогда не заглянешь в раздел манов с описанием printf подобного формата для получения этих данных.

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

list не судьба, хотя зависит от того на что ты готов забить. set/unordered_set позволяет избавиться от дублей, list - нет.

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

Ядро и его модули, системные библиотеки, библиотеки тяжелых вычислений, OpenGL...

Чево? Определение «мишон критикал» хоть знаешь? :) Ведро свое без RT-расширений (да и с ними) можешь себе в тухес засунуть — это не то, что используется хотя бы на истребителях :))). Да и библиотеки эти не софт — только кубики для него :) А OpenGL — ок. Используется где? В играх на плюсах :)) Библиотеки используются где? В прикладухе на плюсах. Круг замкнулся. И чо там с опупительным мегасофтом на цешке-то? :) Оси общего назначения для «бухгалтерий, дома и семьи», раньшие версии прикладухи (щас дураков нет) — ну и опупительно тижелые вычисления зарплаты и чорной кассы ( которые давно считают в жабке с дотнетом), супер-пупер быстрой выдачи страничек со скриптоговном и торговли в биржевом казино? В банках где-то все еще COBOL пашет, где-то дропнули и переписали... не на ц. ОМГ, вершина прогресса — «оси общего назначения и библиотеки» :) Но мегасофта чот не видно, которым тут ты размахивал до этого — алсо для тижолых вычислений еще был фортран :)

anonymous
()

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

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

У нормальной амоотизировано 1, если использовать совершенный хэшинг то 1 будет всегда. (Условие - знать размер таблицы заранее).

invy ★★★★★
()

Прочитал пост афтара. Сам являюсь крестоёбом уже лет 10. Но почему-то пост не задёл, не возбудил, возмущения не почувствовал — пост на 100% из каких-то боянов и шаблонов мышления.

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

Вангую потопление этого адекватного комментария в гуру-споре @ссылка vs указатель@.

Нет, unique_ptr<T> vs T* круче :-) И ничего, что всё равно надо реализовывать деструкторы, конструкторы и операторы копирования, если его использовать в pimpl :-) Зато модно ведь, и гуру велят delete не писать :-)

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

у hashmap o(1) конечно. особенно учитывая, что начиная с 8 элементов внутри букета они начинают храниться в дереве. нужно прям очень сильно постараться, чтобы зафакапить

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

RazrFalcon, если когда-нибудь пойдешь устраиваться на работу кодописателем, ни в коем случае не заикайся про хеш-таблицы и O(n).

в прошлом году на одном из собеседований меня вышвырнули за то, что я сказал про о(1). Могу даже сказать, кто это был: тимлид команды в Новосибирском Акакдемгородке, фамилия Новоселов, компания БАРС Груп. Какой ужасный позор.

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

в прошлом году на одном из собеседований меня вышвырнули за то, что я сказал про о(1)

Дурачок, все зависит от контекста. Ты уверен, что спрашивали не про сложность получения i-го элемента из связанного списка?

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

https://en.wikipedia.org/wiki/Hash_table#Performance_analysis

Про лучшее/худшее время будешь говорить, когда попросят, а так специальный TLDR на странице есть: http://imgur.com/a/wtpup

Еще бы про квадратичную сложность quicksort-а завернул.

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

«Всегда/не всегда» - это рассуждения из анекдота про «какова вероятность встретить динозавра». Если делать правильный хэш, то количество худших случаев оцениваемо, и редкие тормоза от «худшего случая» амортизируются огромным количеством лучших случаев. Про амортизацию можешь почитать например, у Седжвика, книжка называется «алгоритмы на Java», есть Рутрекере. Там где-то в самом начале, где рассказывается о инженерном понимании О-нотации

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

В ход пошли крестоманевры.

Ага, вот как это называется, когда С-шные грабли обходишь: крестоманевры.

Я про это даже не заикался.

Ну да, это ж вы какую-то другую херню меряли. Я вам тогда еще пару ключиков подскажу: -static, -static-libgcc, -static-libstd++ и Co. Результаты впечатлят вашу поврежденную психику еще больше.

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

вопрос был конкретно про производительность класса HashMap. Даже ссылка на официальный javadoc класса HashMap (в котором написано про о(1)) не убедило этого придурка. Лучшие перфомансники и алгоритмисты Сана и Оракла в течение пятнадцати лет шлифовали перфоманс этого класса, написали на этом несколько научных работ, написали целую поэму в джавадоке, но вот приходит некто Новоселов и утверждает что вот он-то знает лучше. Только поэтому я и запомнил эту фамилию. Потом, когда я таки работал с ним в соседнем отделе, принципиально с ним не разговаривал - у меня аллергия на чушь

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

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

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

Ну тогда да. stdc++ не очень. Только не говорите eao197.

Для меня, в отличии от вас, маленький размер stdc++ не означает, что stdc++ говно.

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

Я вам тогда еще пару ключиков подскажу: -static, -static-libgcc, -static-libstd++

Ого, крестоманевры продолжаются.

Интересно, а что бы могла означать буква «s» в расширении «.so»? Superior? Sucking? А может быть shared? А если оно shared, то какая к черту разница? libc.so всегда в памяти. А вот размер крестового бинарника — это расплата за паталогическое ментальное крестослабоумие.

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

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

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

Да вы дебильнее

Сложно переплюнуть человека, который употребляет «вы» и «дебил» в одном предложении :D

Я вам даю еще один фактор для унижения C++, а вы отмахиваетесь.

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

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

Любая дока по hashtable об это говорит

да, только HashMap в джаве - это не хэш таблица в чистом виде. Во-первых, ты не можешь всем сущностям возвращать 42 в качестве хэшкода, и это написано в инструкции к HashMap. Даже если тебя не сожгли в печи за такие выкрутасы, HashMap обернет твой hashCode еще раз своей собственной функцией - защитой от мудака. Все элементы попавшие в один букет выстроятся не в список (как было когда-то в Java 7), а в красно-черное дерево.

и сортировочки там тоже не чистые. Стандартные коллекции сортируются алгоритмом Timsort - стабильной сортировкой со сложностью в лучшем и худшем случае nlogn (и лучшем n). Она работает так: вначале исходный массив делится на кусочки, потом отдельные кусочки сортируются вставками, а результат объединяется сортировкой слиянием. Но если элементов меньше 64, то с самого начала запускается сортировка вставками. (64 и прочие числа - магические, да). Т.е. если ты вдруг искренне верил, что там квиксорт в учебном варианте, то нет.

то что на самом деле - не всегда такое, как кажется) Верь официальной документации, она фигню не скажет (с)

/me, дико смеясь безумному совету, убегает в даль

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