- 1
Class::Class(Pethu pethu) : pethu(std::move(pethu)) {-
C++ / Говнокод #27107
+2
std::move заебал. Просто взял, блядь, — и заебал!
Чем это лучше передачи по ссылке?Запостил:
guestinxo,
12 Ноября 2020
Follow us!
Но вообще разная семантика же совершенно.
Мув: Я умираю, вот тебе мой петух, храни его, теперь он твой
Ссылка: Могу одолжить тебе своего питуха на недельку
Как сейчас:
Вот тебе копия петуха, делай что хочешь. А я его муваю себе в конструкторе.
А я хочу:
Вот тебе отдалживаю петуха, копируй его себе сам, если хочешь.
Обычно просто T (без const & или &&) принимают тогда, когда функция в любом случае будет копировать себе переданного петуха. То есть вместо
Пишут просто
если тебе не жалко уничтожить питуха на вызываемой стороне, то можно же передать ссылку, и мувнуть.
Если тебе того петуха жалко, то просто копируй, и теки
а так ты сначала его создаешь копированием, а потом сразу же отправляешь на компост
А я привела пример, где коньстантность сохраняется.
В обоих случаях нахуй нужен «std::move» кроме как выебнуться - я не понимаю.
Теперь даже курицам всё понятно?
std::forward<T> только.
Опечатался, я его не так часто юзаю. В реальном примере на ideone он есть.
https://youtu.be/l_--ewb4YXg
Предсказываю, кресты уже через несколько лет будут использоваться только там, где используется ассемблер - в микроконтроллерах и в задачах, где нужен пердолинг за лишний 1% производительности.
Я уже говорил, что так концентрироваться на внешней шелухе (педерача значений, по значению, ссылке, питузу, консатному питуну на консатный петху) вместо решаемой задачи - это нездоровая питушня, связанная с тормозами компьютеров в прошлом веке. Сейчас дешевле, быстрее и надёжнее написать программу на более ссылочно прозрачном языке, чем C++.
Широко использоваться будут простые динамические питухи вроде JS с уклоном на зомбирующих дуракозащищающих питухов вроде python - легко найти дешёвого программиста и написать небольшой-средний проект.
Для средних-крупных проектов будет использоваться слабофункциональные языки - питушня с замыканиями и неизменяемыми данными или фреймворками для организации этого, ленивыми питухами. В отличие от тру функциональщины будет разрешена локальная нечисть в пределах функции или файла, но между модулями уже будут гулять только константные питухи.
const в C++ - формально приятная питушня, которая уменьшает количество проблем, но только в мечтах крестухов.
Здесь всё то же самое, как и в ООП. Вроде всё логично и хорошо, но на практике - бюрократия в электронном виде, где работник общественной уборной не имеет право заменить клиенту рулон бумаги, и приходится ждать десять тактов до прихода оберпапирмейстера. А потом, когда заказчик попросит сделать двойные уборные для влюблённых, окажется, что всё надо переписывать или вносить в стройную иерархию классов говно.
const тоже сначала долго прикидывается твоим бро, но ведёт себя как последнее говно, когда при изменении задачи тебе надо его куда-нибудь добавить или откуда-нибудь снять. Приходится просматривать всю диаграмму дейта флоу, следить за тем, чтобы в некоторых местах не копировали значение, чтобы не тратить память или получать по ссылке желаемые изменения, а в некоторых - наоборот копировали, чтобы не получать нежелательные изменения. Более того, если мы пишем чёрный ящик, который принимает const Pethu, то мы только гарантируем, что объект Pethu не сломает чёрный ящик. Но никто не гарантирует, что объект Pethu не сломает чёрный ящик. (Привет винительному питуху)
Как там в 2014? Небось, бакс по 30?
Гроб C++ ещё не достаточно хорошо закопали в поле микроконтроллеров, язык жив и грязный императивный подход всё ещё вызывает миллионы баттхёртов по всему земному диску шару.
С константной ссылкой клиент не может сказать "мне этот петух больше не нужен, забирай". И приходится ради него писать вторую версию функции с &&.
Можно, конечно, через универсальную ссылку сделать, но она только в шаблонах работает и надувает бинарь.
А с передачей по значению одна функция пригодна и для копирования и для мува. В итоге меньше копипасты и меньше говна в бинаре.
Это говорит ВЫЗЫВАЮЩАЯ сторона? Тогда нахуя ВЫЗВАЕМЫЙ код делает Mov?
Да, примеры приведены с вызывающей стороны. И они в общем-то ничем не отличаются от классических const & и &&.
> нахуя ВЫЗВАЕМЫЙ код делает Mov
А нахуя вызываемой стороне копировать аргумент, который всё равно сдохнет в конце вызова? Вполне логично, что вызываемый код его мувает.
Просто если вызывающая сторона сделает Move, то она разрушит своего питуха.
В случае же ссылки мы могли бы вообще ничего никуда не копировать, если мы знаем, что петух будет жить дольше вызывемой стороны..
Кстати, а можно сделать два конструктора: один получает питуха по ссылке, другой по значению, и вызывающая сторона выбирает:
* скопировать
* мувнуть
* передать ссылку
Или в С++ вызывающая сторона такие вещи не решает, если только там не указатель?
Борманд умный, я за Борманда!