2013-11-15 2 views
2

В настоящее время я работаю над назначением класса, где мне нужно реализовать связанный с блокировкой список. Структура каждого из моих узлов, по существу:Кража битов из std :: shared_ptr

class Node { 
    std::shared_ptr<Node> next; 
    long long    key; 
} 

мне нужно как-то встроить дополнительный бит данных в «следующий» указатель. Я не могу использовать дополнительное логическое поле, потому что «следующий» указатель нуждается в обновлении с помощью compare_exchange_strong(). Я также должен использовать std :: shared_ptr для его возможностей сбора мусора; выполнение мелиорации памяти на блокированной структуре данных выходит за рамки того, что мы изучили в ходе курса.

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

Может ли кто-нибудь дать представление о том, как я могу это сделать?

О, и для любопытных я использую g ++ - 4.8.2 в системе Linux.

+2

Вы можете вставлять информацию в пользовательский делектор. – dyp

+0

Знаете ли вы, где я мог бы найти пример чего-то подобного? –

+1

@DyP Делектор за указатель на объект, а не на общий указатель, поэтому я думаю, что это совсем другое. –

ответ

0

Похоже, вы пытаетесь смешивать здесь две разные вещи.

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

Во всяком случае, пользовательский deleter, как было предложено ранее, делается следующим образом;

struct d { void operator()(foo* f){ delete f; } }; 

... и вы создаете shared_ptr с использованием;

shared_ptr<bar> b(new bar, d()); 

... но почему бы не использовать атомные операции для начала?

Приветствия!

+0

Я хотел использовать shared_pointers для получения преимуществ управления памятью; вам не нужно беспокоиться о том, когда их удалять. Однако, по-видимому, в gcc-4.8.2 они не являются 100-процентными потокобезопасными; в одной из моих реализаций я получал действительно странные ошибки «вызова чистой виртуальной функции». Я закончил писать свой собственный менеджер памяти, который использовал указатели опасности, чтобы определить, когда было бы безопасно повторно использовать элемент данных. Я также должен был написать подход, основанный на блокировке, а пользовательский менеджер памяти был на 300-400% быстрее, чем использование общих указателей ... –

+0

Что касается ошибок «чистой виртуальной функции»; Я получаю это иногда, когда я вызываю виртуальную функцию из деструктора базового класса. Иногда я кладу 'cout <<" Destroying: «<< * this» в деструкторе для ведения журнала и если 'operator <<' содержит вызовы виртуальных функций ...: / – Daniel

Смежные вопросы