LINUX.ORG.RU

list of lists

 , , ,


0

3

Возможно ли использовать

class A {
public:
list<list<list<A>>> a;
};

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


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

onhydro ()

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

Silerus ★★★ ()

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

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

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

anonymous ()

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

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

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

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

KennyMinigun ★★★★★ ()
Ответ на: комментарий от onhydro

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

ferz ()
Ответ на: комментарий от ferz

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

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

KennyMinigun ★★★★★ ()
Ответ на: комментарий от Silerus

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

ferz ()
Ответ на: комментарий от onhydro

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

onhydro ()

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

верно

missxu ()

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

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

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

missxu ()
Ответ на: комментарий от missxu

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

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

onhydro ()
Ответ на: комментарий от onhydro

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

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

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

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

missxu ()
Ответ на: комментарий от missxu

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

ferz ()
Ответ на: комментарий от ferz

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

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

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

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

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

непонимаю

missxu ()
Ответ на: комментарий от ferz

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

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

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

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

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

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

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

missxu ()
Ответ на: комментарий от missxu

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

ferz ()
Ответ на: комментарий от ferz

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

anonymous ()

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от theNamelessOne

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.