В аналогах std::tuple во всех известных языках просто применяется хеш для ВСЕХ типов
Да, а еще там кортежи только для чтения. Если тебе надо смирительная рубашка и неэффективная реализация по умолчанию - действительно есть «все другие языки». А в С++ надо понимать, что и где вычисляется и на что влияет.
но tuple/pair - очень очевидные кандидаты.
А еще можно все методы виртуальными сделать. Хуже не будет. Наоборот, ошибок меньше станет. Но почему-то не делают.
Programming languages have a lot in common with religions. You can spend your life searching for the «one true» way, and either find enlightenment, or discover you were worshipping false idols.
Ну он прав если добавить «Programming languages have a lot in common with religions for many people
Смотря на ЛОР - нельзя на согласиться. На меня в этом треде напали в контексте моей критики С++ сделаной в контекста „хаха, вот тут небольшой недостаток“, который восприняли за нападение на святую мудрость великих творцов С++, которые если что-то делают, то это догма, остальное - ересь.
Пф. Еще один все понял. Наверно из веба пришел. 2500 строк он на C++ написал. Вот пришел бы в проект с хотябы 25000 строками на плюсах, на следующий день написал бы подобную статью про java.
А потом еще побегает по разным сферам, dev ops, анализ данных, фронтенд, gamedev, AI, embedded. И вот тогда однажды утром он таки познает дзен и не будет писать зашкварных статей «я наконец-то нашел лучший язык программирования в мире»
Строки тоже не только для чтения, почему для них определен hash?
Потому-что это специализированный тип, где все явно и однозначно. А когда ты задаешь tuple, ты создаешь новый тип. И там только ты можешь знать, что там надо хешировать, что не надо, и если надо то как. Попытка сделать универсальную реализацию и приводит к костылям вроде R/O кортежей, чтоб у пользователи мозги не закипели от необходимости понимания реализации базовых контейнеров.
2.5K строк на современном C++ — это нифига не хеловорлд. А если он там еще и какую-нибудь стороннюю либу заюзал по полной программе, то сильно далеко не хеловорлд.
«Я писал на С. Попробовал на С++ и ошибок было меньше. Еще попробовал Rust, Go, Swift, как-то не пошло. Если вы еще не попробовали С++ с фишками новых С++11, то рекомендую. Всем хорошего дня»
Не читал вашу дискуссию, но если речь о том, как сделать все грамотно с закрытием, то open_self может быть шаблонным и возвращать R и принимать на вход лямбду ()->R
Я о потенциальном варианте реализации на С++. Ну «извращение» - это лишь слова. Я бы волновался невозможностью move по нормальному внутрь лямбды. Это кажись прокол стандарта.
Что, извините? Я привел простое и безопасное решение на С++, это не мне нужен костыль with-open-file. И не мне надо изобретать способ заставить его работать аналогично показанному мной примеру.
Я бы волновался невозможностью move по нормальному внутрь лямбды. Это кажись прокол стандарта.
Не вопрос, тогда можно не включать и С++11, и проблемы не станет, ведь в С++03 лямбд и семантики перемещения не было. А если вопрос в поддержке компиляторами, то как минимум gcc, clang, msvc уже реализовали данную возможность из С++14.
Если был std::cow_vector рядом где-то, то он бы никому не мешал.
Да, но стандартная библиотека не может вместить всё на свете. Конкретно эта штука мне кажется далеко не самой необходимой вещью. Опять же, что мешает использовать сторонние библиотеки? В общем, это явно не проблема языка.
As a language, C is close to perfect. It is portable assembly, no more, no less. The grammar is consistent, easy to understand, and generally unsurprising.
Это же тролль :| 4.2 по всем пунктам.
I currently work at Google. I have no idea what I'm doing.
господи, какие только костыли не изобретут в питоне, лишь бы не использовать деструкторы
В питоне есть метод __del__, но во-первых из него во всю торчат уши реализации, а во-вторых он вызывается «когда-нибудь потом, а может и никогда». Собс-но это проблема всех языков с GC - Java, C#, CL, Python и т.д.
Ну почему сразу тролль. Может быть он в это искренне верит.
if you're like me and you've been ignoring C++ due to distrations from all kinds of shinier things such as Go, Rust, and Swift, I encourage you to take another look
Это называется «у хипсторов появился новый идол».
Ну или как описал Кэрролл такую ситуацию:
«– Мне нужна чистая чашка, – перебил ее Болванщик. – Давайте подвинемся»
Ну чо, пора. Где-то с периодом в 2-3 года это происходит.
А теперь запусти свой тест с нормальным malloc из tcmalloc, jemalloc, TBB malloc или чуть более экзотичных.
Другой вариант, использовать deque, если тебе не нужно, чтобы данные лежали непрерывным куском, как в сишном массиве. Там сразу потребность в realloc отпадет (и копирований никаких не будет).
В нормальном языке ANTLR не очень-то и нужен, можно использовать парсинг-комбинаторы (например, FastParse в скале) с типо-безопасностью, автодополнением в IDE и чем угодно. И не нужно раскочегаривать сторонний инструмент со всей связанной с ним негибкостью, или там мучаться с регэкспами, чтобы распарсить три строчки.
Я рекомендую посмотреть в сторону Scala. Там есть фреймфорк для метапрограммирования LMS, Lightweight Modular Staging. https://scala-lms.github.io/ Знаю, что на нем реализовывали генерацию ядер FFT, сравнимого по быстродействию с FFTW (Spiral).