list of lists

Выглядит как дерево. А «поле класса» выглядит как ключ. Ключ может быть составным. Если устраивает, что элементы будут автоматически отсортированы по «полю класса» в каждой подветке, то, видимо, стоит использовать дерево, а «поля классов» вынести в ключ.

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

Здравствуйте.

Рекомендую вам пройти курсы по программированию на современном C++, которые были созданы совместно Яндекс и МФТИ на плфтформе Coursera.

https://www.coursera.org/learn/c-plus-plus-white

Или лучше использовать другую структура данных?

Да, std::vector. Долго обьяснять, но в 99.9% случаев std::vector лучше, чем std::list. Если интересно, вот тут подробнее: http://danglingpointers.com/post/dont-use-std-list/

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

Может std::map / std::unordered_map?

Сортировка исключена. Думал о boost::property::tree, слишком много проблем вылазит с извлечением данных. Нужно как вертикальных обход данных так и линейный.

Сортировка исключена.
Нужно как вертикальных обход данных так и линейный.

Просто храни список ключей отсортированных в нужном тебе порядке (например в порядке добавления).

хэш таблица с составным ключом?

Относительно быстрый доступ к элементу в любом месте, удаление, вставка. Таки струтур должно быть минимум три т.е list<list<list<class>>>. Базовый элемент должен быть классом содержащий такую структуру данных из трех элементов. Применение, игра (стратегия) что то вроде шахмат но более сложная(многоуровневая). class это позиция.

Не, не пойдёт, там элементы по ключу не будут рядом лежать.

Или лучше использовать другую структура данных?

верно

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

база данных(БД) в отбельном потоке или сервер к которому подключаешься(сокетами или как угодно)

писать самому монстро-БД не получиться(будешь фиксить тонну багов ошибок утечек памятии тормозов тыщу лет)

Ой бы только из пушки по воробьям. С БД будет куча boilerplate кода, который нужен только если производство таких структур надо на поток поставить. Я молчу, про то, что это vendor lock in(в случае in-memory баз данных это почти 100%), накладные расходы на блокировки и i/o(в памяти оно тоже самое i/o) на пустом месте, да ещё и доп зависимость.

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

map<key,map<key,map<key, class>>> и паралельно list<list<string(key)>> вот так?

понял, это про дерево был комент

Лучше плоско

class Data { /* whatever */ };

using Key = std::tuple<Key1, Key2, Key3>;

using DataMap = std::map<Key, Data>;

using Keys = std::vector<DataMap::mapped_type>;

нет, так не получается. плоско хуже

Ой бы только из пушки по воробьям.

але челик, БД разные бывают

от single-header БД на пару сотен строк, до полумонстров(sqlite), и очевидных монстрова(монго/mysql etc)

вот например я пользовал(чуть сложнее single-header)
очень быстрая и минималистичная https://unqlite.org/ (гитхаб https://github.com/symisc/unqlite )

там примеры именно то что ТС хочет

/* Store some records */
	rc = unqlite_kv_store(pDb,"test",-1,"Hello World",11); /* test => 'Hello World' */

нет, это не то что мне нужно. доступ по ключу приводит к тому что нужно создавать структуру для хранения ключей.

библиотека по ссылке использует 1мб «оперативной памяти» для своих нужд, все остальное выше этого будет на данные

один класс list или map это уже +500кб к используемой памяти, многоуровневые включения списков из списков даст еще больший расход

скажи мне пожалуйста почему же

нет, это не то что мне нужно. доступ по ключу приводит к тому что нужно создавать структуру для хранения ключей.

чем создание структуры list или map отличается от использования подобных по функционалу либ

непонимаю

один класс list или map это уже +500кб к используемой памяти

откуда такие цифры? у меня десятки байтов

откуда такие цифры? у меня десятки байтов

доступ по ключу приводит к тому что нужно создавать структуру для хранения ключей.

библиотека по ссылке использует 1мб «оперативной памяти» для своих нужд, все остальное выше этого будет на данные

один класс list или map это уже +500кб к используемой памяти

о чем ты если не о памяти???

я тебе объяснил что по памяти это идентично(тыж еще половину std/boost потащишь за собой и это мегабайты добавит), что еще тебя волнует?

количество кодописания?
при использовании той либы что я линканул или подобной минималистичной-меньше чем с дефолтным list

я о памяти, понятия не имею откуда у меня может появится в одном списке 500кб. в данный момент структура данных решает свои задачи, а там видно будет

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

Или лучше использовать другую структура данных?

И как можно вообще на такой вопрос ответить, если даже не указано, что за задача решается?

Вот телепаты из отпуска выйдут и ответят ТСу!

А что, теперь внимательно читать могут только телепаты?