LINUX.ORG.RU

Прикрутить список к элементам уже содержащим ссылки на соседей?

 , ,


0

1

Есть пачка объектов где-то-там уже лежащих, которые надо организовать в список, и дальше с этим списком работать. При этом объекты уже содержат поля для ссылок на соседей по списку, в зависимости от ситуевины это не обязательно указатели - могут быть например номера элементов в общем массиве типа uint16_t (в данной задаче критическим является размер памяти), или еще что то. Список тоже может быть как односвязный, так и двусвязный.

Можно конечно реализовать все руками, но уж больно много повторяющегося кода выходит в которым легко напортачить. Хочется сваять шаблонный класс (два - для двусвязного и для осноснвязного списков), но я не очень соображу как в него передать способ манипулирования со ссылками на соседей.

Пока что в голову приходит только совать соответствующую лямбда-функцию в аргумент конструктора (точнее несколько - ну там для доступа к ссылке вперед/назад и для получения самого элемента). Но как то не Ъ выглядит... Кто что посоветует?

★★★★★

гм, если я правильно всё понял - то может нужно определить свой итератор для каждого типа объектов из пачки, который уже будет знать как правильно переходить от одного элемента к другому?

spectral1989
()

Зачем тут нужны лямбды — я пока не вижу. Можно сделать класс, сделать метод <<для доступа к ссылке вперед/назад>> виртуальным, реализовать всё остальное через него, а уже в наследниках этот метод специфицировать.

По-хорошему вы тут должны реализовать SequenceContainer или подобное.

Crocodoom ★★★★★
()

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

template<typename T, template<class> typename Binder>
class container {...}
Где в качестве Binder-а у вас будут шаблоны вида:
template<typename T>
struct index_binder {
  static void set_next(T & left, T & right) {...};
  static T * get_next(const T & current) {...};
  ...
}

eao197 ★★★★★
()

+ итераторам и первому оратору

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

Да, насчет итератора в таком ключе я не думал. Спасибо.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от eao197

У меня что то такое вертелось, но есть две проблемы:

1) биндеру зачастую придется знать какую то доп. информацию (скажем начало массива в котором лежат элементы). Можно конечно то ли в конструктор биндера это передавать, то ли в каждую функцию при вызове, но все как то криво выглядит.

2) Работа со ссылками в каждом биндере будет дублироваться, а это то от чего хотелось избавиться и вынести это как раз в сам список. Хотя это не очень большая беда, будет там этих биндеров условно штуки три... терпимо.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Crocodoom

В данном случае не хочется связываться с виртуальными функциями.

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

биндеру зачастую придется знать какую то доп. информацию (скажем начало массива в котором лежат элементы). Можно конечно то ли в конструктор биндера это передавать, то ли в каждую функцию при вызове, но все как то криво выглядит.

Да вроде нормально это выглядит. Просто у вас тогда будут не stateless биндеры, а stateful. И сам биндер будет хранится внутри контейнера (как хранится аллокатор в стандартных контейнерах).

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

Биндеров же можно наследовать друг от друга или от общего предка и переиспользовать таким образом общий код.

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