Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,c++,языки программирования,без перевода,программирование,it humor,geek,C++,programming languages,programming
Еще на тему
it-юмор geek c++ языки программирования без перевода программирование
Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,c++,языки программирования,без перевода,программирование,it humor,geek,C++,programming languages,programming
Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,c++,языки программирования,без перевода,программирование,it humor,geek,C++,programming languages,programming
- модули в cmake до сих пор не довезли.
- Стандарты раз в 3 года делают (а могли бы каждый месяц-два)
- дрочат на обратную совместимость (а могли бы дрочить поменьше и заставлять почаще переписывать легаси - вот уж точно хуже бы не стало)
- Рефлексию довезут только в 23м. И pattern_matching возможно. А метаклассы тогда вообще хуй знает когда
- никто не горит желанием все переписать на модули (а пора бы)
- в стандартной библиотеке повсюду ужасный_снейк_кейс_нейминг который_уже_даже в_ключевые_слова_языка пробрался (но это лично моя вкусовщина).
- стандарт языка дорогой, нельзя просто взять и прочитать (несколько килодолларов вроде)
- 21 способ инициализации переменной - это пожалуй слишком много
Считаю что с++ отличный язык для работы (ненавижу его уже 10 лет и не собираюсь останавливаться).
Стандарты менять так часто, как ты предлогаешь, это будет геморой.
И да, я понимаю что в Rust и Swift все проще потому что они ни с кем договариваться не должны. им вообще стандарт не особенно нужен, если там 1-2 компилятора и все. Просто выкати обновление компилятора и радуйся жизни. А стандарт плюсов еще же со всеми согласовать надо. я понимаю почему сейчас так сложно, для этого конечно есть объективные причины. Но от этого менее больно не становится.
Причём тут C++? Ты из тех кто считает что крестам нужен "менеджер пакетов", кек?
> дрочат на обратную совместимость
Потому что это серьёзная технология для системной разработки, а не хипсторские однодневки. Это в ёбаном JS жизненный цикл фреймворка полтора года, а кресты -- всерьёз и надолго.
> Рефлексию довезут только в 23м
Нахой она не нужна потому что. Деманглинг системными средствами и коллбеки. Для остального есть JIT.
> никто не горит желанием все переписать на модули (а пора бы)
Нет, не пора, и никогда не будет. Модули может и нужны в отдельных случаях, но разделение на декларацию и реализацию (а так же прекомпилирование заголовков) -- отличная штука для больших проектов.
> повсюду ужасный_снейк_кейс_нейминг
Именно что вкусовщина. Поработаешь ещё лет десять и будет вообще похуй.
А вообще, да - считаю что крестам нужен менеджер пакетов (conan уже неплохо справляется)
2) ах, как я люблю это надуманное противопоставление серьезные мужики - хипстеры недокодеры. А главное что оно благополучно скрыло смысл того что же ты хотел сказать...
Вот по твоему, с++ должен обновляться раз в: месяц/пол года/год/3 года/5 лет/10 лет/поколение/никогда, ибо уже достиг совершенства? то что он всерьез и надолго не значит, что он не должен меняться.
3) тебе не нужна, а вот тем кто интегрирует плюсы с другими языками - нужна. и тем кто хочет существенно расширить compile time вычисления - тоже. мир большой, задачи у всех разные.
4) стандартную библиотеку начнут переводить на модули (так что мне не понятен аргумент про "и никогда не будет"). Модули нужны практически везде, (время компиляции, удобство для систем сборки, уменьшение боли с odr). Модули вполне себе поддерживают разделение на декларацию и реализацию, но с другой стороны позволяют писать и без этого. Ведь по сути это разделение нужно практически в одном единственном месте - в интерфейсе выставляемом наружу из библиотеки.
5) про вкусовщину не вижу смысла спорить. хотя если есть хорошее исследование сравнения читаемости кода - я бы поглядел.
2) Менять не всегда значит сделать лучше. Менять - наделать новых ошибок?
3) Задачи разные - по этому под другие задачи нужно брать не С++
4) Что за модули вообще? Чем разделение по разным lib или dll не нравится?
Эти что ли?
Только страничка с вики как будто устаревшая. там скорее всего посвежее есть, если порыться
А к чему сожаления про одну из систем сборки?
> как я люблю это надуманное противопоставление
Just kidding, конечно. Но, вообще, новые стандарты вон меняют язык, и вполне хорошо. Тут трейдоф-то простой: или ебошим каждый день новые концепции, или тщательно подбираем то что не отменяет достигнутых преимуществ. Соотношения качества, стоимости и количества наебать-то можно, но только делается это чем-то действительно стоящим, чего нельзя взять и потребовать потому что хочется.
> вот тем кто интегрирует плюсы с другими языками - нужна
Для этой интеграции есть SWIG и хуева гора надстроек которые никто не хочет учить, пока не прижмёт. Мир большой и все хотят испортить хорошую технологию потому что всякий думает что то что нужнее именно ему -- прям вот ебанись как полезно и нужно. У крестов есть конкретная (неузкая такая, да?) ниша, в которой они сидят: уровень чуть повыше асма, без накладухи на сборку мусора, интроспекцию и рефлексию. Полноценной рефлексии без накладных не будет, а для неполноценной -- JIT и шланговый парсер в помощь (может быть его лучше допилить чем стек насиловать?). Большая часть других языков имеют если не сам вообще Си под капотом, то отличные биндинги которые скриптятся наотличненько.
> разделение нужно практически в одном единственном месте
Нихера ж себе "единственное место" -- да любой проект мало-мальски оптимизированный под сборку содержит тонны одних только forward-деклараций, а архитектура естественным образом распадается на элементы зачастую даже в рамках одной библиотеки.
В чём вообще бенефит модулей? ODR, как и любой принцип -- скорее рекомендация, чем веление строгой необходимости, тем более его целиком и полностью контролирует любой компилятор.
- согласен, стандарты плюсов довольно сложная (и много где хорошая) вешчь, чтобы просто так взять и вписать в нее что-то сильно новое и при этом ничего не поломать. Действительно - комитет не на пустом месте так много над новыми фичами думает - там есть над чем подумать. Но с другой стороны, вот те же метаклассы из-за этой тактики придется ждать по меньшей мере до 26го видимо. И что-то здесь все же не так: я ж хочу эту радость при своей жизни поюзать, а не внукам подарить) и желательно в боевом проекте а не в фича-ветке популярного компилятора.
- про SWIG - я и сам из той кучи, которая не хочет его учить) Совершенно согласен, что рефлексия в плюсах не должна стоить в рантайме или вообще ничего или крайне мало.
- Ну дык с модулями как раз и не нужны будут все эти forward- декларации (если я правильно понимаю) там же явно прописываешь, что из модуля идет на экспорт, а что остается. Плюс насколько я помню хедеры в принципе в плюсах появились именно из за этого дурацкого механизма сборки через копирование. Если от него избавиться, то и разделение на h/cpp тоже будет не особенно нужно. Думаю даже в библиотеках можно будет без него обойтись и все сделать на модулях (но я чессказать не пробовал)
У каждого более-менее выстоявшегося языка есть некая своя внутренняя логика (ну, кроме JS). Которая в частностях выражается в наличии всяких "искусственных ограничений" вроде private/protected/public, const-validity и запрете на неявный даункаст, выведения конструктора копии, реализации ромбовидного наследования etc. etc. И то что классы -- не first class object, в общем, тоже некий важный элемент этой логики. Это не значит, что они не нужны, или не позволят что-то делать более эффективно, это значит, что нужно трижды подумать, прежде чем их добавлять, и подумать семь раз, прежде чем найти им лексическую форму. Темболие у нас есть специализация шаблонов и дивный мир SFINAE (кстати, когда язык приходит к таким обскурам, это, скорее всего, признак того что свой потенциал он исчерпывает).
На самом деле из-за модулей я и начал комментировать. Думал, ты, как их апологет, поделишься в полемическом задоре каким-нибудь лихим кейсом, который я не вижу своим зашоренным взглядом.
С тем что плюсы плохи в метапрограммировании - в целом согласен, шаблонный синтаксис, как и шаблоны в целом - больная тема. Но вот с тем что они довезли концепты, должно стать полегче.
вообще похоже что логика развития языка примерно следующая: сначала выкатываем минимально работающую фичу (шаблоны), потом смотрим как ее используют и наиболее частые фичи тоже закрепляем в языке (концепты). Логичный этап далее - выбросить устаревший подход или хотя бы обложить его warning-ами со всех сторон, но до этого пока не доходит.
Имхо, очевидно что до этого рано или поздно дойдет. Принципиальная сложность компиляторов ограничена сверху сложностью, с которой в состоянии справиться белковый мозг. так что потолок гарантированно есть, мы просто в него еще не уперлись (но явно пытаемся).
Кстати, например вот этим интересным предложением предлагается практически задепрекейтить move-семантику, передачу по ссылкам и подобное: и заменить это все 5ю декларативными конструкциями. и это чертовски хорошо выглядит, как по мне. я когда такое вижу, у меня аж клавиша & на клавиатуре перестает болеть. Кстати в этом же видео саттер высказывает вариант, как можно не ломая обратную совместимость, выделить из языка подмножество и использовать только его для новых проектов - всяко получше будет.
а в плане модулей - сорян. я написал пару-тройку hello-world-ов на них. выглядит очень хорошо, никаких include-shield-ов, никаких инклудов в принципе - только сборка немного странная. они неплохо поддерживают разделение на h/cpp но в большой проект у меня их затащить нет возможности именно из-за cmake(
веке?
Да и причем тут С++? Это вопросы к Микрософт, а не к С++
а я у себя ошибку 2 дня до этого искал)
Это финальные версии. Если ты не разработчик компилятора, то драфта достаточно с головой для любых кейсов. Если нужна какая-то конкретная версия — есть архив всех материалов, ну а для любителей опен-сорса исходники драфтов свободно публикуются на Гитхабе.
мне эта ситуация просто стратегически не нравится. Ну не должно быть так, что сообщество по черновикам восстанавливает что там в стандарте "на самом деле" написано. ерунда какая-то
Обычно, когда ты пишешь код, ты пишешь его чтобы его могли прочитать люди. Чтобы было понятно какого хуя тут делается, и всё такое. На С++ пишут не для людей. На С++ пишут то, что максимально быстро исполнит машина. С пониманием кэша, шины памяти, того что происходит когда тред с твоей программой переносится шедулером с одного ядра на другое, минимизация и разведение по углам тяжёлых операций, бранчинг и предсказуемость, и это ещё до того как ты сунешься в мультитрединг. Программист на С++ должен понимать в деталях как железо исполняет код, чтобы писать так как было удобно железу. При этом он также должен понимать в деталях, как компилятор плюсов генерирует код, чтобы писать так, чтобы генерировался код удобный железу. Обычно в итоге удобный железу код через финскую подушку компилятора приносит в жертву человекочитаемость. Программист на плюсах смотрит на этот код сквозь призму того, как он будет скомпилирован и выполнятся, и говорит "хм, логично". Программист на человеческих языках посмотрит на этот код с точки зрения человека, и сможет только сказать "БЛЯДЬ, ЧТО ТЫ ТАКОЕ?!".
Вот это умение понимать что нагенерит компилятор, и как это пройдёт сквозь железо-затыки, и есть особенность чтения профессионального кода на плюсах, от которой у программистов на других языках волосы дыбом встают, что аж сидеть неудобно.
Если ты пишешь для людей, игнорируя возможности писать для железа, то тебе нахуй не сдались плюсы. Если ты пишешь на плюсах, будь добр использовать то ради чего эта попиздятина существует. Попытки использовать плюсы как обычный человеческий язык программирования и словленный с этого расплав пукана и являются основной причиной ненависти к плюсам.
буду эйчаром!
Как будто просто бессмысленный набор переменных и операторов. Как будто утром сильно не выспался, на автомате что-то закодил, думая о чем-то другом, как-то оно еще при этом жило, и выявлялось чисто случайно.