Такое писать ненужно. В С++ есть вывод типа возврата. В ситуации же с растом:
fn a_plus_b(a: i32, b: i32) -> i32
-> i32 — это писать нужно. Потому что вывода типов нету.
То есть в C++ есть как минимум два разных синтаксиса
С чего вдруг они «два разных», если это один синтаксис? Вот в расте два синтаксиса для лябд и не-лямбд и никакого типа в лябдах указать нельзя. Вообще ничего нельзя, т.к. синтаксис очень слабый.
auto a_plus_b(uint32_t a, uint32_t b) {
return a + b;
}
auto a_plus_b(uint32_t a, uint32_t b) -> uint32_t {
return a + b;
}
В какой вселенной это два синтаксиса? Явно не в этой. По аналогии let x; и let x: T; тоже два разных синтаксиса.
Человеку, который много лет пишет, например, на Python, С++ будет казаться крайне вырвиглазным.
В этом нет никаких оснований. Он не будет казаться вырвиглазным — он будет касаться избыточным, но у С++ синтаксис не является избыточным. Аннотировать типы нужно? Аннотация в С++ куда менее избыточна чем в раст и куда более мощная(это даже сравнивать никак нельзя). Никак это не убрать. Точно так же наличие ссылок/указателей и прочего — это всё требует синтаксиса. От этого не уйти ни в каком языке.
Но раст это отдельная ситуации. Синтаксис там именно избыточен. Борроучекер несостоятелен без лайфтаймов, а лайфтаймы не не несут какой-то логики — это просто костыли, которые помогают чекеру работать(причём дырявые).
Тоже самое с теми же ссылками. В С++ они работают прозрачно, как в том же питоне. В расте нет. Они требуют дополнительного синтаксиса — дополнительного мусора.
Точно так же fn и прочая паскалятинка — это всё обусловлено слабость реализации. Это всё синтаксический мусор.
разработчики Rust не зря выбрали именно такой синтаксис объявления типа результата функции и типов аргументов
Что за чушь? Они ничего не выбирали. В примитивном синтаксисе вначале декларации всегда стоит кейворд. Это никак нельзя обойти. Никакого там выбора не было.
Если делать сишный синтаксис, а не паскалятский, то он куда сложнее. От того все расширения синтаксиса, либо отдельные синтаксисы строятся на расширении базовой опоры. Это либо кейворд, либо существующий элемент расширяемого синтаксиса.
Ах да, все эти рассуждения ломаются об лямбды. К тому же, в расте нету никаких decltype/typeof — потому что язык попросту слаб. Толку там с этого ровно ноль. Хотя нет, толк есть. Вывода всё равно нету, а значит приходится указывать тип из аргументов. Хотя нет, мы не можем указывать тип аргументов — мы можем указывать тип генериков. Ой, а шаблоны в С++ пишутся до типов и опять факап.
Вообщем, разбирать подобные рассуждения так глупо. Они же дырявые насквозь.
Без какого-то минимального понимания, минимальной аргументации пытаться понимать мотивацию языков.
Состоятельность подобного сравнения сомнительна, а вернее отсутствует. Существует не только malloc, а ещё и копирование. К тому же, на тех строках которые он показывал — аллокация и так не будет — будет оверхед только на копировании.
Как я уже писал — существует множество объект тяжелее условно-бесплатных строк. Хотя даже они не так что-бы и совсем бесплатны.
Это такие же трюки. Это работает только в одном кейсе и этой истории десяток лет. Я не понимаю почему её до сих пор везде рассказываю и выдают за что-то универсальное и то, что может кого-то удивить.
В конечном итоге этот трюк сливает pf, но автор нашел вывод — это похаять pf за шаблоны. Но это не проблема pf. Это общая проблема шаблонов которые нельзя ограничить и приходится обкладываться sfinae. Но её уже решили концептами.
К тому же, это решение не универсально. Оно работает только если нам нужно копировать объекты «как есть» вовнутрь объекта. Такое далеко не всегда нужно, а вернее чаще ненужно. А когда нужны все эти кейсы тривиальны и проще просто открыть все поля и инициализировать объекты через список инициализации. Это будет и проще и нагляднее и быстрее: cust{.first = «Niko»}
Только сначала перечитайте все примеры в этой, пожалуйста, я там немного добавил про std::forward в том числе.
Я прочитал и именно про forward я и говорил. Я нигде не отрицал, что вы показывали pf. Я говорил о том, что ваши выводы/сравнения pf и «по значению» неправильные. Так же, я объяснял почему.
Так же, я рассказал и о том, откуда взялся этот срыв покровов с «по-значению» с которым носятся неофиты. Они продолжают повторять одно и тоже уже сколько лет. Но проблема в том, что те кто изначально об этом рассказывал — объясняли всё. Но люди выдирают оттуда какие-то куски, ничего не понимания и неся эти откровения в массы.
«по-значению» + move достаточно хайповая вещь, которая никогда не претендовала на замену pf. Так же, было чётко сказано о её применении.
как правильно передавать аргументы в конструктор или сеттер.
Про это я так же говорил. const & имеет только одну проблему — нельзя мувать. Мы можем передать временный объект, но не можем его замувать(т.к. мы не знаем — какой там объект).
Именно поэтому «по-значению» имеет смысла только тогда, когда мы заходим мувать. Т.е. когда мы ходим скопировать/замувать аргумент в поле. Но, хоть и пример именно такой(а он чисто случайно такой), то нигде и никак на это явно не указывается.
Так же, я не стал говорить о том, что существуют концепты. Есть/будет auto && | String && и pf уже не так сложно писать.
sv — не си-строка, но прозрачно создаётся из си-строки со всеми вытекающими.
Если у вас есть сомнения в эффективности — сначала профилируйте, и только если вы действительно можете что-то выиграть на этих временных объектах — оптимизируйте.
Никакой профайлер ничего не покажет. Подобные советы говорят лишь о крайне странных представлениях о профайлере и отсутствии опыта работы с ним(кроме как в примитивных случаях).
Хорошо. Мы имеет оверхед на передаче. У нас тысячи функций, передаются десятки, сотни разных типов объектов. Всё это будет размазано и десяткам/сотням разных функций. Как мы вообще поймём, что проблема есть и как мы её локализуем? Да никак.
Даже если мы увидим много memcpy/malloc, то это не всегда нам позволит найти и локализовать причину. Ну узнаем мы, что из вызывают эти десятки/сотни функции(вместе с её тысячами других). Какие из этих конструкторов лишние?
Поэтому, никакой профайлер тут почти никогда не поможет. И проще изначально определиться с правильным подходом и его использовать.
Потому что пример в той статье полностью корректен, и автор статьи абсолютно прав.
Нет, очевидно. Это просто самый наивный способ передачи. Так напишет любой, кто 1-2 раза видел С++, а автор его таки 1-2 раза и видел.
копирование обеих строк
Копирование есть, оно есть всегда.
Если не боитесь комбинаторного взрыва, то можете дать шанс && (но зачем? реального выигрыша в скорости не будет никакого, оптимизатор не дремлет):
Подобная аргументация ничего не стоит.
Очевидно, что это не одно и тоже. В случае с передачей по ссылке не будет копирования, когда как в случае с первым вариантов оно будет. Ещё на 20-40 байтовой строке можно что-то говорить о том, что копирование бесплатно, но объекты не всегда 20-40байт.
Даже если у вас не std::string, а какой-то объект собственноручно написанного большущего класса, и вы хотите людей заставить перемещать его (а не копировать), то в таком случае лучше запретить конструктор копирование у этого большущего класса, нежели везде передавать его по &&. Так надежнее, да и код короче.
Надёжнее и быстрее как раз через &&. К тому же, к чему определяется это ложное разделение? Одно не мешает другому.
(из пушки по воробьям)
И подобная тоже.
Почему так происходит, каков фундаментальный принцип? Он прост: объект, как правило, должен ВЛАДЕТЬ своими свойствами.
Что это за принцип такой и с чего он должен кого-то волновать? Всё это догматическое raii достало уже всех — оно показало свою полную несостоятельность. Ещё с C++11 от этого глупого догмата начали отходить.
Если объект не хочет чем-то владеть, то он может владеть shared_ptr'ом на это «что-то».
Зачем захламлять код этим мусором, когда есть нормальные ссылки и сторедж может быть не только в хипе. Это опять какой-то догматизм.
pf{std::move(pf)} // std::move здесь важен для производительности
Мы копируем что-бы потом замувать, хотя можно с тем же успехом передать по ссылке, но. Что мы этим получим.
1) Мы получим меньше оверхеда т.к. ненужно будет копировать данные.
2) Если так произошло, что что-то кинуло исключение до move sp, то мы получим те самые:
накладные расходы на блокировку счетчика ссылок shared_ptr в памяти (сотни циклов CPU) и на его инкремент.
Потому что в случае с ссылкой оверхеда на передачу не будет(он будет при копировании в поле), а в ситуации со значением будет.
3) ссылка более универсальна. Т.к. мы не всегда хотим копию объекта. Мы можем захотеть взять подстроку, либо просто использовать данные для какой-то операции внутри конструктора(не копируя/перемещая их в поле).
Мораль: не используйте const& повально. Смотрите по обстоятельствам.
Опять какое-то ложное разделение. Передача не ограничивается этими двумя вариантами.
В конечном итоге подобная передача сливает pf во всём. И рассказывать о её какой-то эффективности — глупость и неправда.
Можно говорить о какой-то простоте для начинающих, но опять же слишком много но. Даже const & куда более универсален и лучше начинающим использовать его.
Ненужно пытаться вести какие-то войны руководствуясь хейтом const & времён С++11. Нужно понимать почему и за что хейтили const &. const & не позволяет мувать временные объекты и для решения этой проблемы существует pf. Решение с «по значению» просто более понятное людям и в какой-то мере может служить заменой pf, но эта замена не полноценна.
Но, людям свойственно использовать некий общий паттер при передаче. И с учётом того, что в 80% случаев люди не пытаются сохранить переданные объекты — переда по значению не может являться универсальной, ведь люди её начнут использовать для этого. И подобные советы — вредные советы.
Единственным правильным и универсальным решением является только «универсальная ссылка» и pf на базе неё. Всё остальное — не является полноценным и эффективным. Даже в таком самом лучшем для «по значению» кейсе.
К тому же сами рассуждения не имеют смысла. Единственное что может pm «бесплатно» — это switch. Всё что далее — это непредсказуемая лапша. К тому же почти всё это реализуется по аналогии с visit/variant. Правда никому ненужно.
Описание мапы будет всегда лучше. К тому же С++ может без проблем хоть phf в компилтайте сгенерировать.
Реализовать синтаксис схожий в pm так же можно. Интернет завален подобным. Правда, как я уже говорил, спросом не пользуется т.к. в подавляющем большинстве случаев бесполезно.
Ну естественно, если автор пишет, что визитор лучше паттерн-матчинга, то это авторитетное мнение, а если кто-то пишет, что паттерн-матчинг лучше визитора, то это глупые лозунги и растопропаганда.
У вас методичка течёт. Что-то я не вижу от вас разоблачений автора и обсуждения того, какой же он дурак со своими тезисами. Чего же вы гадите мне, а не гадите автору?
Я не хочу обсуждать растовский матч, впрочем, я его не знаю. Давайте обсуждать паттерн-матчинг в более функциональных языках,
Меня не интересует «функциональных языках» существующие только для написания хелвордов, хотя и хелворд вы не осилили на нём написать. Когда я увижу многопоточную версию хелворда?
как балансирование красно-чёрного дерева. Как на визиторах будет выглядеть функция
Когда я увижу хотя-бы одну состоятельную реализацию кд-дерева на этой лапше — тогда приходите. Заниматься и разбираться в синтаксическом мусоре я не хочу.
И зачем вам в реальной жизни нужна частично специализированная шаблонная перегрузка при написании небиблиотечного кода? У вас в ADT ваших часто есть std::variant<std::vector, std::vector>, которые надо обрабатывать похожим образом? Поздравляю, вы хреново спроектировали ваши типы, потому что это значит, что T1 и T2 должны быть ветками одного ADT.
Дальше лозунгов что-то будет?
Для паттерн-матчинга нельзя?
Опять лозунги? Меня это волнует мало. Можно — показывайте. На вопросы про матчинг отвечать должны вы, а не я.
И как этой композицией выразить «заматчить на тип Foo, если его вариант-член bar имеет значение типа Quux»?
Меня мало волнуют лозунги. Аналогичный код на расте в студию. Нету кода — с лозунгами не ко мне.
Mach7 это может. Перегрузки функций — нет. Но Mach7 никто не пользуется.
Что за нелепые попытки на каждый тезис придумывать новый супер-язык?
Понятно.
Опять убогая методичка. Либо цитируется тезис целиком, либо меня эта нелепица не волнует.
Как там, строки на уровень шаблонов уже завезли? Или тоже ненужно?
Что за нелепица? Строки на уровне шаблонов были всегда.
Про аналогичный пропозал для, кажется, C++23 вы, видимо, не слышали?
Что из этого нелепого срыва покровов следует?
Ну, что никто не обрабатывает ошибки выделения памяти для одного объекта в продакшен-коде (кроме чуваков из NASA и вояк, возможно). Даже на плюсах. Обрабатывают только ошибки выделения, не знаю, памяти под матрицу стопицот на стопицот.
Что это за набор нелепых лозунгов. Как быстро меняются методички. Буквально вчера все плюсовали статьи на тему «нужно проверять», а как случилась «лужа» мы всё забыли и оказывает проверять уже ненужно.
Даже на плюсах нельзя непроверить ошибку. В плюсах исключения.
В очередной раз игнорируя метаиронию контекста остальной части вашего комментария, можно лишь заметить, что да, куда им до лоровцев.
Ну да это очевидны. Вы в теме про ваш хелворд были слиты. Раст-адепты в теме про раст были слиты.
Сливает по какому критерию? Что по выразительности, что по числу строк кода оно, наоборот, уделывает.
Вот зачем писать эти лозунги глупые, если даже сам автор говорит о том, что визиотор уделывает pm, по крайне мере в его кейс. Да и почти в любом другом кейсе.
По какому критерию — по любому. Ваш критерий «по стракам» несостоятелен. Там уже выше кидали статью в которой автор «больше строк» не нашел, да и нейти их. К тому же искал он их в заведомо подложном кейсе. Критерий «по выразительности» так же несостоятелен, т.к. перегрузка куда более выразительна, нежели match.
Причины очевидны. Перегрузка может быть шаблонной, может быть частично шаблонной. Для перегрузки можно использовать композицию из существующих функций/типов.
match существует в rust и подобных языках лишь по одной причины — они крайне примитивных. В них нет шаблонов, перегрузки, компилтайм-вычислений, параметров-значения даже для генериков. В них попросту невозможно написать что-то типа overloaded-композитора, либо visit.
И самое интересное, как только будет реальная задача. Обход того же дерева — на нём будет очевидна вся несостоятельность pm. Что нам и сообщает автор. Но даже визиторы на rust будут написаны убого, т.к. нету перегрузки. Это будет тонна лапши на генерик-трейтах.
Как вы на визиторах замачтитесь на значение без того, чтобы городить тонны ифов?
Это ненужно. Для случае уровня свича есть свич. Реализовать тот же визитор для чего угодно — не является проблемой. Вообще визитор ничего не матчит, матчит перегрузка. Она уже есть на уровне языка.
тонны ифов?
Я бы в контексте раста об этом вообще не заикался. Как там не обработать ошибку без тонны ифов? Из-за тонны ифов раст-методичка даже nullptr из аллокатора игнорирует. А что, памяти нету — можно падать. Надёжность она такая. Особенно смешно выглядят рассуждения раст-адептов про «как вы можете игнорировать NULL у malloc».
Тут, кстати, видно уровень состоятельности ЦА. Как адепты бегут плюсовать какие угодно лозунги(ничем не обоснованные), лишь бы они соотносились с их верой.
Но почему в таком случае во всех известных мне проектах на плюсах код разделен?
Особенно в бусте и stdlib? Мне попросту лень отвечать на очередную идиотию в интернете. Эти нелепые аргументы уровня начальной школы уровня «мне»? С чего вдруг все проекты стали ограничиваться «мне»?
К тому же, даже если предположить, что их нет — это ничего не значит. Это такой же аргумент уровня начальной школы. Аргумент уровня «но почему в таком случае во всех известных мне лифтах было нассано?».
Что там вам известно — ни на что не влияет. Вы либо аргументируете за «нужно», либо продолжаете писать ахинею. Адепты всяких мастей вас будут плюсовать итак. Можете хоть рандомный набор слов писать.
Так ведь именно в этом разделении и проблема. В других языках нет необходимости разделять модуль компиляции и заголовочный файл к нему
В С++ нету так же необходимости, а есть возможность.
а в C++ почему-то вот все так делают. Наверное, есть необходимость..
Ничего нет. Как минимум у вас нет никакой конкретики, зачем что-то писать без какого-либо представления о вопросе? Разделение кода не имеет абсолютно никакого смысла, его ноль. Там можно что-то начать рассказывать про раздельную компиляцию, но тут опять же проблема. Никакой раст не собирается пофайлово, а значит все эти рассуждения не имеют смысла. К тому же, какое-то ускорении это так же мифология.
technic93 В С++ никакие модули(это просто нелепый лозунг внешней пропаганды) ненужны, а макросы не имеют никакого отношения к модулям, либо теме.
(именно реакция на критику, минусы в «карму» и т. п.).
В чём она неадекватно? В том, что обиженные адепты раста гадят в карму и минусуют, набегая на меня табунами?
Я вам так же советую изучить тему перед тем как делать какие-то выводы. Это уже не первая тема в которой они гадят. В корой угрожают. В которой они проигрывают.
Почему вас так волнует, что кто-то в интернете поставил вам минус в какую-то «карму», как от этого изменится ваша жизнь?
Мотивация гадящих адептов очевидна — не дать мне писать комменты. Таково устройство этого ресурса, что табун гадящих адептов может лишить тебя возможности свободно что-то писать.
Почему вы так агрессивно и остро реагируете? Симптомы бреда преследования прослеживаются (какая-то группа лиц желает зла, гадит и угрожает).
У меня всё задокументировано. А вы просто кидаетесь нелепыми обвинениями.
Отличная история. Адепты гадят и делают вид будто бы ничего не было. Ответы будут? Ответы за угрозы, ответы за то, что гадят? Где ответы? А Нету ответов, есть только «Гадят» и нелепые обвинения уровня начальной школы
Адепты увидели ни на чём не обоснованный трёп и начали плюсовать того, кто нагло врёт и оправдывает их. И гадят, гадят. Ведь ничего иного они не могут.
Совет. Не использую ни раст, ни С++, но чем больше вы используете фразы «Каждая новая строчка пробивает очередной дно», «сливаться и гадить», «гадящие в карму», «бред это ваши рассуждения вызванные вашем же непониманием», «да и попросту враньё», тем больше вам будут снижать карму, причем даже если вы писали по делу.
Ваши рассуждения не работают. Гадить начали до всего, а значит не в следствии. «бредом» было названо моё утверждение, где ваш коммент там? Нету. А что же так? Неужели вы просто пытаетесь что-то оправдываться, даже не разобравшись в теме?
Ну вот не любят на Хабре такой тон, для многих это как красная тряпка, причем поставить минус могут даже не разбираясь кому и почему вы так писали (бывает прилетает даже когда оппонент явный тролль). Сомневаюсь, что хотя бы один минус вам прилетел именно от адептов раста.
Именно адептов. Эти адепты набегают табунами из всяких чатов и прочих сборов и минусуют. Это мною доказанный факт.
Я уже отвечал в нескольких темах и в этих самых темах я то и делал, что опровергал мифология раста. Как и побеждал адептов попросту кодом. Именно это их тригерит и вы можете пойти и изучит мои комментарии.
Таким образом с моей стороны есть аргументация, код и победы. Со стороны адептом — нет ничего. Они мотивированы гадить, что они и делают. Точно так же мы не видим их аргументации, но видим минусы.
Всё это было мною разобрано и доказано тысячи раз. Разберитесь перед тем как кого-то оправдывать.
Ах да, существуют адекватные адепты раста. Они способны писать код, способны понимать. Но проблема в том, что их очень мало и адекватный человек просто так не гадит. Гадит только тот, кому нечего сказать. Кто пытается заткнуть меня/неугодных.
Я вам ещё раз советую почитать историю Посмотреть как мне угрожали эти адепты. И где же все честные люди были, когда мне писали откровенные угрозы? А, никого не было.
Если вы про auto в сигнатуре, то лично я бы предпочел видеть там полноценный тип/шаблон. Да, не во всех ситуациях это будет красиво, но в большинстве — снимет кучу головной боли при чтении кода.
Да, шаблоны вполне себе разбиваются. Не на .h и .cpp, конечно, но на блоки объявления и реализации — вполне.
Это будет некрасиво в случае использования современного С++-кода. Современный С++-код полагается на типизацию и сложные типы, которые не так-то просто вывести руками. И именно auto убирает все эти проблемы.
К тому же подобный код ненужно читать. 1min / 1s — вы же не будите руками писать тип? И вам ненужно при чтении знать тип. Задача системы типов сделать таким образом, что-бы вы не смогли написать 1min * 1s;
К тому же, выводит типы задача ide. Как и задача компилятора(ide) проверять синтаксическую корректность кода. Ненужно это делать за них. Это пустая трата сил на то, что реализуется автоматикой. Всё что автоматизируется должно быть автоматизировано.
Я про случаи когда
Ну это просто си-api.
Вполне себе С++, вполне себе хороший способ убрать компиляцию тяжелых частей в локализованные .cpp. Кроме прочего, таким образом можно уменьшить количество инклудов которые расползутся по проекту, ставя их только в .cpp
Ещё раз. Если ваша библиотека ho, то вы никаким образом подобное не сделаете. Если вы сделаете шаблонное api, то его нельзя будет засунуть в cpp. Вы можете сделать только сишное api.
Таким образом мы просто сделаете обёртку над шаблонной ho-библиотекой. Удобство сишного api крайне сомнительно в случае какой-то обобщённой логики. А такой логики в современной С++ навалом.
Пример интересный, спасибо, но не уверен что все это так же хорошо масштабируется на относительно большие проекты
Я думаю, что хром является «относительно большим проектом». Там всё так же работает. Именно это они и сделали.
Вот это враньё. пруф.
Такое писать ненужно. В С++ есть вывод типа возврата. В ситуации же с растом:
-> i32 — это писать нужно. Потому что вывода типов нету.
С чего вдруг они «два разных», если это один синтаксис? Вот в расте два синтаксиса для лябд и не-лямбд и никакого типа в лябдах указать нельзя. Вообще ничего нельзя, т.к. синтаксис очень слабый.
В какой вселенной это два синтаксиса? Явно не в этой. По аналогии let x; и let x: T; тоже два разных синтаксиса.
В этом нет никаких оснований. Он не будет казаться вырвиглазным — он будет касаться избыточным, но у С++ синтаксис не является избыточным. Аннотировать типы нужно? Аннотация в С++ куда менее избыточна чем в раст и куда более мощная(это даже сравнивать никак нельзя). Никак это не убрать. Точно так же наличие ссылок/указателей и прочего — это всё требует синтаксиса. От этого не уйти ни в каком языке.
Но раст это отдельная ситуации. Синтаксис там именно избыточен. Борроучекер несостоятелен без лайфтаймов, а лайфтаймы не не несут какой-то логики — это просто костыли, которые помогают чекеру работать(причём дырявые).
Тоже самое с теми же ссылками. В С++ они работают прозрачно, как в том же питоне. В расте нет. Они требуют дополнительного синтаксиса — дополнительного мусора.
Точно так же fn и прочая паскалятинка — это всё обусловлено слабость реализации. Это всё синтаксический мусор.
Что за чушь? Они ничего не выбирали. В примитивном синтаксисе вначале декларации всегда стоит кейворд. Это никак нельзя обойти. Никакого там выбора не было.
Если делать сишный синтаксис, а не паскалятский, то он куда сложнее. От того все расширения синтаксиса, либо отдельные синтаксисы строятся на расширении базовой опоры. Это либо кейворд, либо существующий элемент расширяемого синтаксиса.
Ах да, все эти рассуждения ломаются об лямбды. К тому же, в расте нету никаких decltype/typeof — потому что язык попросту слаб. Толку там с этого ровно ноль. Хотя нет, толк есть. Вывода всё равно нету, а значит приходится указывать тип из аргументов. Хотя нет, мы не можем указывать тип аргументов — мы можем указывать тип генериков. Ой, а шаблоны в С++ пишутся до типов и опять факап.
Вообщем, разбирать подобные рассуждения так глупо. Они же дырявые насквозь.
Без какого-то минимального понимания, минимальной аргументации пытаться понимать мотивацию языков.
Пример чего? Того, что там будет копирование? Это очевидно.
То, что это выражается — так же очевидно. Но вы начните с измерений move — после этого уже можно будет поговорить о копировании.
Заранее спасибо.
Состоятельность подобного сравнения сомнительна, а вернее отсутствует. Существует не только malloc, а ещё и копирование. К тому же, на тех строках которые он показывал — аллокация и так не будет — будет оверхед только на копировании.
Как я уже писал — существует множество объект тяжелее условно-бесплатных строк. Хотя даже они не так что-бы и совсем бесплатны.
Это такие же трюки. Это работает только в одном кейсе и этой истории десяток лет. Я не понимаю почему её до сих пор везде рассказываю и выдают за что-то универсальное и то, что может кого-то удивить.
В конечном итоге этот трюк сливает pf, но автор нашел вывод — это похаять pf за шаблоны. Но это не проблема pf. Это общая проблема шаблонов которые нельзя ограничить и приходится обкладываться sfinae. Но её уже решили концептами.
К тому же, это решение не универсально. Оно работает только если нам нужно копировать объекты «как есть» вовнутрь объекта. Такое далеко не всегда нужно, а вернее чаще ненужно. А когда нужны все эти кейсы тривиальны и проще просто открыть все поля и инициализировать объекты через список инициализации. Это будет и проще и нагляднее и быстрее: cust{.first = «Niko»}
Мне лень.
Я прочитал и именно про forward я и говорил. Я нигде не отрицал, что вы показывали pf. Я говорил о том, что ваши выводы/сравнения pf и «по значению» неправильные. Так же, я объяснял почему.
Так же, я рассказал и о том, откуда взялся этот срыв покровов с «по-значению» с которым носятся неофиты. Они продолжают повторять одно и тоже уже сколько лет. Но проблема в том, что те кто изначально об этом рассказывал — объясняли всё. Но люди выдирают оттуда какие-то куски, ничего не понимания и неся эти откровения в массы.
«по-значению» + move достаточно хайповая вещь, которая никогда не претендовала на замену pf. Так же, было чётко сказано о её применении.
Про это я так же говорил. const & имеет только одну проблему — нельзя мувать. Мы можем передать временный объект, но не можем его замувать(т.к. мы не знаем — какой там объект).
Именно поэтому «по-значению» имеет смысла только тогда, когда мы заходим мувать. Т.е. когда мы ходим скопировать/замувать аргумент в поле. Но, хоть и пример именно такой(а он чисто случайно такой), то нигде и никак на это явно не указывается.
Так же, я не стал говорить о том, что существуют концепты. Есть/будет auto && | String && и pf уже не так сложно писать.
sv — не си-строка, но прозрачно создаётся из си-строки со всеми вытекающими.
Никакой профайлер ничего не покажет. Подобные советы говорят лишь о крайне странных представлениях о профайлере и отсутствии опыта работы с ним(кроме как в примитивных случаях).
Хорошо. Мы имеет оверхед на передаче. У нас тысячи функций, передаются десятки, сотни разных типов объектов. Всё это будет размазано и десяткам/сотням разных функций. Как мы вообще поймём, что проблема есть и как мы её локализуем? Да никак.
Даже если мы увидим много memcpy/malloc, то это не всегда нам позволит найти и локализовать причину. Ну узнаем мы, что из вызывают эти десятки/сотни функции(вместе с её тысячами других). Какие из этих конструкторов лишние?
Поэтому, никакой профайлер тут почти никогда не поможет. И проще изначально определиться с правильным подходом и его использовать.
Нет, очевидно. Это просто самый наивный способ передачи. Так напишет любой, кто 1-2 раза видел С++, а автор его таки 1-2 раза и видел.
Копирование есть, оно есть всегда.
Подобная аргументация ничего не стоит.
Очевидно, что это не одно и тоже. В случае с передачей по ссылке не будет копирования, когда как в случае с первым вариантов оно будет. Ещё на 20-40 байтовой строке можно что-то говорить о том, что копирование бесплатно, но объекты не всегда 20-40байт.
Надёжнее и быстрее как раз через &&. К тому же, к чему определяется это ложное разделение? Одно не мешает другому.
И подобная тоже.
Что это за принцип такой и с чего он должен кого-то волновать? Всё это догматическое raii достало уже всех — оно показало свою полную несостоятельность. Ещё с C++11 от этого глупого догмата начали отходить.
Зачем захламлять код этим мусором, когда есть нормальные ссылки и сторедж может быть не только в хипе. Это опять какой-то догматизм.
Мы копируем что-бы потом замувать, хотя можно с тем же успехом передать по ссылке, но. Что мы этим получим.
1) Мы получим меньше оверхеда т.к. ненужно будет копировать данные.
2) Если так произошло, что что-то кинуло исключение до move sp, то мы получим те самые:
Потому что в случае с ссылкой оверхеда на передачу не будет(он будет при копировании в поле), а в ситуации со значением будет.
3) ссылка более универсальна. Т.к. мы не всегда хотим копию объекта. Мы можем захотеть взять подстроку, либо просто использовать данные для какой-то операции внутри конструктора(не копируя/перемещая их в поле).
Опять какое-то ложное разделение. Передача не ограничивается этими двумя вариантами.
В конечном итоге подобная передача сливает pf во всём. И рассказывать о её какой-то эффективности — глупость и неправда.
Можно говорить о какой-то простоте для начинающих, но опять же слишком много но. Даже const & куда более универсален и лучше начинающим использовать его.
Ненужно пытаться вести какие-то войны руководствуясь хейтом const & времён С++11. Нужно понимать почему и за что хейтили const &. const & не позволяет мувать временные объекты и для решения этой проблемы существует pf. Решение с «по значению» просто более понятное людям и в какой-то мере может служить заменой pf, но эта замена не полноценна.
Но, людям свойственно использовать некий общий паттер при передаче. И с учётом того, что в 80% случаев люди не пытаются сохранить переданные объекты — переда по значению не может являться универсальной, ведь люди её начнут использовать для этого. И подобные советы — вредные советы.
Единственным правильным и универсальным решением является только «универсальная ссылка» и pf на базе неё. Всё остальное — не является полноценным и эффективным. Даже в таком самом лучшем для «по значению» кейсе.
К тому же сами рассуждения не имеют смысла. Единственное что может pm «бесплатно» — это switch. Всё что далее — это непредсказуемая лапша. К тому же почти всё это реализуется по аналогии с visit/variant. Правда никому ненужно.
Описание мапы будет всегда лучше. К тому же С++ может без проблем хоть phf в компилтайте сгенерировать.
Реализовать синтаксис схожий в pm так же можно. Интернет завален подобным. Правда, как я уже говорил, спросом не пользуется т.к. в подавляющем большинстве случаев бесполезно.
Типичное «слышал звон». cpp -E в студию.
Меня не перестают удивлять эти срывы покровов. Объявления не имеют никакого отношения к инклюдам.
У вас методичка течёт. Что-то я не вижу от вас разоблачений автора и обсуждения того, какой же он дурак со своими тезисами. Чего же вы гадите мне, а не гадите автору?
Меня не интересует «функциональных языках» существующие только для написания хелвордов, хотя и хелворд вы не осилили на нём написать. Когда я увижу многопоточную версию хелворда?
Когда я увижу хотя-бы одну состоятельную реализацию кд-дерева на этой лапше — тогда приходите. Заниматься и разбираться в синтаксическом мусоре я не хочу.
Вот зачем писать эти лозунги глупые, если даже сам автор говорит о том, что визиотор уделывает pm, по крайне мере в его кейс. Да и почти в любом другом кейсе.
По какому критерию — по любому. Ваш критерий «по стракам» несостоятелен. Там уже выше кидали статью в которой автор «больше строк» не нашел, да и нейти их. К тому же искал он их в заведомо подложном кейсе. Критерий «по выразительности» так же несостоятелен, т.к. перегрузка куда более выразительна, нежели match.
Причины очевидны. Перегрузка может быть шаблонной, может быть частично шаблонной. Для перегрузки можно использовать композицию из существующих функций/типов.
match существует в rust и подобных языках лишь по одной причины — они крайне примитивных. В них нет шаблонов, перегрузки, компилтайм-вычислений, параметров-значения даже для генериков. В них попросту невозможно написать что-то типа overloaded-композитора, либо visit.
И самое интересное, как только будет реальная задача. Обход того же дерева — на нём будет очевидна вся несостоятельность pm. Что нам и сообщает автор. Но даже визиторы на rust будут написаны убого, т.к. нету перегрузки. Это будет тонна лапши на генерик-трейтах.
Это ненужно. Для случае уровня свича есть свич. Реализовать тот же визитор для чего угодно — не является проблемой. Вообще визитор ничего не матчит, матчит перегрузка. Она уже есть на уровне языка.
Я бы в контексте раста об этом вообще не заикался. Как там не обработать ошибку без тонны ифов? Из-за тонны ифов раст-методичка даже nullptr из аллокатора игнорирует. А что, памяти нету — можно падать. Надёжность она такая. Особенно смешно выглядят рассуждения раст-адептов про «как вы можете игнорировать NULL у malloc».
Тут, кстати, видно уровень состоятельности ЦА. Как адепты бегут плюсовать какие угодно лозунги(ничем не обоснованные), лишь бы они соотносились с их верой.
Особенно в бусте и stdlib? Мне попросту лень отвечать на очередную идиотию в интернете. Эти нелепые аргументы уровня начальной школы уровня «мне»? С чего вдруг все проекты стали ограничиваться «мне»?
К тому же, даже если предположить, что их нет — это ничего не значит. Это такой же аргумент уровня начальной школы. Аргумент уровня «но почему в таком случае во всех известных мне лифтах было нассано?».
Что там вам известно — ни на что не влияет. Вы либо аргументируете за «нужно», либо продолжаете писать ахинею. Адепты всяких мастей вас будут плюсовать итак. Можете хоть рандомный набор слов писать.
В С++ нету так же необходимости, а есть возможность.
Ничего нет. Как минимум у вас нет никакой конкретики, зачем что-то писать без какого-либо представления о вопросе? Разделение кода не имеет абсолютно никакого смысла, его ноль. Там можно что-то начать рассказывать про раздельную компиляцию, но тут опять же проблема. Никакой раст не собирается пофайлово, а значит все эти рассуждения не имеют смысла. К тому же, какое-то ускорении это так же мифология.
technic93 В С++ никакие модули(это просто нелепый лозунг внешней пропаганды) ненужны, а макросы не имеют никакого отношения к модулям, либо теме.
В чём она неадекватно? В том, что обиженные адепты раста гадят в карму и минусуют, набегая на меня табунами?
Я вам так же советую изучить тему перед тем как делать какие-то выводы. Это уже не первая тема в которой они гадят. В корой угрожают. В которой они проигрывают.
Мотивация гадящих адептов очевидна — не дать мне писать комменты. Таково устройство этого ресурса, что табун гадящих адептов может лишить тебя возможности свободно что-то писать.
У меня всё задокументировано. А вы просто кидаетесь нелепыми обвинениями.
Отличная история. Адепты гадят и делают вид будто бы ничего не было. Ответы будут? Ответы за угрозы, ответы за то, что гадят? Где ответы? А Нету ответов, есть только «Гадят» и нелепые обвинения уровня начальной школы
Ваши рассуждения не работают. Гадить начали до всего, а значит не в следствии. «бредом» было названо моё утверждение, где ваш коммент там? Нету. А что же так? Неужели вы просто пытаетесь что-то оправдываться, даже не разобравшись в теме?
Именно адептов. Эти адепты набегают табунами из всяких чатов и прочих сборов и минусуют. Это мною доказанный факт.
Я уже отвечал в нескольких темах и в этих самых темах я то и делал, что опровергал мифология раста. Как и побеждал адептов попросту кодом. Именно это их тригерит и вы можете пойти и изучит мои комментарии.
Таким образом с моей стороны есть аргументация, код и победы. Со стороны адептом — нет ничего. Они мотивированы гадить, что они и делают. Точно так же мы не видим их аргументации, но видим минусы.
Всё это было мною разобрано и доказано тысячи раз. Разберитесь перед тем как кого-то оправдывать.
Ах да, существуют адекватные адепты раста. Они способны писать код, способны понимать. Но проблема в том, что их очень мало и адекватный человек просто так не гадит. Гадит только тот, кому нечего сказать. Кто пытается заткнуть меня/неугодных.
Я вам ещё раз советую почитать историю Посмотреть как мне угрожали эти адепты. И где же все честные люди были, когда мне писали откровенные угрозы? А, никого не было.
Бред это ваши рассуждения вызванные вашем же непониманием. Шаблон нельзя никуда эспортировать по определению. Эспортировать куда-то можно инстанс.
Что за бред? Во-первых 2-3-4 типа это не шаблон, у шаблона нету никаких ограничений. Во-вторых эспортируются не шаблоны, а инстансы.
Узнайте разницу между первым и вторым перед тем как кричать «бред».
Это будет некрасиво в случае использования современного С++-кода. Современный С++-код полагается на типизацию и сложные типы, которые не так-то просто вывести руками. И именно auto убирает все эти проблемы.
К тому же подобный код ненужно читать. 1min / 1s — вы же не будите руками писать тип? И вам ненужно при чтении знать тип. Задача системы типов сделать таким образом, что-бы вы не смогли написать 1min * 1s;
К тому же, выводит типы задача ide. Как и задача компилятора(ide) проверять синтаксическую корректность кода. Ненужно это делать за них. Это пустая трата сил на то, что реализуется автоматикой. Всё что автоматизируется должно быть автоматизировано.
Ну это просто си-api.
Ещё раз. Если ваша библиотека ho, то вы никаким образом подобное не сделаете. Если вы сделаете шаблонное api, то его нельзя будет засунуть в cpp. Вы можете сделать только сишное api.
Таким образом мы просто сделаете обёртку над шаблонной ho-библиотекой. Удобство сишного api крайне сомнительно в случае какой-то обобщённой логики. А такой логики в современной С++ навалом.
Я думаю, что хром является «относительно большим проектом». Там всё так же работает. Именно это они и сделали.