Budget: 7500 UAH Deadline: 1 day
I do it in 1 day, I use Clion. I will describe and explain everything in detail. If necessary, I will detail the work of the program. Write in Personal Messages
Нужно реализовать B+ дерево на c++. Лабораторная работа 1 курса. У самого не получается.
Понимаю идею, но возникли сложности с языком, не могу реализовать даже операцию вставки. Запутался в выделении памяти.
Задача: написать ОСНОВНЫЕ методы: вставка, удаление, и необходимые для них. Убедится, что проходят тесты на эти методы. + я хочу понимать весь код, поэтому нужна zoom встреча, на который вы бы могли объяснить как что написано(~1 час). После этого, я бы написал остальное: итераторы, операторы... ии вслучае проблем, снова бы обратился к вам за помощью.
Прилагаю readme файл, как что должно быть написано.
НЕ НАДО копировать код с интернета, т.к. код должен быть уникальным.
Кто готов, отпишитесь, более подробно объясню, потом уже скину начальный проект, тесты...
Желательно работать в Clion.
Дедлайн: как можно быстрей, хочется чтобы через 4 дня уже были insert+erase+основные тесты.
По цене, договоримся.
Текст задачи в readme.
# B+ дерево
## Потребность в блочных структурах данных
Организация памяти в вычислительных системах сложна и иерархична, с существенным ростом стоимости доступа к каждому следующему уровню.
Поэтому выгодными оказываются блочные схемы обращения к памяти - когда за раз читается относительно большой непрерывный блок данных, даже если это повлечёт
за собой дополнительный вычислительные затраты на его обработку.
Особенно актуальна блочная организация для хранения данных на HDD - скорость случайного доступа у дисков очень низка и выгода от чтения больших блоков
весьма существенна.
Пример:
* Процессор с частотой 1 Гц
* Скорость доступа к кешу процессора - примерно 10 тактов = 10 нс
* Скорость доступа к ОЗУ - примерно 100 тактов = 100 нс
* Скорость доступа к HDD (время перемещения головки) - примерно 10 мс - медленнее ОЗУ в 10^5 раз
## Идея
B+ дерево - это дерево с более высокой степенью ветвления (порядком), нежели двоичное. Внутренние узлы дерева порядка N могут иметь от ceil(N/2) до N потомков.
Порядок дерева - не меньше 3.
Корень дерева может иметь от 2 до N потомков.
Внутренние узлы дерева хранят только ключи и ссылки на потомков.
Листья дерева содержат ключи и значения, каждый лист может содержать от N/2 до N пар ключ-значение. Листья связаны в односвязный список, что позволяет эффективно
реализовывать поиск интервалов.
Подробнее можно ознакомиться с идеей B+ дерева в [статье википедии](https://en.wikipedia.org/wiki/B%2B_tree).
Другое описание см. [здесь](http://www.cburch.com/cs/340/reading/btree/index.html).
Основных отличия от двоичных деревьев несколько:
* узлы гораздо большего размера, хранят много ключей
* внутренние узлы хранят только ключи и ссылки на потомков, любой поиск сопряжён со спуском до листа
* листья связаны в односвязный список, что позволяет эффективно получать интервалы
Обычно размер узла делают достаточно существенным, чтобы читать данные большими блоками. Например, если на хранение ключа и ссылки на потомка требуется 32 байта,
размер узла - 4096 байт, то порядок дерева = 128. Если требуется хранить в таком дереве 10^7 элементов, то высота его будет варьироваться от 4 до 5 - то есть,
любой поиск будет сопряжён максимум с 5 чтениями. Сравните с бинарным деревом - у идеально сбалансированного дерева на 10^7 элементов высота будет равна 23.
## Постановка задачи
Требуется реализовать шаблонный ассоциативный массив с интерфейсом, во многом подобным `std::map`.
Предполагается, что все хранимые ключи уникальны (как и с `std::map`).
Нужно реализовать основные функции типичной коллекции:
* проверка размера и очистка
* провера наличия ключа
* поиск элемента по ключу
* прямой доступ к элементу по ключу
* добавление и удаление элементов
* поддержка задания произвольного компаратора
В основе реализации должно лежать B+ дерево. Его порядок не фиксирован и выбирается исходя из размера хранимых типов так, чтобы обеспечить фиксированный
размер блока, задаваемый шаблонным параметром класса дерева, значение по умолчанию - 4096 байт.
Предельная заполненной блока должна быть максимально возможной, например, если для обслуживания 1 ключа во внутреннем блоке
требуется 100 байт, то порядок дерева будет равен 40.
Допускается во внутренних узлах иметь дополнительные накладные расходы в виде размер ключа + размер указателя (т.е. при эффективной вместимости узла в `K` ключей,
отводить место под `K+1`), это может упростить реализацию.
Помимо этого предполагается, что внутренние узлы имеют место для хранения `K` ключей и `K+1` указателей, а также хранят количество присутствующих ключей.
Таким образом, `K` можно определить как `(BlockSize - sizeof(std::size_t) - sizeof(void *)) / (sizeof(Key) + sizeof(void *))`.
Листья имеют тот же размер, который используют для хранения пар ключ-значение, количества присутствующих пар и указателя на следующий лист.
Возможность задания произвольных типов ключей и значений нарушает идею "блочной" структуры данных: к примеру, `std::string` выделяет память под своё значение
самостоятельно и на это сложно повлиять. Тем не менее, по сравнению с `std::map`, такое B+ дерево всё-таки будет "блочным" - доступ к одному узлу даст множество
ключей, а не один.
Итераторы коллекции должны иметь категорию forward.
Допустимы следующие упрощения:
* можно игнорировать служебные расходы на организацию классов (например, для поддержки виртуальных функций); достаточно, если в заданный размер блока укладывается
всё явно определённое содержимое узла
* можно игнорировать то, что некоторые классы ключей или значений могут самостоятельно выделять память; достаточно упаковать в заданный размер блока сами объекты
ключей и значений (и иные вспомогательные поля классов узлов)
* разное количество ключей во внутренних узлах и листьях: размер блока распространяется на оба типа узлов, но если внутренние узлы помимо ключей содержат ссылки на
потомков, то листья содержат помимо ключей - объекты значений, размер которых может отличаться от затрат на представление ссылок
## Требуемый интерфейс
```c++
template <class Key, class Value, std::size_t BlockSize, class Less = std::less<Key>>
class BPTree
{
public:
using key_type = Key;
using mapped_type = Value;
using value_type = std::pair<Key, Value>; // NB: a digression from std::map
using reference = value_type &;
using const_reference = const value_type &;
using pointer = value_type *;
using const_pointer = const value_type *;
using size_type = std::size_t;
using iterator = ...;
using const_iterator = ...;
BPTree(std::initializer_list<std::pair<Key, Value>>);
BPTree(const BPTree &);
BPTree(BPTree &&);
iterator begin();
const_iterator cbegin() const;
const_iterator begin() const;
iterator end();
const_iterator cend() const;
const_iterator end() const;
bool empty() const;
size_type size() const;
void clear();
size_type count(const Key &) const;
bool contains(const Key &) const;
std::pair<iterator, iterator> equal_range(const Key &);
std::pair<const_iterator, const_iterator> equal_range(const Key &) const;
iterator lower_bound(const Key &);
const_iterator lower_bound(const Key &) const;
iterator upper_bound(const Key &);
const_iterator upper_bound(const Key &) const;
iterator find(const Key & key);
const_iterator find(const Key & key) const;
// 'at' method throws std::out_of_range if there is no such key
Value & at(const Key &);
const Value & at(const Key &) const;
// '[]' operator inserts a new element if there is no such key
Value & operator[] (const Key &);
std::pair<iterator, bool> insert(const Key &, const Value &); // NB: a digression from std::map
std::pair<iterator, bool> insert(const Key &, Value &&); // NB: a digression from std::map
template <class ForwardIt>
void insert(ForwardIt begin, ForwardIt end);
void insert(std::initializer_list<value_type>);
iterator erase(const_iterator);
iterator erase(const_iterator, const_iterator);
size_type erase(const Key &);
};
```
## Рекомендации
Данная структура данных весьма проста идейно, но её реализация оказывается довольно сложной. Причём эта сложность не алгоритмическая, а во многом связана с организацией
структуры на конкретном языке. Самая сложная операция - удаления. Попробуйте для начала отключить тесты, требующие операций удаления и реализовать только вставку.
У некоторых авторов возникает желание добавить горизонтальные связи между внутренними узлами дерева - лучше от этого воздержаться, т.к. только операция удаления может
получить от этого какой-то выигрыш, но для удаления вам всё равно понадобятся сложные вертикальные манипуляции и соседа можно получить через родителя.
Если допустить возможность временного переполнения внутренних узлов при вставке (см. выше про допустимые накладные расходы), то операцию вставки во внутренний узел
можно сильно упростить выделив две раздельные стадии - вставку и расщепление.
Говорят, что на викиконспектах ИТМО в описании операций над B+ деревом есть ошибки или неточности.
При возникновении проблем, попробуйте воспроизвести каждую из них по отдельности, написав минимальный юнит-тест (за хорошие тесты вы можете получить дополнительные баллы).
Budget: 7500 UAH Deadline: 1 day
I do it in 1 day, I use Clion. I will describe and explain everything in detail. If necessary, I will detail the work of the program. Write in Personal Messages
Budget: 1500 UAH Deadline: 5 days
Good day .
I have experience writing programs with different data structures.
I am ready to discuss the conditions of cooperation with you.
Thank you for attention.
Budget: 1000 UAH Deadline: 2 days
Hello, I have experience in doing such tasks, I will do within 2 days.
A patch is required for the graphics card driver that expands the capabilities of managing the graphics adapter by adding additional user settings. The patch must integrate into the existing driver architecture without disrupting its core functionality and ensure compatibility with supported versions of the operating system. The main goal is to provide more flexible access to parameters that are not available in the standard driver control panel, with the ability to modify them through a user interface or software API. The patch should provide a modular structure that allows for the addition of new parameters in the future without significant code redesign. It is necessary to ensure proper error handling, change logging, the ability to revert settings to default values, as well as maintain compatibility with future driver updates as much as possible. The solution should be accompanied by technical documentation describing the architecture, implemented capabilities, limitations, and testing recommendations.
We are a large logistics company with our own exports. We have a large fleet of vehicles and we constantly send our own vehicles for export to European countries.Description Website: https://echerha.gov.ua/ On this website, we place our vehicles in an electronic queue for crossing the state border. During registration, the following data must be entered: driver's first and last name; foreign passport number; email address; logistics phone number for notifications; type of vehicle (cargo); manufacturer's name of the vehicle; state registration number of the tractor; state registration number of the trailer; customs declaration number. A specific day and time for crossing the border is predetermined for each vehicle. For example, the vehicle must pass through the "Rava-Ruska" checkpoint on Monday at 10:00.Our Problem - The queue on the website https://echerha.gov.ua/ moves unpredictably. - For example, today is Friday, and the vehicle must cross the border on Monday at 10:00. - We do not know exactly when the queue will start moving. This can happen on Friday evening, at any time on Saturday or Sunday, early in the morning, during the day, or late at night. - When the queue starts moving, it is immediately visible on the website. Sometimes, within just a few minutes, it can move from Friday to Monday or even to Tuesday. - Because of this, logistics personnel are forced to constantly monitor the mobile application or website to not miss the moment when the queue reaches the required date and time. If this moment is missed, we physically cannot place the vehicle in the queue for the needed time slot.Task - After entering the vehicle data (for example, into a table or another interface, depending on the programmer's implementation), the system should automatically track the movement of the queue. - When the queue reaches the predetermined date and time, the system should automatically fill in the necessary data and place the vehicle in the queue without the involvement of the logistics personnel.
Looking for an experienced TrinityCore 3.3.5a developer who has a good understanding of the core architecture, Battleground system, C++, SQL, and the WoW 3.3.5 client. A custom Battleground “Slavery Valley” has already been integrated into the project, transferred from AzerothCore to TrinityCore. The main part of the work has already been completed, but it needs to be brought up to Blizzard's standards.What has been done TrinityCore 3.3.5a + Eluna. The server is fully configured. The Battleground is integrated into the core. Entry into the BG works. Client UI works (partially). Most SQL and DBC have been transferred. Builds without errors.What needs to be done Fix remaining Battleground bugs. Bring the mechanics up to the level of official Blizzard Battlegrounds. Fix the match start phase. Implement correct starting gates/fire walls. Fix point capture mechanics. Fix match completion. Check score allocation and WorldState functionality. Fix remaining C++ and SQL issues. Conduct a full gameplay test.Requirements Mandatory experience: TrinityCore 3.3.5a; C++; SQL (MariaDB/MySQL); DBC; MPQ; Visual Studio; CMake; Git. Would be a big plus: AzerothCore; Eluna; experience in Battleground development; understanding of the client side of WoW 3.3.5a.Work format Work is staged. Mandatory testing after each stage. Each stage is accepted only after in-game verification. Clear reports on changes are required.In the future This is a long-term project. After completing the Battleground, the following is planned: transfer of new Battlegrounds; transfer of new arenas; new races; new classes; new game systems; further development of a custom World of Warcraft 3.3.5a server. Looking for a developer who has already worked with TrinityCore and can not only write code but also bring the system to a fully operational state.no server from 0 as I want If you are looking for a developer not just for one Battleground, but for creating a server from scratch, then the announcement should look something like this.Project Title Development of a World of Warcraft 3.3.5a server from scratch (TrinityCore / C++ / SQL / Eluna)Project Description Looking for an experienced TrinityCore 3.3.5a developer for long-term collaboration. I need a person who can develop a fully ready World of Warcraft 3.3.5a game server from scratch based on TrinityCore with further project development. The project is large and is expected to take several months of development.Project Foundation TrinityCore 3.3.5a. Maximally stable and close to Blizzard base. Eluna Lua Engine. MariaDB. Visual Studio + CMake. Git.What is planned to be implemented Fully operational server 3.3.5a. Fixing core bugs. Development of new game systems. Integration of custom Battlegrounds. Integration of new arenas. Transfer of useful modules from AzerothCore to TrinityCore. Development of custom modules. New PvP and PvE systems. New game events. Class balancing. Additional progression systems. Improvement of server performance.In the future After completing the basic part, the following is planned: new races; new classes; new zones; new dungeons; new raids; new Battlegrounds; new professions; new game mechanics; integration of modern systems into the 3.3.5a client.Developer Requirements Mandatory: Excellent knowledge of TrinityCore 3.3.5a. Confident knowledge of C++. SQL (MariaDB/MySQL). Git. Visual Studio. CMake. Understanding of TrinityCore architecture. Experience with Battleground, PvP, and game mechanics. Would be a big plus: Experience with AzerothCore. Eluna Lua Engine. Working with DBC and MPQ. Experience in creating custom game systems.Work format Work is staged. Each task is documented as a separate technical assignment. Mandatory testing after each stage. Work is accepted only after verification directly in the game. A developer is needed who can bring functionality to a fully operational state, not just write code.
Create compatibility between the ground control station, automatic start system (SAS), radar, and the aircraft.