GoldRobot

Ну лучше как ты bool tested_flag_ = false в классы вписывать, и ассертить их после теста. Ух блять юнит тест от бога.

У нас же года 3 назад был какой-то железячник задрот нет? Толи утка, толи еще какая херня его звали.

У лили миксов достаточно, могу понять. Играть против сильного персонажа меня не так что бы напрягает, на дистанции оно пофиксится, а вот фундаментально некоторые типажи персонажей я терпеть немогу. К примеру меня драг не так сильно раздражал как миксап машина на синей девочке. Ну отрывает ебучку, ну нужно потеть, ну и ладно? Пусть, через месяц ему ноги отрежут и он в мега-крипа превратится, так и произошло. Но я не считаю что нужно бежать нерфить Лили сейчас. Понять могу, но не думаю что это приоритет. Пусть прыгает и вертится дальше, не оп и ладно покамест.

Ага, вижу. AddRef, RemoveRef, Release. А если тег поставить, чтоб считало с 1, то ты споткнешься на local_ptr. Во, об этом и речь. Ты в меру своего скудного разумения мокинга и тестов, собственно, и написал тест. Как умеешь, как знаешь. Такую хуйню можно изобразить только в страшном сне. Что нужно было сделать, какая библотека для мокингов это позволит сделать красиво, я уже сказал. Флажки он блять тестит. Произошел мем "я не тупой я просто тролю". Да в целом гроха все и написал. Цпу читает память через кеш, как прослойку. Пишет тоже через нее. При чтении собственно кешируется адресс из памяти, очевидно. Но при этом еще кешируется некоторый объем данных вокруг конкретно нужного адресса памяти. Этот объем чето около 100 байт, он и называется кеш линией. Раз это кеш, то конкретная ячейка из RAM в кеше может быть только в одном виде (твоя переменная условно). Далее, этот кеш делится между ядрами. Ядра пишут в память через кеши обратно, с каким-то там размером пайплайна на запись. Соответственно с одной кеш линией в общем случае может работать множество ядер одновременно. В случае атомарных операций вся линия лочится к хуям (читать с нее может только одно ядро), ожидается пока то что уже там на молотили ядра и хотели записать в кеш запишется, потом из нее читает одно ядро, выполняет работу пишет анлокает. Потому атомик может подзадушить вообще все что на одном процессе с ней находится. В теории. На деле похуй, плюс похуй, если ты не начинаешь атомики за место интов юзать (я видел такое говно). Потому что кеш линий дохуя, и наврятли все твои 10 потоков в одной кеш линии зависнут, если не захотят одновременно с атомиком поработать. Хотя я не знаю как согласованность кешей работает (L1, L2), но они быстрые пиздец, сами понимаете. Потому я и говорил что в однопотоке похуй+похуй если ты там чутка лишними атомиками обмазался, и умный указатель у тебя по доброте душевной атомик, а не просто инт. Далее, барьером называется потому что все что до атомика происходит в твоем коде выполнится. Написал ты y ++; x ++; z ++; atomic_store(z); Все эти y,x,z компилятор может перетасовать как хочет, в каком хочет порядке. Пайплайн у процессора так же. То как в коде описано, не факт что будет так же как выполнится. Однако, когда дойдет до атомика исполнения, это значит что все что выше выполнилось однозначно. И так же у соседнего потока с этим же атомиком, у которого вообще другие не связанные с синхронизациями функции выполнялись до атомика. Даже если атомик "свободен". Вот тебе и "барьер". С помощью таких барьеров можно сделать машинарию и обеспечить трейдсейф работу с "обычными" типами, даже не используя явный мутекст. Но на самом деле этих барьеров больше одного, и лок кеш линий/записей может быть разный, а есть его варации. std::memory_order. Чето типа std::shared_lock/std::unique_lock. Можно себя этим наебнуть очень легко. Только лично я ебал в этих сортах разбираться, это выдрочь либо для тех кому прям интересно, либо для очень узких мест в дорогом софте. Браузеры тормозят не из-за этого, а у хрома фризит сайдбар с всего пару к закладк не потому что там кто-то вписал атомик лишний. Как и то что вам пара смс пришла с задержкой тоже не от того что там голдробот фаелсистем заюзал. Потому я придерживаюсь мнения что лучше зажать мутех заместо ебли с фенсингом, за исключением случаев когда это реально оправдано. UPD: Вопрос конечно где я напиздел и помню не правильно. Яб тоже почитал какой научпоп на эту тему с удовольствием.

Можешь не выебываться, ты обосрался в самом начале. Но ты круто тему переводишь. Абстракция и разделение зоны ответственности, чтобы не тестить мютекс, а протестировать логику многопотока, это - сложна. Наш предел хуячить везде умный-указатель-но-с-ручным-управлением. Но опустим, считай как хочешь, я пытался объяснить, но твой уровень мы уже знаем. Влететь не читая, и начать срать, устраивая клоунаду чтобы потом поорать "вы не понимаете, я тролил, на самом деле в яндексе работаю". Лучше давай оценим тесты за твоим авторством: Ебать откровение. Которое я еще в первых пару комментов написал как причину того почему я, персонально, этого не делаю. Тьфу блять, ну грохув, ну это уже тролинг какой-то не иначе.

Так это же косвенный баф Браена получается! Базовый патч, ждем. Не сильно понимаю нерфов Вити и Пауля. Вроде не такие уж и бесячие?

Ну я иммел в виду чтоб ты мог эти шарики, молнии, и вот такое навешивать в кастомизации. Бля я представил чтоб можно было выбрать 🤡. И на панише чтоб пачка их высыпалась с руки/ноги 🤡🤡🤡 🤡 🤡🤡🤡 Насколько я не люблю кринж кастомизацию, но это же охуенно

Ну согласен. Было бы прикольно иметь какой-то эффект или звук если це паниш. Кастомизирующийся если еще типа кх ваще пушка жеж?

Капитан, судно тонет. Мы иден на дно! Когда там уже заплатку на днище поставят в виде 1.5? Они что-то про сроки говорили? Ага особенно у кинга с его тру миксапами захватов.

Всмысле надпись что "тру паниш"? Хз такое мне кажется, не красивое. А КХ визуально видно, эффекты эти рисуются. Наверное было бы прикольно тру паниш бы чем-то подобным нарисовать? Но вот что я реально бы хотел, это что бы если ты захват не порвал, чтоб оно писало "оно рвалось вот так вот".

Клоуна в зеркале увидишь чучело. Ты уже не первый раз влетаешь, несешь хуйню, а потом выясняется что ты вообще понятия даже не имел о чем спор.

Справедливости ради сколько минус не важно в вопросе "а среагирую ли паниш сдать". Важна совокупность из стартап+полный рекавери, и того насколько просто мув различить.

Ты в дерьмо сел. Напоминаю как все было в реальности. Вы доказывали что их невозможно протестировать, а я утверждал что возможно, но тяжело, и дорого. А что мешает? Возможно. Просто тяжело и дорого покрывать. Поэтому, думаю все согласны считать значит что у меня получилось вам объяснить реальное положение дел. Приятно было пообщаться, много нового узнал! Чел, получается ты мне мозги столько страниц ебал, потому что не осилил "основной тезис" дуита нормально прочитать?

Откуда я мог знать что ты ссылаешь конкретно на гайдлайн хромиума? Ясно, как вижу челы сами поняли что проебались. Пока используй #define REQUIRE_ADOPTION_FOR_REFCOUNTED_TYPE() \ static constexpr ::base::subtle::StartRefCountFromOneTag \ kRefCountPreference = ::base::subtle::kStartRefCountFromOneTag https://github.com/scrapy/base-chromium/blob/master/memory/ref_counted.h#L290C1-L292C69 если собрался шарить владение прямо в конструкторе. Хз чем тебе еще помочь, ебись. Но тему с атомиками я так и не понял. В твоей гугловской копии шаред_птр_но_лучше так же атомик. В чем доебка тогда?

Цитата из гуглового стандарта https://google.github.io/styleguide/cppguide.html Согласно этому, ты накодил хуйню в своем примере. Потому что ты уже пошарил овнершип, а не передал мувом-копиец етц. Либо ты ссылаешься на какой-то другой гайдлайн, о котором я незнаю.

Почти, потому что у тебя вокруг этих накладных расходов дофига другого кода. Но ты видимо в лоб сравниваешь с int++. Именно потому что я пишу с++, я могу себе позволить эти накладные расходы. Там где это нужно и зачем нужно, а не на каждой переменной. Как я должен понять код куски которого я из тебя выдирать должен?

Класс A не является умным указателем. Ахаха. Откуда блять я это значить должен? Ты даже не от какогонибудь EnableThreadSafeRef отнаследовался, а напрямую от класса указателя Почти ничего не стоит. Атомик не так давит многопроцесс А должно? Думаешь лучше сегфолты, битую память, уб, как у тебя в примере жрать? Охуенно ты конечно придумал. Либо пиздуй отсюда, либо давай полный листинг.

Cмотря на то как ты пишешь тесты: Делаю логичный вывод что нет, нихуя не знаком.

Хорошо, уговорил, ведь я этого и не пиздел. О, я легко объясни, чего не понятно. Если умный указатель инкрементирует при copy/assign/конструкторе счетчик, то он УЖЕ будет 1. На момент вызова PostTaskOnWorkerThread(this, &A::SomeMethod); его конструктор УЖЕ отработал. Ведь от этого умного указателя и отнаследовался класс. А внутри этой твоей PostTaskOnWorker создается, логично, новый умный указатель который подумает до 2. Unless кто-то не умеет в мув семантику, не знает что такое RVO, и сделал буквально как ты написал. Что у тебя assign/copy constructor инкрементит, а просто конструктор нет, и потому можно создать объект с НУЛЕМ. Но тогда даже в синхронном однопоточном коде ты получишь абсолютно туже хуйню, что как-только умрет в PostTask последний референс, у тебя delete позовут. Почему ты такой тупой? У тебя там какая-то лапша из дерьма написана, и я хуй просышь что за лапша. Объясни нормально. Грохув кто-то прочитал гугловые стандарты, даже абсеил, нихуя не понял, но решил что слишком умный. std::shared_ptr специально сделали только с атомик версией. Потому что нирли нихуя не стоит, если ты не используешь многопоток, и чтобы не усложнять жизнь. Если у тебя есть какой-то кровь из носу нужный заоптимизировать кейс, то возьми shared_ptr имплементацию, и вырежи к хуям атомики. А лучше возьми имплементацию boost::local_shared_ptr (хуй ты об этом знаешь я подозреваю). А std::enable_shared_from_this, если ты блять не подумал, сделан именно так как сделан что бы не ебаться с кодом из твоего примера. Именно потому там внутри weak_ptr всегда создается. Именно потому из объекта, который создается вголую без shared_ptr, ты не можешь сделать shared_ptr, в отличии от твоего примера. И даже если ты сделаешь class A: public std::enable_shared_from_this {} auto aptr = new A{}; std::shared_ptr<A>(aptr) Оно всеравно корректно отработает. Представь, блять, себе, на само деле не обязательно make_shared звать на самом деле, можно и ручками. Достаточно звать shared_from_this() когда уже будет ясно кто должен чистить объект, будет овнер, собственно появится шаред птр. А даже если не сделать этого, выкинется просто эксепшен. Умно, не правда ли? За тебя уже подумали. За тебя уже сделали. Сделали как надо. Бери и пользуй. Либо хотя бы перенимай опыт. Из-за таких кодеров индексы ловят инфаркт, а дуиты смеются с плюсов застряв в С98. Не делайте так.

Чел. Это плата за безопасность. Ты сам себе злой буратино, который потом ебеться с тем что выше. Если нет контеншена, то атомик довольно быстро работает. Так же если классу НУЖНО разделяемое владение, что он ажно в себя вписывает, то он и должен быть, очевидно, обязательным. Если ты пишешь говно по которому даже не ясно за что оно ответственно, то ССЗБ. Не отработают методы, если не шаредптр сделан. Ну тоесть ты написал хуйню, объяснить которую даже не можешь. Ясно. Я удивлен что ты даже с gmock не знаком. Хотя казалось бы, не дуит, не дуит мы думали ты. Чел, ту хуйню которые ты написал и даешь нам как пример, согласно гугловским гайдлайнам нужно в печи нахуй сжечь.

Ты про свои гениальные тесты вида: MyClass::MyFunc() { member_variable_ = 1; } MyTest() { MyClass tested_class; tested_class.MyFunc(); assert(tested_class.member_variable_ == 1); } ? Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились. Судя по коду я попал в точку, ты вообще не понимаешь о чем говоришь Флажки блять в классе. Ты ебанутый? Узри же, МАГИЮ https://google.github.io/googletest/gmock_cook_book.html#OrderedCalls Извне? AddRef чья обязанность позвать? Нету ThreadSafeRef/WeakThreadSafeRef? Если ты такое дерьмище адское поддерживаешь, и допиливаешь. Без тестов и не умея тесты писать, мое тебе уважение брат. Без рофлов, когда фундаментальные тулсы написаны вот так, представить боюсь что за паутина там у тебя накожена вообще. Расскажи. Нагрузочное тестирование не является проверкой на провисшие ссылки. Собственно как и проверки тредсейфа, о чем вы сами, вроде, доказали. Еще идеи?

Ты провисшие ссылки то как собрался тестить? Еще рофл конечно такую хуйню в конструкторе писать. Конечно придется код написать так что бы он тестировался, а ты как думал? Хотелось бы послушать как ты покрываешь тестами на протухсшие ссылки/указатели синхронный код. И в чем тут будет разница. БТВ Ты вообще какую-то аддовую хуйню написал. Если ты не передал туда владение, просто по this передал, то схуяли оно там должно декрементить и что-то удалять? Тоесть у тебя ThreadSafeRefcounted полагается что кто-то ИЗВНЕ зовет decrease_count или типа того? На момент вызова ThreadSafeRefcounted счетчик УЖЕ инкрементирован. Его конструктор уже отработал. unless ты отнаследующейся пометив public, и у тебя MakeRef ответственна за инкрементит. Тогда это уже нихуя не умный указатель. Не пишите такую хуету как грохуф, прошу вас и заклинаю, изайте шаред птры из стд.

Не совсем. Слипами и прочим ты тестируешь совокупность имплементации и кейсов которые ты не знаешь. А должен тестировать кейс которые ты знаешь. До ребяток никак не доходит, что предметом тестирования становится не имлпементация того как у тебя там джейсон перекладывается, а логика синхронизации. Логика работы с примитивами и собственно с тем что представляет из себя сущность полезного кода. От того и не понимания и перлы про "хахаха тестишь имплементацию". Для этого достаточно и нужно мокать и абстрагировать. Тебе нужно придумать логику работы, и проверить то что ты эту логику заимплементил как ожидалось. Это и является предметом теста. Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит: connection.lock connection.exec connection.unlock cache.lock cache.save cache.unlock И ни один другой метод не вызывается. Ты ведь продумал логику свою, логику в код транслировал, вот ее и проверяй. Проверяй что два лока в дедлок не могут принципиально встать. Вдруг ты подумал, но накодил cache.lock->connection.unlock? Скорее проблема непонимания у дуита и ко в том, что они мокинг воспринимают исключительно как способ подсунуть классик без имплементации. Ну чтоб без коннекта в базе как-то запустился. О настоящем тесте асинхронку, таймеров, работы с сокетами, файловой системой, для того что бы проверить как работает то что ты накодил, они не слышали. Просто тестят что у них сокет читается, ну и ладно. Прописываю чтения документации о пусть будет gmock. Впрочем я их понимаю, нахуй надо. Это все слишком сложно получается в итоге. Чтож, видимо мышления дуита это твой предел. Невысокий оказался.

По факту есть что сказать? Дуит попытался, разьебался. Ты следующий.

вкатил колбаску тебе защеку