Бюджет: 7500 UAH Термін: 1 день
Я роблю за 1 день, використовую Clion. Все детально розпишу і поясню. У разі необхідності детально розпишу роботу програми. Напишіть в особисті повідомлення
Нужно реализовать 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+ деревом есть ошибки или неточности.
При возникновении проблем, попробуйте воспроизвести каждую из них по отдельности, написав минимальный юнит-тест (за хорошие тесты вы можете получить дополнительные баллы).
Бюджет: 7500 UAH Термін: 1 день
Я роблю за 1 день, використовую Clion. Все детально розпишу і поясню. У разі необхідності детально розпишу роботу програми. Напишіть в особисті повідомлення
Бюджет: 1500 UAH Термін: 5 днів
Добрий день .
Я маю досвід написання програм з різними структурами даних.
Готова обговорити з вами умови співпраці.
Дякую за увагу.
Бюджет: 1000 UAH Термін: 2 дні
Привітання, у мене є досвід у виконанні подібних завдань, я зроблю за 2 дні
Потрібно розробити патч для драйвера відеокарти, який розширює можливості управління графічним адаптером за рахунок додавання додаткових користувацьких налаштувань. Патч має інтегруватися в існуючу архітектуру драйвера без порушення його основної функціональності та забезпечувати сумісність з підтримуваними версіями операційної системи. Основною метою є надання більш гнучкого доступу до параметрів, які недоступні в стандартній панелі управління драйвером, з можливістю їх зміни через користувацький інтерфейс або програмний API. Патч має передбачати модульну структуру, що дозволяє в подальшому додавати нові параметри без суттєвої переробки коду. Необхідно забезпечити коректну обробку помилок, журналювання змін, можливість відкату налаштувань до значень за замовчуванням, а також збереження сумісності з майбутніми оновленнями драйвера, наскільки це можливо. Рішення має супроводжуватися технічною документацією з описом архітектури, реалізованих можливостей, обмежень і рекомендацій щодо тестування.
Ми є великою логістичною компанією, яка має власний експорт. У нашому розпорядженні великий автомобільний парк, і ми постійно відправляємо власні транспортні засоби на експорт до країн Європи.Опис Сайт: https://echerha.gov.ua/ На цьому сайті ми ставимо наші автомобілі в електронну чергу для перетину державного кордону. Під час реєстрації необхідно ввести такі дані: ім'я та прізвище водія; номер закордонного паспорта; електронну адресу (email); номер телефону логіста для отримання сповіщень; тип транспортного засобу (вантажний); назву виробника автомобіля; державний номерний знак тягача; державний номерний знак причепа; номер митної декларації. Для кожного автомобіля заздалегідь визначено конкретний день і час перетину кордону. Наприклад, автомобіль повинен пройти пункт пропуску «Рава-Руська» у понеділок о 10:00.Наша проблема - Черга на сайті https://echerha.gov.ua/ рухається непередбачувано. - Наприклад, сьогодні п'ятниця, а автомобіль повинен перетнути кордон у понеділок о 10:00. - Ми не знаємо, коли саме почне просуватися черга. Це може статися у п'ятницю ввечері, у будь-який час у суботу або неділю, рано вранці, вдень чи пізно ввечері. - Коли черга починає рухатися, це відразу видно на сайті. Іноді всього за кілька хвилин вона може просунутися з п'ятниці до понеділка або навіть до вівторка. - Через це логісти змушені постійно контролювати мобільний застосунок або вебсайт, щоб не пропустити момент, коли черга дійде до потрібної дати та часу. Якщо цей момент буде втрачено, ми фізично не встигаємо поставити автомобіль у чергу на потрібний часовий слот.Задача - Після внесення даних про автомобіль (наприклад, у таблицю або інший інтерфейс, залежно від реалізації програміста) система повинна автоматично відстежувати рух черги. - Коли черга дійде до заздалегідь визначених дати та часу, система повинна автоматично заповнити необхідні дані та поставити автомобіль у чергу без участі логіста.
Шукаю досвідченого розробника TrinityCore 3.3.5a, який добре розбирається в устрої ядра, системі Battleground, C++, SQL та клієнті WoW 3.3.5. В проект вже інтегровано кастомний Battleground «Долина Рабства» (Slavery Valley), перенесений з AzerothCore на TrinityCore. Основна частина роботи вже виконана, однак потрібно довести його до рівня Blizzard.Що вже зроблено TrinityCore 3.3.5a + Eluna. Повністю налаштований сервер. Battleground інтегровано в ядро. Працює вхід у BG. Працює клієнтський UI (частково). Виконано перенесення більшості SQL та DBC. Збирається без помилок.Що необхідно зробити Виправити залишкові баги Battleground. Довести механіку до рівня офіційних Battleground Blizzard. Виправити стартову фазу матчу. Реалізувати коректні стартові ворота/вогняні стіни. Виправити механіку захоплення точок. Виправити завершення матчу. Перевірити нарахування очок і роботу WorldState. Виправити залишкові проблеми C++ та SQL. Виконати повний ігровий тест.Вимоги Обов'язковий досвід: TrinityCore 3.3.5a; C++; SQL (MariaDB/MySQL); DBC; MPQ; Visual Studio; CMake; Git. Будет великим плюсом: AzerothCore; Eluna; досвід розробки Battleground; розуміння клієнтської частини WoW 3.3.5a.Формат роботи Робота поетапна. Після кожного етапу обов'язкове тестування. Кожен етап приймається тільки після перевірки в грі. Необхідні зрозумілі звіти по змінам.В подальшому Це довгостроковий проект. Після завершення Battleground планується: перенесення нових Battleground; перенесення нових арен; нові раси; нові класи; нові ігрові системи; подальша розробка власного сервера World of Warcraft 3.3.5a. Шукаю розробника, який вже працював з TrinityCore і зможе не просто писати код, а доводити систему до повністю робочого стану.немає сервера з 0 як я хочу Якщо ти шукаєш розробника не на один Battleground, а на створення сервера з нуля, то оголошення повинно виглядати приблизно так.Назва проекту Розробка сервера World of Warcraft 3.3.5a з нуля (TrinityCore / C++ / SQL / Eluna)Опис проекту Шукаю досвідченого розробника TrinityCore 3.3.5a для довгострокового співробітництва. Потрібен чоловік, який зможе з нуля розробити повністю готовий ігровий сервер World of Warcraft 3.3.5a на базі TrinityCore з подальшим розвитком проекту. Проект великий і розрахований на кілька місяців розробки.Основа проекту TrinityCore 3.3.5a. Максимально стабільна і близька до Blizzard база. Eluna Lua Engine. MariaDB. Visual Studio + CMake. Git.Що планується реалізувати Повністю робочий сервер 3.3.5a. Виправлення помилок ядра. Розробка нових ігрових систем. Інтеграція кастомних Battleground. Інтеграція нових арен. Перенесення корисних модулів з AzerothCore на TrinityCore. Розробка власних модулів. Нові PvP та PvE системи. Нові ігрові події. Балансування класів. Додаткові системи прогресії. Покращення продуктивності сервера.В майбутньому Після завершення базової частини планується: нові раси; нові класи; нові зони; нові підземелля; нові рейди; нові Battleground; нові професії; нові ігрові механіки; інтеграція сучасних систем у клієнт 3.3.5a.Вимоги до розробника Обов'язково: Відмінне знання TrinityCore 3.3.5a. Упевнене знання C++. SQL (MariaDB/MySQL). Git. Visual Studio. CMake. Розуміння архітектури TrinityCore. Досвід роботи з Battleground, PvP та ігровими механіками. Будет великим плюсом: Досвід роботи з AzerothCore. Eluna Lua Engine. Робота з DBC та MPQ. Досвід створення власних ігрових систем.Формат роботи Робота поетапно. Кожне завдання оформлюється окремим технічним завданням. Після кожного етапу проводиться обов'язкове тестування. Робота приймається тільки після перевірки безпосередньо в грі. Потрібен розробник, який вміє доводити функціонал до повністю робочого стану, а не тільки писати код
Стоврити сумісність між наземною станцією управління, системою автоматичного старту (САС), радаром та літаком.