All streams
Search
Write a publication
Pull to refresh
5
1.8
Send message

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

Только тогда в пятимерном пространстве перемножать будете не два вектора, а четыре :-)

Серверная часть у них уже есть. По сути, нужен клиент + поддержка другого формата бандлов.

Чисто на случай, что с покупок из рустора им 30% не отстегнут :-). Так что уверен – вопрос тут финансовый.

Если будет API для установки стороннего софта – написать клиент не очень сложно.

Задаём вопрос ChatGPT, получаем более краткое и понятное разъяснение.

Но в общем и целом этот функционал не нужен, за его использование надо бить по рукам. Вместо него следует использовать factory function.

Сложное какое-то объяснение... Лучше на практике въехать: когда попадаешь в ситуацию, что без тестов требуемый функционал ну никак не вырисовывается (пишешь, запускаешь, 100500 действий, чтобы попробовать – нет, не то, и так раз за разом) – очень быстро соображаешь и про tests first, и про то, как их лучше писать.

Поэтому мы гарантируем, что "inline" отработает.

В таком варианте вроде понятно. По сути, получается относительно простое условие, когда можно примененять эту оптимизацию так, чтобы откатывать не пришлось (даже если дальнейшие оптимизации не пройдут – будет хотя бы инлайн ценой одной проверки)?

Обратите внимание на пример из статьи. Там вызов виртуальной функции превращается в несколько if, а затем (на случай, если это не один из учтённых вариантов) всё тот же вызов через vmt. Если так и оставить (не случилось никаких последующих оптимизаций) – возможно, это будет ничем не лучше изначального варианта (а может и будет: не знаю, отрабатывает ли предсказание переходов на косвенных вызовах).

Т.е. понятно, что если после этого преобразования получится, к примеру, вытащить if из цикла – у нас есть ускорение. А что делать, если ничего такого не получилось?

А компилятор может вначале применить спекулятивную девиртуализацию, а потом сказать "не пригодилось" (благодаря ей не открылись новые оптимизации) и откатить обратно?

Ранее в VK сообщили, что сотрудники центра безопасности мессенджера Max в июле 2025 года заблокировали (за нарушения пункта 4 «Права и обязанности Пользователя») более 10 тыс. телефонных номеров мошенников, которые чаще всего предпринимали попытки выдать себя за сотрудников банков, правоохранительных органов или государственных сервисов.

Я не понимаю. Почему для "сотрудников банков, правоохранительных органов или государственных сервисов" просто не сделан белый список? Классика же: верифицированные аккаунты. Это примерно единственное, что могло бы сделать этот мессенджер полезнее конкурентов.

Некоторые любят свою работу, и им не в кайф вместо неё бездельничать. А про учёт времени вы всё правильно говорите.

В воспроизведении и изоляции много тупого перебора – и эту работу точно есть резон передать роботу. Пусть человек ему идеи подаёт.

Поржал над заголовком. Не бывает много тестирования, если чатгпт научат хотя бы баги воспроизводить (убрав из описания страшное слово "sometimes") и изолировать (перебрав варианты воспроизведения и оставив минимальный) – уже праздник, ценность освоивших его тестировщиков резко возрастёт.

Любопытно, нельзя ли их рутовать через test point.

"Уточнение"? Да вы мастер преуменьшений. Вашу статью по сути похоронили одним очевидным любому программисту вопросом, показав вашу некомпетентность в освещаемом вопросе, а вы называете это "уточнением"?!

Санитайзинг – чистка от запрещённого (удалением или заменой, например 0x02 удалить или заменить на тире, как в статье). Эскейпинг – обратимая замена запрещённого (как в вашем примере для символов пунктуации).

В общем, всё вы знаете, только термины почему-то мимо прошли :-)

Глядите, если у вас есть N разных типов – то для каждого визитора вам надо написать N разных функций и положить их в него. А для switch – написать N разных case. И будете вы это писать ровно в том же месте. И даже компилятор проверит одинаково (все ли функции есть, если ваш визитор соответствует типу визитора, или все ли варианты тэга вписаны в case в случае switch).

Т.е. у вас точно так же расползётся всё по всему проекту, только ещё добавится фабрика.

Так что воспринимайте использование discriminated union, как visitor на минималках.

Для визитора надо не POD-типы, а полноценные объекты с VMT (ну или в случае JS – с лежащим в объекте или его прототипе "виртуальным" методом).

Соответственно, если эти объекты не в вашем же коде созданы, а, как это часто бывает в JS, пришли извне в сериализованном виде – для того, чтобы вы могли пользоваться визитором, вам всё равно вначале придётся их сконвертировать в "жирные" объекты со всеми методами – а для этого написать тот же switch-case или ещё что. Зачастую это перебор.

Information

Rating
1,390-th
Registered
Activity