Станислав Макаров

Да. Такие эксперименты были. Лет 5 назад когда был еще жив sql.ru, один человек продвигал
модель т.н. квинтетов. Это таблица с 5 полями которая полностью описывала любую
доменную область. Я к сожалению не могу нигде найти следов описания этой системы
но возможно это оно https://cyclowiki.org/wiki/QDM . Читайте смотрите.

Второе. В эпоху новых версий DBMS (Oracle/PG/MySQL) когда мы можем использовать
JSON/XML внутри ячейки, сама идея EAV теряет смысл. Поле атомарно? Атомарно.
Значит законы реляционной алгебры мы не нарушаем и JSON совершенно легальный
тип для реляционок. Хотя лет 30 назад его использование было-бы кощунством
в БД. Но это можно было списать на жесткую экономию ресурсов и чрезмерную
математичность моделей Бойса-Кодда. Сегодня все используют JSON и нет никаких
архитектурных доводов против. Поэтому создавайте NoSQL табличку где есть
key и есть значение в виде либерального типа документа. Как делают MongoDb, CouchDb.
И если связать их в иерархию то получится вполне себе те-же самые квинтеты.

Про EAV лучше забудьте. Их любят преподаватели SQL и теоретики. Но практически EAV
слишком медленно работает чтобы развивать его в бизнес-приложении или в промышленности.
Мир тяготеет к упрощению. И поэтому JSON - это упрощение EAV. И работает быстрее.

xaml лишь язык разметки..
все элементы доступны в коде...
почти как в winforms..
MSDN в помощь

можно подумать, что при объявлении указателя, символ * относится к имени(не как часть, а как что-то зависящее от него), а не к типу.

Если взять стандарт языка (например C99) и почитать главы Declarations, Type Specifiers и Declarators, то можно увидеть, что он разделяет declaration-specifiers, в который входят только слова и declarators, в который входят скобочки и звёздочки. Т.е. твой вывод по сути верный.

Там же можно увидеть, что часть называемую declarator всегда можно обернуть в скобки, из чего можно извлечь следующий вывод: часть объявления вокруг которой можно поставить скобки самым широким образом относится к конкретному идентификатору, оставшаяся часть -- ко всему списку. Т.е. const char *a, b; можно превратить в const char (*a), b, но нельзя превратить в const (char *a), b или в char (const *a), b.

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

Скорее всего проблема в кодировке файла. Попробуй сконвертировать формат файла в utf-8, если другой, и дополнительно смени тип новой строки с \r\n на \n (не уверен, что важно)

https://ftp.ripe.net/ripe/dbase/split/

Вот здесь все файлы, что вам потребуются. Преобразовать в формат БД можно, например, с помощью https://github.com/firefart/network_info

если у вас vector/array используйте std::variant или std::optional в качестве шаблонного параметра
в случае С-array, используйте указатель на тип
вот пример:

#include <iostream>
#include <vector>
#include <optional>

int main() {
    std::vector<std::optional<int>> vec;
    vec.push_back(10);
    vec.push_back(std::nullopt);
    vec.push_back(15);
    for (auto i : vec) {
        if (*i) {
            std::cout << *i << std::endl;
        } else {
            std::cout << "value is not exist\n";
        }
    }

    return 0;
}

srand вызывайте только один раз где-нибудь в начале программы. А потом сколько угодно раз используйте rand.

srand устанавливает состояние генератора псевдослучайных чисел. В качестве seed вы там используете количество миллисекунд, которое целую миллисекунду одинаковое, поэтому состояние генератора у вас в каждой функции rand_offer одно и то же - поэтому числа и генерируются одни и теже. sleep(1) лечит проблему потому, что следующий вызов посчитает другое значение count_ms.

Таблицы на основе генераторов или sequences обычно ствавят главной задачей - обеспечить
уникальность id в первую очередь. С эти sequence справляется.

Гарантировать блокировку или захват sequence они не могут так как Postgres создавался
как много-пользовательская БД. Тоесть много сессий обладают правом в любой момент
взять из sequence следующее значение. Поэтому требование хронологии - это как эксклюзивный
лок объекта. Слишком жесткое требование. И никому не нужное. Если б так БД работали то
они теряли бы в производительности и ждали-бы чтоб какая-то главная сессия отпустила таблицу.

Выход есть - брать ранг записи извне. Тоесть само приложение должно быть поставщиком
таких номеров. А БД будет просто их вставлять.

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

Все до безобразия просто:
Вы выделяете память в момент, когда она вам нужна, а удаляете когда эта память вам более не нужна.
Соотвественно, вам нужна функция array_deinit(), которая возьмет на себя непосильную ношу освобождения памяти в момент, когда вы больше не планируете обращаться к своему двумерному массиву.

В простейшем случае, в С++ подобный функционал оборачивают в класс, который, в свою очередь, обязательно должен почистить за собой память хотя бы в деструкторе.

Также в современном С++ не принято использовать new/delete без веской причины (например, вы пишете супер быстрый, современный контейнер, в котором хотите управлять всеми аллокациями самостоятельно), а рекомендуется использовать умные указатели для работы с памятью.

fixed запрещает перемещать объект в памяти.
Сборщик мусора может и не соберёт объект, но без fixed он может его переместить и тогда указатель станет невалидным.

stackalloc выделяет данные на стеке, а по тому с ним такой проблемы нет, ну и да - он не нагружает gc, хоть и обладает кое-какими другими потенциальными проблемами.

Единственный такой проект, о котором я слышал — это разработка ядра Linux. Там изначально велась разработка по почте. Да и сейчас кажется ничего не изменилось. На гитхабе мы видим лишь зеркало проекта. Гит изначально был придуман Торвальдсом специально так, чтобы он максимально прозрачно интегрировался в такой процесс. Даже коммиты при просмотре выглядят как электронные письма — там есть имя и мыло автора, тема, тело с подробным описанием изменений…

А ответ на вопрос «как?» вы найдете в официальной книге Pro Git. Там этому посвящена целая глава. Учебник продолжает дополняться и переписываться сообществом, в том числе и на русском.