Victor Bomberow

Хочу порекомендовать тебе материал от разработчиков PVS-Studio относительно моделей данных в C++. Там хорошо и коротко объясняется суть твоего вопроса.
Так же тебе будет полезно изучить документацию C++, где можно изучить подробности.

Модель данных выбирается при трансляции и не может быть изменена в уже собранном бинарном коде. Абсолютно весь бинарный код опирается на значения модели данных буквально в каждый момент времени исполнения. Изменение модели данных бинарного кода потребует детального анализа как исполняемого кода, так и всех структур памяти, которыми бинарный код оперирует. Это будет эквивалентно повторной трансляции исходного кода в бинарный с иной моделью данных.

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

Поэтому, в общем смысле на твой вопрос ответить можно так. Если клиентская система ожидает от процесса одну модель данных, а он работает в другой, то падения процесса не миновать. В ряде случаев процесс даже не загрузится в память, т.к. загрузчик бинарного кода может по косвенным признакам определить несовместимость процесса и системы у клиента.

1. Округление к чётному. Это стандартное округление к ближайшему; если расстояние одинаково — то к чётному.
4,4 → 4
4,5 → 4
4,6 → 5
−4,4 → −4
−4,5 → −4
−4,6 → −5
5,4 → 5
5,5 → 6
5,6 → 6
−5,4 → −5
−5,5 → −6
−5,6 → −6

2. Округление вниз к −∞. Округление к меньшему.
4,xxx → 4 (при любой дробной части)
−4,xxx → −5

3. Округление вверх к +∞. Округление к бóльшему.
4,xxx → 5
−4,xxx → −4

4. Отбрасывание дробной части. Округление к 0. Округление к меньшему по модулю.
4,xxx → 4
−4,xxx → −4

Столько много знаков у double — так что где-то в недрах библиотеки float стал double’ом. Знаков у float не точно 7, а чуть больше семи. И это число действительно не тройка: тройка имеет 16-й вид 4040.0000, а ваше число — 403F.FFFF. Как вы видите, величина единицы младшего разряда (ULP) на таких величинах будет около 2,4·10⁻⁷ — поболее семи знаков будет, но до восьми не дотягивает.

Механизмы округления IEEE 754 не имеют никакого отношения к десятичному округлению, прописанному в библиотеке языка. Округление IEEE на самом деле двоичное и используется при переводе из более точного типа в менее точный, или чтобы округлить результат умножения/деления.

Согласно ортографической геометрии полей, non-orthogonal basis используется в вычислении полеморфических квантовых фигур в небазесном пространстве. Если найти расстояние между двумя точками, то можно в теории измерить поверхность полиморфной фигуры.

вы делаете записи какие то важные для вас, где то в текстовых файлах, чтобы зайти подсмотреть, шпаргалка так называемая ?

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

Под Linux, вроде, ничего не надо делать, стандартный терминал и так всё поддерживает, а ОС интерпретирует текст в char и string как UTF-8. Если хочешь Unicode под Windows, то добро пожаловать в адъ.

1. Убедись, что исходный код сохранён в UTF-8. Если Visual Studio, нужно немного потанцевать с бубном.
2. Куда вывести, в файл или в консоль? Вывести в стандартную консоль невозможно, нужно установить Windows Terminal, последнюю PowerShell и связать их (для этого ещё потанцевать с бубном).
3. В программе, перед тем как послать юникодную строку в ОС (например, перед тем как печатать), убедись, что ты перевёл её из UTF-8 в системную кодировку (которая обычно UTF-16). В стандартной библиотеке такого нет, нужно подключать либу. Вот что я юзаю с Boost и fmt:

namespace strings
{
    using native_char = boost::filesystem::path::value_type;
    using native_string = std::basic_string<native_char>;

    namespace detail
    {
        inline void write(const std::string& string)
        {
            std::cout.write(string.c_str(), string.size());
        }

        inline void write(const std::wstring& string)
        {
            std::wcout.write(string.c_str(), string.size());
        }
    }

    using fmt::format;

    template <typename S, typename... Args>
    void print(const S& format_str, Args&&... args)
    {
        const auto string = fmt::format(format_str, std::forward<Args>(args)...);
        detail::write(boost::locale::conv::utf_to_utf<native_char>(string));
    }

    using boost::locale::conv::utf_to_utf;
    using boost::locale::conv::from_utf;
    using boost::locale::conv::to_utf;
    using boost::locale::conv::between;

    inline native_string to_native(const std::string& utf8)
    {
        return utf_to_utf<native_char>(utf8);
    }

    inline std::string from_native(const native_string& native)
    {
        return utf_to_utf<char>(native);
    }
}

Это принципиально не корректная идея использования репозитория. В данном случае надо иметь отдельный репозиторий с ядром и несколько репозиториев с доп. функционалом. То есть 1 проект = 1 репозиторий.

Соединять репозитории можно либо через git modules (но мне не нравится этот способ), либо же любым удобным пакетным менеджером, например, тот же npm.

Ветки нужны только для временной разработки и последующего вливания в мастер

но на него не было нормального ответа(по-этому я и спросил)

90% ответов нормальных, просто они вам не нравятся, поскольку везде говорят что за что бы ты не взялся, вкалывать прийдется много, а получится или нет - зависит от тебя.
При этом не нужно такие ответы игнорировать, потому что так и есть. Жизнь это не сказка.

Учи любой язык. Вообще любой. Тебе до входа в профессию еще далеко, потому что новички, которые могут написать простенький тетрис - полно, и они никому особо не нужны. А для того, чтобы написать тетрис УЖЕ нужно знать немало.

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

Unit of Work - это паттерн определяющий логическую транзакцию т.е. атомарную синхронизацию изменений в объектах, помещённых в объект UoW с хранилищем (базой данных).

Если обратиться к исходному описанию этого паттерна у Мартина Фаулера - то видно что объект, реализующий этот паттерн отвечает за накопление информации о том какие объекты входят в транзакцию и каковы их изменния относительно исходных значений в хранилище. Основная работа производится в методе commit() который отвечает за вычисление изменений в сохранённых в UoW объектах и синхронизацию этих изменений с хранилищем (базой данных).

Паттерн Unit of Work как правило не является полностью самостоятельным, он обычно тесно связан с паттерном Identity Map, задача которого - сохранение карты созданных объектов, взятых из хранилища с тем чтобы гарантировать что одна единица информации из хранилища представлена ровно одним экземпляром объекта данных в приложении. Это позволяет избежать конфликтов изменений т.к. не допускает ситуации когда два объекта, представляющих один и тот же элемент данных в хранилище, изменены по-разному. Информация из Identity Map используется в методе commit() паттерна Unit of Work для вычисления разницы между исходными данными и накопленными изменениями.

Поскольку для вычисления разницы (и, соответственно, определения того что и каким образом должно быть изменено в хранилище) необходимо знать какие данные и как именно хранятся в объектах - как правило необходима также реализация паттерна Metadata Mapping, описывающего связь между содержимым хранилища (к примеру таблицами и столбцами базы данных) и классами / свойствами объектов.

Также, если данные в хранилище не являются независимыми (к примеру связи между таблицами в базе данных) - может потребоваться реализации ряда паттернов, отвечающих за сохранение информации о связях между данными (это паттерны раздела Object-Relational Structural Patterns в каталоге паттернов).

Подводя итог: сам по себе Unit of Work довольно прост в своём внешнем интерфейсе, но реализация его корректной работы требует предоставления множества дополнительных данных, поэтому миниатюрных примеров привести не могу.

Если говорить о PHP - то лучшей реализацией этих паттернов на PHP безусловно является Doctrine ORM. В частности в разделе Working with Objects документации Doctrine можно найти хорошее описание и множество примеров использования паттернов, описанных выше.

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

Вы забываете о большом пласте истории техники, который был сильно до этого - 8 битные домашние ЭВМ (десятки их) и язык Бейсик.

Так вот, ЭВМ того времени были катастрофически разными - разные носители (кассеты, дискеты, картриджи), разная аппаратура (засунуть еще один центральный процессор в дисковод? да нивапрос! разная скорость для PAL и NTSC версий - легко!). Но вот бейсик был везде и позволял, с некоторыми переделками, таскать программы с машины на машину.

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

Отчасти, это сработало на старых мобилках, в эпоху j2me - это как раз Java, засунутая в телефон - игры, браузеры, карты (были даже ЯндексКарты), читалки, чатилки - куча всего.

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

Сейчас апплет на java можно встретить во всяком старом железе, на нем там сделано GUI для удаленного администрирования серверов, коммутаторов и СХД. Вы браузером заходите на железку, и тут на вас вываливается ворох предупреждений о том, что сейчас будет запущено какое-то ужасное дырявое ПО, держите штаны, а то слетят. Уверены? Точно уверены? А с этим согласны? А так?

А уже потом начали активно применять JavaScript, главным образом, изобретя Ajax - продолжая люто натягивать сову (систему для создания электронных библиотек для ученых/HTML) на глобус (задачу создания интерактивного гуя с красивой версткой).

И это вы еще бэк на Perle не рефакторили

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

Проблема в том, что вопрос по теме, заданный в вакууме, да еще и на всеобщее обозрение, не показывает всю картину происходящего с человеком. Иногда нужно кучу времени потратить, чтобы человека просто один на один разговорить и он рассказал, а что на самом деле у него происходит. Что-то ему будет тяжело принять, что-то он бы не хотел распространять о себе или других людях (это кстати одна из причин, зачем нужна конфиденциальность в этом деле). Поэтому 99% советов, которые дадут в ответ на такой вопрос в сети не соответствуют контексту, в котором автор формулировал вопрос, и хорошо, если они не сделают ему хуже. А учитывая, что психологией программисты не занимаются – советы часто будут не только вне контекста, так еще и вредными по определению (как, например, популярный совет - взять на себя большую нагрузку, когда ты и так истощен до предела). Поэтому формат вопросов-ответов в том виде, в котором он есть на Хабр Q&A тут не годится.

Так что заводить такой тег именно здесь не имеет смысла. Он мало того, что будет непрофильным, так еще и пользы не принесет. Гораздо лучше задаться вопросом массового образования программистов – чтобы люди не только мыли руки после туалета, но и про психогигиену не забывали, чтобы проблемы не становились очевидными, когда уже все плохо и без врача и серьезных перемен в жизни не обойтись. Но задачка эта не из простых, конечно.

Toster Extension
Toster Comfort
Выбирайте ))

https://godbolt.org/z/ARYhis
Если посмотреть в пролог функции, она делает локальную копию нашей a. А желаемое место в стеке на 36 байтов выше, чем вы ищете.
Разумеется, всё под x86. Вызов под x64 подразумевает регистры.

UPD. А вот Интел не делает локальных копий и всё на месте.

Вопрос писать или не писать такую тривиальщину как роутер, сводится, в сущности, к вечному вопросу поддержки.

Написать десяток велосипедов не проблема.
Поддерживать один-два в актуальном состоянии - тоже.
Но может накопиться такое количество велосипедов, что их поддержка будет занимать все наличные ресурсы, и на разработку собственно функционала попросту не останется времени.

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

Во первых - готовый код - он разный. В частности данное утверждение подразумевает "готовое обкатанное, проверенное на многих использованиях, все основные косяки и грабли уже найдены и пофиксены".

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

В третьих - готовое распространенное решение проще поддерживать, завтра вы уйдете / перестанете поддерживать свое "творение", и другой разработчик вынужден будет разбираться в вашем произведении, матюкаясь что в одном месте "все прибито гвоздями", в другом "собрано из г**на и палок", в третьем "эти 30 строк пишутся одной тренарной операцией, кто это вообще писал???"... И вам потом икать, оно вам надо?

То есть, если вы уверены, что ваш код безглючен, выполняет то что надо и в 4 раза короче "готового решения" - вперед на мины, а если важнее надежность и фидбэк, вкупе со скоростью разработки - лучше взять популярное рабочее решение.

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