Grohuf

Блять, гроха, ебаный стыд. Я описал идею того, как это делается, и как я считаю это правильным. Я взял выраженный пример. Мне что нужно было, посидеть сейчас и повыдумывать тебе что то сложнее? С ифами и прочим? Нужно было синженерить тебе класс какимнибудь сокетом? Придумать логику, тесты к ней, и расписать? Ты сам не можешь представить себе просто работу я хуй знает, с базой? Там где у тебя паралельно connect, reconnect, exec, disconnect, stats, healthcheck, soft_stop и тебе нужно это скомутировать через логику. С очередями потоко безопасными, калбеками на пуки, таймаутами, и реконнектами скрытыми в этом классе. Но логику которого ты блять должен продумать, реализовать, и быть увереным что она отработала так как ты это нарисовал в голове посмотрев просто на цепочку EXPECT_CALL. И быть увереным что хотя бы нарисованные в голове сценарии ты сделал правильно. Не говоря уже о том чтобы это как-то зафиксировать. Это и нужно тестировать, если ты хочешь сделать надежно. Это и нужно абстрагировать. Эту логику. И это я сказал десять раз уже. Но ты тролишь тупостью "хахаха он хочет std::mutex::lock тестить". Подискутировали, спасибо хорош. Фпизду, сегодня с тобой на эту тему говорить больше не буду, невижу смысла. А зачем во всем тобой перечисленном локи? Я за пять минут написал многопоточный тест. А ебланы до сих спор спорят о возможности / уникальной сложности тестирования многопотока. Это что за язык? Js? Кто ребенка потерял? Вызовите полицию, пусть найдут его родителей

То есть, когда GR вызывает приватную функцию класса lock() - это ок. Когда я показываю, что он пишет хуйню и просто меняю переменную - это другое Ты писал: вызвать функцию а1, а2, а3. Потом проверить, что а1, а2 и а3 вызвались в этом порядке. Тебе еблану говорят, что это хуйня, а не тест. Тест, который тупо копирует содержимое функции - говно из жопы. Из экспектами он не превратится в золото.

Ну лучше как ты bool tested_flag_ = false в классы вписывать, и ассертить их после теста. Ух блять юнит тест от бога. Я уже понял, что ты ни хуя не понял, для чего написано так. Я по мнению еблана, должен был писать на каком-то фреймворке, не зная, имеете ли вы знания о нем. Ахуеть. А чего ты сам раньше свои объяснения на GMOCK не писал? Не знаешь что ли?

Ага, вижу. AddRef, RemoveRef, Release. А если тег поставить, чтоб считало с 1, то ты споткнешься на local_ptr. Во, об этом и речь. Ты в меру своего скудного разумения мокинга и тестов, собственно, и написал тест. Как умеешь, как знаешь. Такую хуйню можно изобразить только в страшном сне. Что нужно было сделать, какая библотека для мокингов это позволит сделать красиво, я уже сказал. Флажки он блять тестит. Произошел мем "я не тупой я просто тролю". Я пытался. Но ты и впрямь просто дурак. AddRef у него ручками вызывается . А если я ему скажу, что иногда реально вызывается, то у него инфаркт жопы случится. Про тест - это просто кринж. Тупоголовый еблан думает, что если он напишет EXPECT_CALL, то его дерьмо-тест станет золотым. Алхимик, ебаный. Походу зпшка в два огра и впрямь твой предел. Это пиздец, как будто с полным кретином разговариваю.

(про атомик) вопрос в зал - есть ли материал, где было бы расписано, как оно работает на нижнем уровне - что делает система, что происходит с железом хз, сам бы почитал. Тема с барьерами памяти и атомиками довольно сложная. Но как-то забиваю, так как в работе не нужно.

атомарные операции вставляют барьер памяти. Ничего удивительного. Мьютекс - это не lock inc. lock inc - это атомарный инкремент. На Windows называется InterlockedIncrement. Типичный мьютекс, доступный только в одном процессе - это спинлок (который делается на атомарных операциях) + системный мьютекс, если спинлок крутится слишком долго (в Windows эта хуйня называется критической секцией). Уход в ожидание на мьютексе, предоставляемым ядром, - очень дорогая операция. Но если все ограничивается ожиданием в спинлоке, то ожидание на критической секции достаточно не дорого.

Каким ручным управлением? Хули ты такой тупой? Там все до предела автоматизировано и везде поставлена защита от дурака. Именно поэтому была допущена такая ошибка. Запостить задачу на другой поток в хромике - это как чихнуть. Это рядовая рутинная работа, где ошибиться сложно из-за той самой защиты. Однако чел умудрился, заюзав посттаск в конструкторе, от которой, как оказалось, тогда защиты не было (хз как сейчас, вряд ли есть). Фишка тут в том, что такую ошибку хуй найдешь и удалось поймать только из-за особенности работы планирования потоков (кажись на unix системах). Для того, чтобы сделать что-то потенциально опасное, нужно при создании задачи явно указать "да, я знаю, что это опасно, но я подумал и знаю, тут будет все ок". Например, если создаешь таску с сырым указателем на объект, то его надо обернуть в base::Unretained. Если ты не работал с нормальными абстракциями тасков и таскраннеров - это твой пробел. Не надо пытаться делать вид, что все это хуйня и достаточно знания стандартной библиотеки. Ну я уже понял, что ты настолько тупой, что не догнал, что я просто максимально упростил предлагаемый тобой тест. Ты предлагал написать в коде функции лок у другого класса. Вызвать функцию у другого класса, сделать анлок у другого класса. А потом в тесте нахуячить проверку, что вызван лок у другого класса, вызвана рабочая функция у другого класса, вызван анлок у другого класса. Я написал тоже самое. Присвоил единицу переменную у другого класса и проверил что присвоена единица. Такой же идиотизм, что предлагаешь ты. Но ты настолько тупой, что ты не можешь допереть, что я просто довел до абсурда твою технику тестирования. Мы уже поняли, как ты все делаешь. Ты сам это написал.

Напомню, как пишутся тесты от GR: локи - часть имплементации объектов connection и cache и при использовании этих объектов мы не должны проверять их имплементацию (они для нас черные ящики). Мы же не проверяем, когда выделяем память в куче, что там спинлок захватывается. Однако GR на полном серьезе предлагает так тестировать. Когда нормальный юнит-тест - это когда объект считается черным ящиком и мокаются его входы и выходы и проверяется, что когда мы подаем что-то на вход, то на выходе получаем ожидаемые значения (при необходимости - в нужном порядке). Некоторые многопоточные случаи можно провеять, подавая данные на вход в нужном порядке, но обычно в случае локов нужно минимизировать места, где их нужно использовать, внимательно их просмотреть (код с локами должен быть максимально простым). И стараться не использовать локи в большей части кода. Если класс с локами не удалось сделать простым, а локи в нем необходимы по каким-то причинам (производительность, например), то тогда надо делать для него что-то вроде многопоточных фаззинг тестов.

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

Лично купишь норм компики всем нашим юзерам? То, что в датацентрах решили, что лучше покупать больше железа, чем платить зп норм разработчикам - это ни для кого не секрет. Даже изобрели специальные языки для даунов, типа голанга. да я угараю расслабься ботан я понимаю все это, но тут надо тоже понимать что 16 гб оперативной памяти это минимальный стандарт в 2025 году будет мы до сих пор поддерживаем 32 битную версию браузера Но, конечно, изменение железа юзеров вносит свои коррективы. Например, раньше мультипоточное обращение к диску только вредило. С ссд все наоборот

Лично купишь норм компики всем нашим юзерам? То, что в датацентрах решили, что лучше покупать больше железа, чем платить зп норм разработчикам - это ни для кого не секрет. Даже изобрели специальные языки для даунов, типа голанга.

примеры не ракового геймплея Пример написан в том же посте. Разуй глаза.

В IMAX тупо разрешение выше, так как там более широкая пленка используется плюс экран гораздо больше. Ну и звук там естественно лучше, чем в стандартном кинотеатре, ибо там иногда пиздец бывает звук поставлен.

Потому что это порождает раковый геймплей, который ущербно выглядит. Я молчу про убогий дизайн оружия и доспехов. Но хуй с ним, нравится людям, чтобы все было побольше и поцветастее - хуй с ним. Но перекаты вымораживают. PS То есть, если чар блокирует щитом удар огромного босса - ладно хуй с ним, но когда он прямо под боссом перекатывается и ему ничего от этого нет - хуйня какая-то. Причем потом дс-гении приходят в другие игры и ставят минуса за то, что там нельзя перекатываться агрессивно (то есть, под последующую атаку).

А кто-то говорил, что это я зашореный, так как варюсь в одной кастрюле все время.

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

Надеюсь, прокомментирует каждый пост

Давай я напомню основные тезисы: 1) Тестировать многопоточные ошибки сложно. GR: Ахаха, вы просто не умеете писать тесты <далее приводит пример с тестированием имплементации>. 2) Вопрос, можно ли тестировать с помощью слипа. Тут я привожу пример реальной баги, где хуй проссышь, как надо было писать тест, чтобы ее надежно отлавливать. Но зато ее можно воспроизводить слипом. 3) GR несет хуйню по поводу примера, ибо ни разу не видел код, где счетчик ссылок лежит внутри объекта. 4) GR говорит, что такие указатели дерьмище и приводит пример продуманного shared_ptr. 5) GR говорит, что тестом, с миллиардом потоков, теребонькающих подозрительные классы, нельзя найти баг из моего примера. 6) GR говорит, что я не знаком с gmock, хотя знает, что я работаю над Яндекс.Браузером 7) Я сказал, что shared_ptr хуев, ибо делает две аллокации в куче, чтобы избежать которые надо использовать make_shared. 8) GR сказал, что shared_ptr охуенен и надежен, а еще в нем всегда используются атомики, но это хуйня, потому что атомики практически бесплатны 9) GR сказал, что я не прав, что нельзя передавать сырой указатель, пользуясь shared_ptr. Правда забыл упомянуть, что enable_shared_from_this нельзя использовать вместе с make_shared (привет двойная аллокация). 10) GR сказал, что лучше shared_ptr, чем ловить ошибки. И вообще, он пишет на си++, чтобы забивать на производительность, ибо язык и так быстрый. 11) GR приводит ссылку на гугловый кодстайл, который собственно о кодстайле, а не о том, какие библиотеки использовать. 12) GR думает, что суть в том, что гугл тоже юзает атомики, а не в том, что GR говорит, что они бесплатные или в том, что двойная аллокация - это плохо.

Уже потерял нить разговора? Бедный.

https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/styleguide/c++/c++-features.md#std_shared_ptr-banned Ты ссылаешься на общий гугловый гайдлайн, который применяется и к утилитам, написанным для мелкой задачи, в которых пилить свой фреймворк глупо.

А с чем я должен сравнивать? Для того, чтобы можно было себе что-то позволять, нужно знать какие там накладные расходы. Что тоже выделение памяти в куче как минимум приведет к прокручиванию спинлока, а в худшем случае к переходу в режим ядра. Что непопадание в кэш - это пиздец как плохо и сильно замедляет работу. А чтобы не сидеть и не думать, могу ли я позволить себе вот эти накладные расходы, проще писать всегда правильно, не используя заведомое говно, типа shared_ptr. Именно такая политика в google, касаемая всякого говна из std. У нас тут один коллега делает патч в llvm, потому что реализация перебора файлов в директории на Win в 10 раз медленнее нормальной. Ребята типа тебя написали во внутренней утилите перебор файлов с помощью std::filesystem, не задумываясь о последствиях. Действительно. И так нормально. Ребята, которые писали реализацию для clang тоже, похоже, думали, что и так нормально. Хули тут думать?

Я отнаследовался от потокобезопасного класса, включающего подсчет ссылок. Там нет ни слова про указатель в названии класса. Ага. Всего-то вставляет барьер памяти (не давая оптимизировать код), синхронизирует кэши в разных ядрах и не дает обращаться к ячейке памяти другим ядрам. "Почти" бесплатно. Ну если ты программист на си++, а не программист на Java/Python, как всеми уважаемый дуит, у которого все языки работают с одинаковой скоростью, то должно. Два выделения памяти - это лишние 16 байт накладных расходов, захват критической секции, а самое главное - фрагментированность памяти, мешающей кэшированию процессора. Плюс лишняя косвенная адресация. А так да, "Почти" бесплатно. Ты серьезно? Ты простейший код не понял, а там надо смотреть одни сплошные шаблоны.

Как он может ничего не стоить, если там нужен атомарный инкремент/декремент? То есть тебя не смущает, что без make_shared он выделяет память в куче дважды? Бля, раньше ты мне казался умнее. То ли ты тупой, то ли ты в своем болоте неплохо так деграднул со своими братишками. Так Goldrobot даже не догнал, что наследование у класса A нужно для добавления функция AddRef и ReleaseRef, чтобы не писать их в каждом классе вручную.

Класс A не является умным указателем. Ахаха.

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