- 1
- 2
- 3
- 4
- 5
- 6
std::vector<int> data;
// ...
for (int i = 0; i < data.size(); ++i) {
int item = data.begin()[i];
// ...
}-
C++ / Говнокод #12638
+33
Запостил:
Cpp,
22 Февраля 2013
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
это старое сишное "правило": a[b] == b[a] == *(a + b).
и RandomAccessIterator, к которым относится итератор вектора, поддерживают арифметику - подобно старой доброй арифметике указателей.
Ещё раз повторюсь: Итератор не обязан быть указателем.
Ещё раз повторюсь: синтетическим подсластителям это по барабану. Указатель не указатель - это уже семантика.
не работает на GCC (ни begin()[i] ни i[begin()]) это скорее всего потому что они скорее всего старые Сшные хаки на объекты не распростаняют. что как бы и логично.
но на каких коммерческих/древних компиляторах меня не сильно удивит если это будет компилироватся и работать.
как это? http://liveworkspace.org/code/2uCj4s$0
Все дело в random access итераторе. У него есть оператор []
Ну то есть после перегрузки операторов operator+ и operator[] - принципиально уже две разные сущности
http://liveworkspace.org/code/code/2JOia2$11
Это требование стандарта (Секция 24.1.5 в редакции 2003 года)
Вы можете сказать, что только лох не умеет переберать стлконтейнеры? Да, это так, но.
Вся эта мура с прятаньем указателей, вся эта байда с тысичями методов для индексации и т.п. Просто не помогает, а мешает. Когда-то неосиляторы сказали, что "указатели ненужны, они не безопасны и ваще говно нечитаемое". Поколение книгагрызов, высошее на одной книжке и у их потомков уже в генах подсознательная нанависть и боязнь указателей.
Если добавить к этому ООП говного мозга у 95% приплюснутых да и тот факт, что сейчас "программирование" как таковое на дне морском, то блин у этих новоявленных плюсовиков(да он идиот, но не это главное) просто ступор в башке.
Ну что бы вы мне говорили - я не верю, что без прямого досконального понимания указателей и указательное магии пациент сможет нормально юзать стл. Так и будут массивы перебирать фором со счетчиком, как в детсаде( а 95% плюсовиков, да и сишников так делают).
Поэтому, ясчитаю, что любой приплюснутый должен вначале осилить сишку на уровне "указатель и я" - брат за брата за основу взято, либо идти в жабисты, пхпписты, сишарперы и иную тину болотную. И тогда, даже самый тупые бездари и немощи такие перлы не напишут. И да, стл - говно.
Про copy для массива и связного списка. Что такое кольцевые списки ты конечно же не знаешь, и что copy_ll(head, head) писать быстрее, чем твою stl-байду, ты тоже не осилил, а уж про memcpy и вариации я тебе и говорить не буду.
Просто ты живёшь в мире кубиков, сделаных для тебя дядей страуструпом, при этом ничего не зная о Си-мире. Твоё мышление ограничего кубиками - вот сиди и играйся.
Шире надо смотреть шире, а незашориваться системным Си (я кстати на нем в основном и пишу)
Работают на уровне кубиком только рабсила, а инженер работает на уровне материала. Хотя сейчас и инжинеры пытаются работать на уровне кубиков, как и "программисты". Я думаю не надо тебе рассказывать, что из этого вышло?
Понимаешь такую штуку, бетон как материал меня в форме не ограничивает, а вот готовая бетонная плита ещё как. В данном случае материал - сиасм, но ты же о5 сливаешь на какое-то мистическое "системное Си". Прикладухи пишется не меньше.
Кроссплатформа? Не, не слышал. С радостью посмотрел бы на виндекапец, но пока жива винда - увы, придется думать о кроссплатформе.
> а инженер работает на уровне материала.
Ну зачем же так толсто? Инженер, вместо того чтобы применить в проекте стандартный винт М5х12 должен каждый раз разрабатывать его конструкцию с нуля, на уровне материала?
а бухгалтер работает по другой линии — по линии библиотекаря.
Сишники не осилили, к примеру, реализовать возможность написать функцию, которая компирует элементы из произвольного контейнера в другой произвольный, требуя от контейнеров лишь семантики указателей. Мне бы очень хотелось посмотреть, как memcpy осилит скопировать массив в связный список.
Не то, чтобы это была большая проблема для С, препроцессор и пара хаков с адресами, а также пара десятков великов всегда делали своё дело.
А Posix-API мне сложно назвать изящным API, ибо он наполовину состоит хлама, провоцирующего race-conditions без нужды.
Как я уже говорил. Мешают массивы и связные списки только неосиляторы и бездари. Списки в 99% случаев не нужны, ибо их реализации на маллоке - тормазное говнище( а уж приплюснутые их реализации только в прикладухе и живут).
Это не хаки и препроцессор - это не хак. Это изяшное средство ЯП. Для меня твой стал и шаблоны - хаки, ты же с эитм не согласен? Ну и да, как я уже писал выше - это не нужно.
Суть не в том, что что-то плохо, а суть в том, что лучше нету. А если есть, то это узкаспециализировано( и это круто), либо студподелка на бумажке, которая лучше только на бумажке, а не в реальном мире( это ООП стайл, ибо ООП на 95% состоит из теорий, мистификаций и непонимания).
Рабство совместимость - это бич, но в мире говнорей и бездарей от этого никуда не деться.
Кубики, о которых идёт речь, были разработаны в основном дядей-учителем-математики Степановым не без помощи тёти-студентки Ли, правда, много других дядей из американских телефонных и не очень компаний тоже помогали.
Никогда не мог удержаться, когда так просят.
Любой интсрумент можно использовать через жопу. Хороший инструмент отличается от плохого тем, что плохой иначе как через жопу и не использовать.
И при всем моем настороженном отношении к сям (любым), я сомневаюсь что они попадают под это определение.
>идти в жабисты, пхпписты, сишарперы и иную тину болотную
илита такая илита.
Для тебя, детсадовца, что-то сложнее, чем положить кубик на кубик - это через жопу. Хорошее оправдание. Ах какой несправедливый нижний уровень, что там всё через жопу, а мой "нечерезжопный" ООП-мирок, реализован через жопу. Ты не чувствуешь тут лёгкий запах деления на ноль?
Понимаешь в чем дело. Есть 2 типа ЯП, как 2 типа мышления - это ограниченый(плоское мышление) во все сторы ЯП( это как молоток, который работает только "от себя" аргументируя это тем, что "можно ударить себя в рыло". Только вот такого молотка хватит только на гвоздь в стену, а пряморукий человек себе и обычным молотком в рожу не попадёт).
Это как щас модно - зачем мне что-то знать о мире, об обществе и т.п. Я живу в своём мире( дом, друзья-идиоты, дорога до офиса->работа за еду->дорога домой->первый канал(соцветь, игрулечка, говнокодик потроллить)) - мне всё ок.
Так же и тут - у меня есть жава, GC и индексы - нахрен мне что-то? Для деревенского интерпрайза хватит, раб Сишник мне напишет jvm, OS, и всё низкоуровневую байду, а я илита - я строю нахрен интерпрайзЪ, "хайлоад", ваще труЪ пацан - создаю труЪ системы.
Я до сих пор верю в алгоритмическую оптимизацию( мне так дядя в школе говорил). И черезжопность Си. Верую, вера единственное, что вас держит на плаву.
http://bfolder.ru/_ph/50/2/494769787.jpg
А окружающие просто не осилили такой мощный функциональный язык K&R Си.
Т.е. аргументов по существу нету? Так и запишем.
>Ах какой несправедливый нижний уровень, что там всё через жопу
Сдается мне, тебе приглючилось что я наехал на священную корову си.
Попробуй для разнообразия читать ответы твоих оппонентов.
>Только вот такого молотка хватит только на гвоздь в стену
<КО>Разные ЯП - это разные инструменты, которые подходят для различного списка задач.</КО>
Причем в число критериев выбора входит и такой милый показатель как скорость и стоимость разработки.
Никто не спорит что программа, написанная на сях может при прочих равных работать быстрее чем на более абстрагированном ЯП. Цена этого - необходимость держать в голове гораздо больше посторонних фактов, что напрямую влияет на скорость (=стоимость) разработки. Приемлемая программа сейчас и хорошая через полгода - это лучше, чем идеальная, но только через год.
Дьявол, как обычно, в мелочах: абстрагированность инструмента не освобождает от необходимости думать головой как при его выборе, так и при использовании.
Незначительная потеря производительности из-за еще одного уровня абстракции - это невеликая цена за то, что программой можно пользоваться для решения поставленных задач на полгода раньше и сразу на нескольких платформах.
Но если кто-то раздувает вычислительную сложность на пустом месте (при условии что проект уже вышел из стадии прототипа) - то хоть на асме пиши, это не оправдывает. И, кстати, умение писать на ассемблере не означает умения не писать на нем хуйню.
А там где потеря производительности из-за абстракций критична или где нужна максимальная предсказуемость кода (читай - делать все самому) - вот там для низкоуровнего си раздолье.
Нужно просто (хотя вообще-то это не так просто) думать, что делаешь. Всегда. А ЯП тут не причем.
P.S.: Прозреваю ответ типа "ололо идиотина", ну да что ж поделаешь.
О5 жалкие опрадания. Чуть быстрее - это тебе рассказал сосед по парте? Давай я тебе расскажу о реальным цифра - это порядки, причем десятичные.
Нет, дешевость разработки на ООПЯП с низким порогов хождения - это не их скорость разработки, а дешивезна программистов как таковых( они дешевые как грязь) + переизбыток рынка, а переизбыток предложения дают спросу производить выгодные манипуляции, давай я тебе поясню:
Есть контора А и контора Б. В первой конторе есть 3 сишника по допустим 10к$, которые выполняют ту же задачу, что 1сишник за 10к$ и 5-10макак за 1-2к$. Теперь давай посчитаем, нам нужно выкатить программу цикл разработки которой 3-5месяцев. После этого её надо поддерживать, а выкатывать что-то принципиально новое нам не надо ещё год-два.
Разработка конторам обошласть( допустим) в одинаковую сумму. В конторе А код прекрасен и нуждается в минимуме усилий для сопровождения. В конторе 2 говно и нужно дохрена усилий( 2-3тела в фултайме). Казалось бы всё круто? Но, как ты оворил - детали.
Сишников мало и уволив одного - ты его хрен найдёшь, ибо они либо хомядячие динозавры, либо вымирли уже. Т.е. смишника уволить никак нельзя, ибо спроса больше, а предложения мало. Стоимость штата для конторы А 30к$.
Сколько стоит штак конторы Б? 13-16к$, правильно. Почему? Потомучто в штате остаётся Сишник и 1-3тела для клепания говнокода. Остальных можно уволить не боясь, ибо они год тебе не понадобятся, а понадобятся - на следующий день прибежит к тебе голодных жабистов.
Выгода? Выгода. Но зачем об этом знать? Лучше верить в быстроту разработки.
Я твой дом труба шатал. Совсем из ума человек выжил.
Вот что си животворящий делает!
Это как брать среднестатистического гентушнего и вантузятника, вроде разницы нет? Но она есть. Так же и тут. Среднестатистический сишник, а особенно высококлассный скилованней не потому, что иные тупые, а его жизнь заставила. Так же и гентушнек скилованней не потому, что венда говно, а потому, что а) их мало. б) жизнь заставила.
Твоя логика на дне морском, спорить только с соседями по парте тебе надо.
Ты выбери что-то одно, потому что высококлассный - это не среднестатистический. Сишники не боги, и тоже подчиняются нормальному распределению.
>соседями по парте
Рыбак рыбака?
А макаки, типа "я программист, а не админ", "я программист, а не електрик" - этих надо в утиль. Любой более-менее нормальный низкоуровневый специалист( специалист, не тот который дипломированный, а реальный) минимум средний електронщик, админ, знаем и понимает устройство ОС на которой работает и устройство железа с которым работает. Это основы.
Понимаешь, ты не замечаешь причинноследственной связи. Сишник для написание чего-то сложнее калькулятара должен минимально понимать архитекстуру, а вот писать истерпрайз на жаве - может любая домохозяйка. Это ВИНА НЕ ЯП, А ЕГО ЦА И КОНТЕНГЕНТА. Это надо понимать.
Производительность теряется не из-за абстракций. Производительность - это на 95% использование особенностей железа и на 5% алгоритм. Абстракции изначальные слабые умы вообще отучают от низкого уровня и производительность падает, причем падает на порядки. Они начинают верить в О-натацию, сравнивают что быстрее список или вектор и т.п.
ЯП тут какразтаки притом, что ЯП не должен ограничивать тебя в реализации. Хочу переполнение и безнаковые типы в жаве, причем не эмуляцией. С полными св-вами низов. Нельзя? В том и суть.
Вы так говорите, как будто так делать не надо. В очень многих местах правильно выбранный под задачу контейнер/алгоритм даст выигрыш в производительности гораздо больший чем байтоебства, отличное знание железа, но наивный или не эффективный в данной ситуации алгоритм.
Другое дело что алгоритм с лучшим О работает быстрее алгоритма с худшим О не сразу, а после определенного N, и для некоторых алгоритмов это N достаточно большое... И если в нашей задаче типичные значения n намного ниже этого порогового числа - есть смысл позадрачивать реализацию с худшим О, иначе - однозначно взять алгоритм с лучшим О, и не париться с микрооптимизациями.
Про контейнеры. В 90% задач банального malloc(100500*100500) хватит и всяких фичей векторов/списков там не надо. Это будет понятней, проще, и минимум раза в 2быстрее.
Использование malloc()-стайл аллокаторов убивает весь профит от связного списка. И именно этот факт делает бесполезных все цикл-стайл тестирование контейнеров. Добавте к этом юзанье кучи каждый чих( какэ то можно в ООП и в плюсах в частности).
Всё это превращает елементы списка не соседями по офсету, а соседями по страницам, что печально. А ещё пичально то, что в ООП-стайле модно юзать 2больших объекта в куче. Поэтому в бенчмарке вектор мог влезть в тлб, а в реальной жизни нет - привет фейл.
Поэтому в реальном мире рулит только минимальная узкаспециализированая реализация для хранения одного типа данных, со своим пулом и зарание выделеным адресным пространством.
ой, прости, Тарас
"проще говоря, STL - результат бактериальной инфекции" (с) Stepanov
Вот, ещё одна вещь. Правильно, только вот для того, чтобы понимать примерное время исполнения реализации с лучшим О и также понимать время на одно n в худжем - надо знать микрооптимизацию, надо знать низы.
И вот к чему мы пришли: Для человека, который не знает низы, не разбирается в микрооптимизации, не знает свою архитектуру, ОС, конпелятор(вм, интерпритотор, etc) О-натация абсалютно бесполезна и будет сродни русской рулетке, ибо будет работать как повезёт.
А вот человеку который разбирается - ему не нужна О-нотация, ибо он примерно понимает как будет работать хорошая реализация одного "алгоритма" и как будет работать реализация второго. И он просто выберет самую лучшую, простую, удобную для реализации вещь, при прочих равных.
пойду с бомжами поговорю
> 3 сишника по _допустим_ 10к$
А реальные цифры где?
> 95% использование особенностей железа
Особенности железа умеет использовать JVM и без меня. А вот какие особенности вы собрались использовать в Amazon EC2 - для меня загадка. Ну и опять же - где доказательство _реальности_ этих самых 95%?
>Особенности железа умеет использовать JVM и без меня.
Не смеши мои тапки, пожалуйста. Про особенности ты сам загуглишь, да и не нужно это говни никому.
>Ну и опять же - где доказательство _реальности_ этих самых 95%?
Берёшь любую числодробилку жадную до памяти - реализует её на жаве, сравниваешь скорость - наберёшь хотябы 50% - я тебя похвалю. Хотябы 5 набери.
И не забывай, что овер 50% работы будет делать jvm, которая написана так, как я гвоорил выше, а именно не криволапыми макаками. Попробуй реализовать её вообще без дерганья готового( как это сделанно там, что ты будешь реализовывать). Ты даже и 5% не наберёшь.
Бенчмарки уровня *=2 в цикле ты соседу по парте будешь показывать. Ты да, пиши реальную числодробилку жадную до памяти и хотябы 50% производительности сиасма, я уж не говорю о 70%.
Да что говорить, даже сишка сливает сиасму вплоть до порядков. А уж жава. Срочно в школу.
он в любом месте говно.
А вот так говорить не надо. Оставьте такие "аргументы" для школоты. Хороший код, равно как и говно, есть абсолютно на любом языке.
Тесты в студию
А связка си-асм нормально работает только в гцц. Во всех остальных компиляторах (ну насчет icc не в курсе) асмовставка это инородное тело, которое мешает компилятору оптимизировать код вокруг нее, и, если она маленькая, потери могут стать выше чем профит от вставки... А переписывать на асме большие куски вместе с циклами - привет радостям поддержки.
Твое байтоебство позволят выиграть в лучшем случае 10-15% за счет ухудшения читабельности, стабильности и поддержки. Сравни затраты на работу программистов и на новый комп.
С моей точки зрения - это как лечить симптомы болезни таблетками. Почему бы, к примеру, не разнести статистику по разным потокам и мёржить её по запросу? Да и содержимое кэша бы зазря не пропадало.
Вот вроде люди "знают низы", но вместо того, чтобы придумать высокоуровневый метод решения проблемы, ищут хаки...
Поправьте меня, если я не прав.
Там треды поди почти не выполняют полезной работы между инкрементами этого счетчика?
Как вариант - мелкие тики считать в локальной переменной, а после выполнения достаточно большого куска полезной работы - прибавить результат к главному счетчику. Маловероятно, что нужна именно реалтайм статистика.
32 бита рядом - 2.4нс
32 бита разнесены - 2.3нс
64 бита рядом - 6.2нс
64 бита разнесены - 2.7нс
Для атомарного __sync_fetch_and_add (гцц компилит их в lock add и cmpxchg8b соотвественно):
32 бита рядом - 32нс
32 бита разнесены - 7нс
64 бита рядом - 42нс
64 бита разнесены - 16нс
Если полезная работа между инкрементами счетчика идет дольше 1мкс - на интерференцию явно можно забить т.к. даже в атомарных инкрементах 64 битного числа выигрыш от разнесения будет в пределах 3%.
Здравствуйте o2n3e, я хочу сыграть с вами в игру...
Придумайте небольшую memory-intensive задачку, которую можно реализовать за час - пару часов и выложите ее условие, к примеру, отдельным ГК. Вы реализуете ее на сиасме, я же займу сторону джавистов, и попробую реализовать ее на жабе.
P.S. Т.к. комп у меня не особо новый, а покупать подходящее железо и ставить операционки мне очень влом, желательно чтобы программа работала на i686 линухе и укладывалась в гиг памяти и минут 5-10 процессорного времени. Мультитрединг не запрещается. Компилятор, по возможности, gcc или clang.
Challenge accepted?
Зассал.
А вдруг пишет пример?
http://films.imhonet.ru/element/194852/
ахахаха, такой большой, а в сказки веришь
Опять и снова: читаем ответы оппонентов, а не додумываем. Я такого не писал.
>Человек с прекрасным знанием и пониманием
>Сишник для написание чего-то сложнее калькулятара должен минимально понимать архитекстуру
Понижение планки вхождения, имхо, есть не что иное как побочный эффект от повышения уровня абстрагирования от деталей реализации. Я что-то очень сомневаюсь, что большинство тех, кто действительно разработал свой инструментарий, делали его с мыслью "чтобы осилил даже имбецил". Делали программисты для программистов, чтобы можно было меньше думать о реализации и больше о задаче, просто результатом оказались способны пользоваться и люди без соответствующего образования.
Кстати, очень занятная аналогия получается. Похожие аргументы высказывались когдв Генри Форд налаживал конвейерное производство, успешно заменив нескольких профи массой низкоквалифицированной рабочей силы. И таки пришел к успеху. Так же и тут, вместо единичных шедевров ручной работы, которые остаются предметом роскоши - массовое производство пусть посредственных, но доступных каждому вещей.
Неправда. Это просто зуд, желание впихнуть максимум байтоптимизаций во все что можно. Тогда как это просто не нужно в большинстве случаев. Не окупится.
Не говоря уже о том, что привязка к особенностям платформы вообще и железа в частности делает код непортируемым. А если хочешь портируемости - изволь либо поддерживать зоопарк нижележащих платформ сам, либо абстрагироваться от них и предоставить это разработчикам
промежуточной плафтормы.
Выбор правильного представления данных (причем представления на уровне "дерево против хэш-таблицы", а не "слово против байта") плюс алгоритма их обработки (если представление типовое или сводится к таковому) решает гораздо больше, и для него отнюдь не всегда нужно знать особенности платформы.
>Это ВИНА НЕ ЯП, А ЕГО ЦА И КОНТЕНГЕНТА.
Ну хоть в чем-то мы согласны. Фигня начинается когда задачу пытаются решить не тем инструментом.
>ЯП не должен ограничивать тебя в реализации
Единственный язык абсолютно без ограничений в реализации - ассемблер. Точка.
Все остальные абстрагируют тебя от деталей реализации ценой утраты этих самых деталей - или непосредственно на уровне языка, как питон/ява, или на уровне библиотек, как Си/плюсы. Механизмы "падения" на нижний уровень нередко есть (асмовставки в си и паскале, сишные модули в питоне) но это костыли по сути своей, и писать только через них бессмысленно. Проще сразу взять ЯП с нужным уровнем абстракции.
Попытка же создать язык, работающий на многих уровнях абстракции, весьма рискованна, так как в итоге может получиться химера, не дающая ни скорости и предсказуемости на низком уровне, ни удобства и безопасности на высоком.
Хуечка. Асемблер может не уметь какие-то новые мнемоники, и придется использовать машинные коды напрямую
>ограниченый
>електрик
>електронщик
>калькулятара
>натацию
>какразтаки
Вера в киоске работает продавщицей.
std::next используй.
Потому в с++11 без сомнений добавили std::next
http://liveworkspace.org/code/241HdL$0
http://liveworkspace.org/code/241HdL$1
удивлен, что в libstdс++ решили эту проблему вот так элегантно
хотя чему тут удивляться, у них size() для std::list операция O(n)
Это не я. Это всё она, бес попутал - функция std::next!
А вообще хуле спорить.
С говно
С++ говно
Паскаль рулез
А где его фич будет не хватать (очень редко), там можно написать удобную для себя надстройку, работающую через трансляцию в цланг.
передний привод - говно;
задний привод - говно;
полный привод - полное говно.
Комп говно
Мозг рулез
А где его скорости будет не хватать, выведем ментатов.
>С++ говно
>Паскаль рулез
Minus. Потому что жыр залл мне пол клаватуры и чать клавш не работает.
Всё пропустил, всё проспал...
дрына.рф
дрючить.рф
дрючиться.рф
дрючка.рф
дуплиться.рф
дуроёб.рф
ебака.рф
ебало.рф
ебальник.рф
ебальныегода.рф
ебальныйстанок.рф
ебанатик.рф
ебанашка.рф
ебанутый.рф
ебануть.рф
ебануться.рф
ебаришко.рф
ебатория.рф
ебать.рф
ебаться.рф
ебачь.рф
ебельница.рф
ебёнамать.рф
ебёнть.рф
ебивашумать.рф
ебистика.рф
ебистос.рф
ебись.рф
ебитвашу.рф
ебитесь.рф
ебитскаясила.рф
ебическаясила.рф
еблематика.рф
ебле.рф
ебливщина.рф
ебливый.рф
ебломщелкать.рф
ебло.рф
еблысь.рф
ебля.рф
еблясперископом.рф
ебляс
https://i.postimg.cc/KjB7CYdr/image.png *
Чото понимает. Но в сложной питушне может и заппутаться, ведь ты же знаешь, что https://rtraba.files.wordpress.com/2015/05/cppturing.pdf
*Errata: не str, а int конечно: там спецификация шаблона