mayton2019

Более интересный вопрос - как работают меж-банковские переводы. Как SWIFT работает? Как у него
баланс выглядит. И есть ли он там вообще? Как можно жить в условиях CQRS и eventual consistency?

Вот это мне кажется более интересные вопросы чем просто транзакции внутри банка.

Данная задача решается мета-программированием. Это предполагает 2 фазы компилляции. Поскольку
речь идет о языке С. У нас нет рефлексии и нет шаблонов. То я вижу только такой выход.

Вобщем 2 фазы. В первой фазе - объявить структуру TS1 в каком-то обобщенном формате.
Например в JSON.

{
  "struct" : {
    "name" : "TS1",
    "fields" : [
      { "name" : "a", "type" : "int" },
      { "name" : "b", "type" : "int" }
    ]
  }
}

И сгенерировать из этой структуры код для декларации ее в языке C и для форматной
печати через printf.

Жесткий диск на 4 Тб под хранение файлов планирую отформатировать в exfat.

По дизайну, exfat задумывалась как файловая система для флешек и SSD устройств. Там целая совокупность
фич дизайнилась именно для таких юзкейсов. Поэтому ставя exfat на магнитный HDD ты по любому
делаешь как-бы не-целевое использование этой системы.
К каким последствиям это приведет - я не знаю. Не было у меня таких экспериментов.

Но вот у меня есть 2 внешних HDD в резиновом корпусе (для фильмов и сериалов) и они отформатированы
в NTFS тем не менее прекрасно используются в двух ПК на Windows/Ubuntu и на телевизоре Toshiba.

Что ты там еще про MacOS написал - вообще непонятно. Вроде как в заголовке очевидно что тебе нужно 2 операционки. Так две или три?

Плюс, наверное, не надо будет дефрагментацию на этом диске делать, быстрее всё будет работать, да?

Вот реально уже десяток лет я не слышал чтобы кто-то серъезно озадачивался именно процессом дефрагментации.
Это знаешь ... как гомеопатия. Все говорят что полезно. Но никто никогда не мог в деньгах в долларах или в минутах
посчитать пользу от этого мероприятия. Для SSD например это задача почти бесполезная. А для магнитных дисков
роль в последнее время в бытовых ПК отведена именно как хранилище фильмов и файлов с редким доступом.
Ну да лет 10 назад для Oracle DBMS для раздела redo-logs на магнитных блинах еще можно было что-то там
обсудить. Или жарко поспорить. Сегодня - всем плевать. Даже девопсы этим не занимаются уже.

Вобщем дефрагментация - это гомеопатия. Да и современные ФС - тяготеют к автоматическому само-обслуживаю
в этом плане. На эту тему можно посмотреть в Zfs например. Что у них там?

famsssss это ETL с нормализацией. Задача - типичная.
У тебя должен быть примерно такой план действий.

1) Таблицы vak, ring, mdb, cat, spec нужно загрузить в БД как есть. В денормализованном виде. Если они лежат в excel - то сохранить их как CSV формат. Далее дело техники. Можете задать другой вопрос в qna по поводу того как их грузить.

2) Надо нарисовать реляционную модель. Это примерно то что ты рисуешь в картинке но нужно рисовать от сущности-связи а не от того какие файлы даны. Например есть сущность ISNN. У нее есть какие-то атрибуты. Они возможно опциональные. Но они должны быть перечислены. Далее - другие сущности. Потом определяем связи между ними. Например если многим spec соотвествует один ISNN - то тип связи будет многие к одному. Бывает такое что между двумя сущностями связи многие-ко-многим. Как прямоугольная матрица где по горизонтали одна сущность а по вертикали - другая и на пересечении стоит YES когда связь в наличии. Это тоже можно. Это делается через промежуточную таблицу. Связи бывают рекурсивные (таблица может указывать сама на себя). И в РМ могут быть циклы и петли. Это тоже допускается. Просто в этом случае между сущностями будут несколько вариантов как их джойнить и все варианты верны.

3) После того как Реляционная Модель (РМ) определена - в нее можно загружать данные. Можно грузить через INSERT/UPDATE/MERGE. И если возможностей не хватит то можно брать хранимые процедуры на Postgres. Но обычно мне хватало и SQL. В крайнем случае можно брать языки типа Python, Ruby e.t.c. если например доменная модель ооооочень сложная и надо какие-то делать неочевидные поиски по коллекциям или работать с JSON/XML но у тебя вроде все атомарно и лежит просто в ячейках. Должно хватить SQL.

4) Последняя таблица izdanya - по смыслу является отчетом из основной модели. Я настаиваю именно на таком подходе. Физически - это может быть view или таблица неважно. Главное что она - вторична по отношению к модели.

Нужен еще один аргумент. Типа глубина рекурсии чтоб делать отступы. Ну и внутри функции печатать на экран. Чем больше level тем больше отступ от левого края.

int translateNumberSystem(int num, int p, int level)
{
    if (num == 0)
    {
        return 0;
    }
    return (num % p + 10 * translateNumberSystem(num / p, p, level + 1));
}

Нужно проверить все обращения к векторам

vector<vector<int>> matrix;
vector<int>res;

по индексу. Используется больше элементов чем выделено.

Автор и не жди решения на блюдечке. Давай начинай все проверять. Тестирование - это тоже активность разработчика и никто ее за тебя не сделает.

P.S. Странно что за 30 лет С++ std так и не обзавелся типом "матрица". Бедняги разработчики до сих пор используют вложенные вектора. Или зубчатые вектора.

Для недорогих облачных хранилищ обычно используют
AWS/S3, MS-Azure BlobStorage, Google Cloud Storage.

В топике непонятно что автор имеет в виду под превосходством.

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

Могу констатировать в живых примерах что ядро линукс уже содержит 55 исходников на rust (по состоянию
на 5/13/2023) и следовательно кому-то это надо. Кто-то заказал внедрение нового компиллятора.
Видимо язык С уже не устраивал. Я пытался просмотреть эти сорцы но моих знаний Rust и Linux kernel
разработки пока не хватает чтобы дать хоть какой-то внятный комментарий по поводу. Ну раз коммитеры
вкоммитили значит все таки было очень нужно.

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

Про Mozilla тоже можно посмотреть. Возможно там найдуться примеры где было на С++ и стало на Rust.
Ведь это по сути была главная причина возникновения самого языка Rust.

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

Если тебе нравиться просто так развлекаться - то развлекайся. Но это нельзя признать
эффективным обучением. Подумай о том что другие люди ищут курсы (платные или бесплатные)
и смотрят их и делают задания по плану.

И как ты думаешь что быстрее и больше усвоит материала?

Не Фортист. Но я-бы обозвал себя Форт-любознательный. Что такое вообще мета-программирование.
Вики определяет так

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

Туда-же до кучи кидают и макросы и кодо-генерацию. Достаточно общо. Мне это и нравится
и не нравится. Нравится тем что в топике Форта безо всякой конкретики мы можем
крутить это определение как есть и натягивать его как сову на мячик.

Что вообще есть в языке Форт. Макросы? Вроде там весь синтаксис - это слова (words). И можно определять
новые слова и переопределять старые. Например вместо цифры 2 можно определить 3. Вот даже так.

Про кодо-генерацию говорить не интересно. Форт - язык для встраиваемой техники и микро-контроллеров
и таких вобщем-то задач как кодогенерация в ентерпрайзе и финтехе - вобщем -то нету. Тоесть типичная
задача генерации ORM-Entities где на вход приходит реляционная БД со схемой а на выходе например
C#/Java код с готовыми сущностями - неспецифичная для Форт. Ну нету такой потребности.

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

Вот эта конструкция берет с вершины стека число и считает целое число в кубе.

CUBE DUP DUP * * ;

Функция или макрос? Вот если макрос - то я уже мета-программирую. Тоесть
форт мета-программирует постоянно.

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

Есть китайское зарядное устройство. Размером с обычное мобильное.
На вход - 12 Вольт от аккумулятора. На выходе USB-TypeC стабилизированное
и с интеллектом для регулировки тока.

На нем ноубтук проживет очень долго.

А инвертор в этой схеме не нужен. Он - оверинжинеринг.

Никто не сможет ответить на твой вопрос точно. Память Flash/Nand утекает от длительного неиспользования. Когда она утечет - через 1 год или через 5 лет это наверное тоже зависит от кучи параметров типа новизны телефона и типа внутреннего диска.

Поэтому тут можно ответить как "бабка надвое сказала". Или помру или нет.

Автор беспокоиться о максимальной длине POST-запроса.

Я-бы просто предложил не беспокоиться а провести тестирование корнер-кейсов. Ввести там пароль
в 256 символов. Или в 64К символов. Или в 4 гигабайта символов.

И уже пойти от конкретной проблемы.

А то получается что человек пришел и говорит. Вот... что-то меня беспокоит. Но я не знаю что.
Помогите доктор. С чем-то...

Вот тут пишут как https://stackoverflow.com/questions/16678487/wget-...

Поскольку топик тегирован PHP то я-бы предложил взять PHP фреймворки и смотреть как они видят себе реализацию шаблона например репозиторий. Я-бы мог рассказать о Spring Data Repository но боюсь что для PHP будут отличия и автор просто запутается.

Банда Четырех (юбилейное издание) описывает шаблоны проектирования .... эээ кажется на SmallTalk и С++. По крайней мере во Введении книги они об этом писали. Поэтому читая код надо уметь читать глазами сущности этого мира и не пугаться.

Что такое шаблон Store - я не знаю. Опять-же это специфика PHP скорее всего.

Что такое шаблон Сервис. Ну я вообще не рискнул бы его никак определять. Это КМК слишком размытое понятие и его надо срочно сузить. Хотя-бы до уровня техно-стека. Может сервис в терминологии SOAP это одно. Облачный сервис - может быть вообще другое. Короче архитекторы этих технологий будут бить друг друга здесь как епископы разных церквей друг друга за ереси.

Сервис для ООП - вообще седьмая вода на киселе. Вообще ООП надо начать и закончить на его полиморфизмах и наследованиях и поставить точку. Дальше - нет ООП. Дальше идет хаос и новые виды абстракций от вендора языка. Аннотации и аспекты и рефлексия и прочий бред.