Category: религия

Category was added automatically. Read all entries about "религия".

Dervish

ок наконец понял что такое регулярные типы в с++

https://abseil.io/blog/20180531-regular-types

речь идёт о том, что если и семантика и синтаксис создания, копирования и сравнения value-объектов соответствуют семантике нативного типа («делай как int»), то такой тип называют регулярным.
его практическое свойство - можно использовать в стандартных контейнерах/алгоритмах
самое важное свойство - понятность происходящего с ним

PS
в конце статьи — очень смешно смотреть, как приходится извививаться, ну ей богу как ёрш на сковородке, чтобы определить константность для объекта.
Ага, если изначально назвать 40 лет назад (и с тех пор пор по привычке считать) «объектом» часть стека абстрактной машины без какой-либо изоляции.

дык нет у нас «объекта», народ. именно об этом трудность определения константности нам и говорит.
нет изоляции, нет референциальной прозрачности, нет контроля вторичных эффектов.
если ЛЮБАЯ операция может залезть в наш объект и нарушить его инварианты, то у нас нет «объекта»
если глобальное состояние, изменившись, может нарушить инвариант произвольного объекта без контракта - у нас нет «объекта».
о том и речь уж сколько лет-то.
Dervish

shared pointers

давно подозревал, что постоянная возня руками с .data() умных указателей unique_ptr/QScopedPtr, особенно с передачей за пределы динамически созданного хозяина — намёк на плохой дизайн.
Время жизни жёстко контролируется в одном месте, а использование происходит в другом, и они никак не сцеплены.

Я преположил, что это хороший повод использовать Shared Pointers, но по сути дела они даже не размазывают контроль, а полностью лишают нас контроля — ведь любые ошибки обращения после уничтожения хозяина говорят о том, что МЫ не понимаем, как работает наша логика, а наш SharedPtr - это просто мини-сборщик мусора, который предотвратит падение программы но никак не починит наше неполное знание о её поведении.

Есть ещё вариант со схемой shared_ptr + weak_ptr - по сути дела это просто более технологический вариант проверки на NULL перед использованием указателя, и он тоже не никак не восполняет наше знание о поведении программы.

Есть подозрение, что сама схема «работник как ресурс» фундаментально эпистемологически порочна.
С другой стороны, чисто формально под эту категорию попадает... вообще всё
Dervish

Fire and Forget для транспортных слоёв

Пришлось за прошлый год работать над несколькими прикладными транспортными слоями.
Изначальная идея работы транспортов «мы тут пока набиваем очередь, а ты уже иди начинай отправлять», для краткости назовём эту идею Fire-and-Forget.

Она вероятно оказала нам очень плохую службу что в стеке синхронного протокола [redacted] over rs232, что (как я теперь понимаю) в универсальном транспорте over TCP.
Если наш код в однопоточном приложении чем-то занят и мы долго не будем заходить в универсальный транспорт по сигналу readyRead(), мы пропускаем получение комбинированной (транспорт + user) квитанции (на них выходит таймаут и мы признаём сообщение недоставленным). В синхронном протоколе [redacted] эту ситцацию я очень хорошо наблюдаю на стыке отправки первой короткой команды и второй длинной команды.

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

В синхронном протоколе [redacted] я отключил FnF
>> Отключаем раннюю отправку: пока клиент прикладного протокола не закончит закладку очереди полностью, протокол не начинает отправку через транспорт.
Пускай очередь набивается кусочками прикладных данных свои законные несколько сотен миллисекунд, подождём, некуда спешить.

Пропуски транспортных квитанций в универсальном транспорте:
Как я теперь понимаю, никаких подтверждений доставки в универсальном транспортном слое делать не нужно было - ни пользовательских, ни транспортных, ведь они не используются.
Мы уже работаем поверх надёжного сетевого транспорта TCP, а логически обрабатывать квитанции с точки зрения бизнес-логики реалистично никто не хочет, ведь это привело бы к безумному усложнению кода.
В результате от квитанций все просто отмахиваются - никого не интересует ни пользовательский ответ, ни вывод транспорта об успешности доставки.

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

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

TL;DR: Fire and Forget плохая идея, если не доказано обратное.
Никогда такого не было, и вот опять — пустая погоня за воображаемой производительностью вылилась в логические ошибки.
Dervish

добавить *пустой* макрос в проект

вот например такой классический код, который я не хочу/не могу менять:


#if defined WIN32
#ifdef SUPER_API_EXPORTS
#define SUPER_API __declspec(dllexport)
#else
#define SUPER_API __declspec(dllimport)
#endif
#elif defined __linux
#define SUPER_API __attribute__ ((visibility ("default")))
#endif

class SUPER_API AwesomeApi {
...
}


если я хочу использовать код AwesomeApi напрямую, не собирая библиотеку, а просто добавив файлы в свой проект, мне будет мешать токен «SUPER_API», а просто так добавить в дефайны SUPER_API не прокатит!

[10.09.2019 15:52:44] я всегда думал что пустой дефайн ни во что не разворачивается в коде и таким образом никак не должен мешать. но это неверно.
[10.09.2019 15:52:50] By default, the value associated with a symbol is 1. For example, /Dname is equivalent to /Dname=1.
https://docs.microsoft.com/en-us/cpp/build/reference/d-preprocessor-definitions?redirectedfrom=MSDN&view=vs-2019

таким образом, нужно специально определить макрос SUPER_API как пробел:
для Microsoft Visual Studio (свойства проекта .vcxproj, C++ -> Препроцессор -> свойство Определения препроцессора):
SUPER_API= ; (пробел, затем точка с запятой!)
для QMake (синтаксис .pro-файла):
DEFINES += SUPER_API=" "
для MSVS, голая команданая строка компилятора cl.exe:
-DSUPER_API= (NB: обязательно дополнительный пробел после знака равенства!)
Dervish

внезапно, нельзя использовать const char* в роли ключа в словаре!

внезапно, нельзя использовать const char* в роли ключа в словаре!
потому что не просто сломается, а сломается по разному в зависимости от реализации словаря!
для дерева дефолтный компаратор будет сравнивать указатели, а не их содержимое, и обращение по ключу с проверкой будет вызывать out_of_bounds
а хеш-таблица будет хешировать опять же не сам литерал, а разумеется его (уникальный) указатель, что, подозреваю, не приведёт к падениям, но приведёт к неявному мультимэпу в случае наличия двух одинаковых литералов (например из разных единиц компиляции), но с двумя разными указателями
a god is you

внезапно ещё задумался про религию

может ли вера являться неким неизбежным экзистенциальным артефактом самого сознания, некоей «физиологически» обусловленной отдачей, онтологической «наводкой» от нашего же self-loop?
или может быть артефактом когнитивной структуры конкретно стайных приматов, а скажем гипотетические мозговитые вороны не будут ей подвержены?
Dervish

AWS Lambda

до вездесущего вычислительного субстсрата пока далеко, но это уже безумно круто.

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

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

вменяемые (sic) поинты против Google memo

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

https://medium.com/@yonatanzunger/so-about-this-googlers-manifesto-1e3773ed1788

кстати, пиар-департамент гугла очень беспомощен. они не только отреагировали очень вяло, но и не сделали хоть какой-либо damage control, не попытались дать какое-то вменяемое имя ивенту, который теперь повсюду известен (unhelpfully) как «мемо из гугла». лучше бы начали кричать имя автора на каждому углу. и уникальное название событию было бы, и автор бы получил заслуженно то, чего пытался добиться.

дополнительно, что науке известно про эту табуированную тему:
https://www.recode.net/2017/8/11/16127992/google-engineer-memo-research-science-women-biology-tech-james-damore
(хинт: известно мало, но всё то, что известно, указывает скорее на ничтожность различий в этом вопросе. различия конечно же есть, они конечно же важные, и... подобные скандалы мешают всерьёз их исследовать)
Dervish

c++ move semantics : БЕЗНОГNМ БЕЗλМНРIW

моя бошка уже немного пухнет, но вот что я понял.

std::move(x) ничего не двигает. оно просто приводит тип к rvalue (&&x), то есть мы явно говорим что объект x нам больше не нужен.

втихую move contructor генерится только для POD (не совсем так, но смысл именно такой).
совершенно точно нельзя передвинуть класс, если у него явно запрещён copy contructor и при этом не определён явно move contructor.

есть некий middle gorund вида const T& ← &&T , то есть rvalue will bind to a const lvalue reference
то есть, класс с нетривиальным конструктором можно передвинуть, если он is_move_contructible<T>, то есть std::is_constructible<T,T&&> (его можно сконструировать из rvalue)
например так работает конструктор копирования из T(const T&) и инициализирует T из временного выражения &&T

иными словами, подвинуть некопируемый объект нельзя. никак. нихт. нада.
такие классы нужно инстанцировать в хозяйствующий указыватель unique_ptr<T> и передвигать это хозяйство с помощью std::move(unique_ptr<T>)
в частности, никак невозможно и нельзя подвинуть QObject, и это by design, именно потому что правильно скопировать identity class (уникальный объект) просто невозможно по определению.
для этого у них у всех запрещены конструктор T(const T&) и присваиватель T& operator=(const T&) макросом Q_DISABLE_COPY


а вот RVO всё может, потому что он не языковая механика, а компиляторная.