Каковы производительность, безопасность и выравнивание элемента данных, скрытого во встроенном массиве символов в классе C++?

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

• Бассейн. Это класс, который эффективно распределяет память для некоторого определения «эффективного». Бассейн гарантированно вернет кусок памяти, который выровнен по запрошенному размеру.

• Obj_list. Этот класс хранит однородные коллекции объектов. Как только количество объектов превышает определенный порог, он меняет свое внутреннее представление со списка на дерево. Размер Obj_list - один указатель (8 байтов на 64-битной платформе). Его густонаселенный магазин, конечно, превзойдет это.

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

В этом примере элементы Совокупный всегда выделяются из Бассейн, поэтому они всегда выровнены. Единственные вхождения Obj_list в этом примере - это «скрытые» элементы в объектах Совокупный, и поэтому они всегда выделяются с использованием размещение новое. Вот классы поддержки:

class Pool
{
public:
   Pool();
   virtual ~Pool();
   void *allocate(size_t size);
   static Pool *default_pool();   // returns a global pool
};

class Obj_list
{
public:
   inline void *operator new(size_t s, void * p) { return p; }

   Obj_list(const Args *args);
   // when constructed, Obj_list will allocate representation_p, which
   // can take up much more space.

   ~Obj_list();

private:
   Obj_list_store *representation_p;
};

А вот и агрегат. Обратите внимание, что объявление члена member_list_store_d:

// Aggregate is derived from Lesser, which is twelve bytes in size
class Aggregate : public Lesser
{
public:
   inline void *operator new(size_t s) {
      return Pool::default_pool->allocate(s);
   }

   inline void *operator new(size_t s, Pool *h) {
      return h->allocate(s);
   }

public:

   Aggregate(const Args *args = NULL);
   virtual ~Aggregate() {};

   inline const Obj_list *member_list_store_p() const;

protected:
   char member_list_store_d[sizeof(Obj_list)];
};

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

Aggregate::Aggregate(const Args *args)
{
   if (args) {
      new (static_cast<void *>(member_list_store_d)) Obj_list(args);
   }
   else {
      zero_out(member_list_store_d);
   }
}

inline const Obj_list *Aggregate::member_list_store_p() const
{
   return initialized(member_list_store_d) ? (Obj_list *) &member_list_store_d : 0;
}

У вас может возникнуть соблазн предложить заменить массив символов указателем на тип Obj_list, инициализированный значением NULL или экземпляром класса. Это дает правильную семантику, но просто меняет стоимость памяти. Если бы память все еще была в дефиците (а это могло быть, это представление базы данных EDA), замена массива char указателем на Obj_list потребовала бы еще одного указателя в случае, когда объекты Совокупныйделать имеют члены.

Кроме того, я не хочу отвлекаться от главного вопроса, а именно от выравнивания. Я считать вышеупомянутая конструкция проблематична, но я не могу найти больше в стандарте, чем какое-то расплывчатое обсуждение поведения выравнивания «системы / библиотеки» новый.

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

Редактировать: Я понимаю, что есть способы заменять подхода с использованием встроенного массива символов. Так поступили и первоначальные архитекторы. Они отказались от них, потому что память была в большом почете. Теперь, если у меня есть причина прикоснуться к этому коду, я, вероятно, его изменю.

Однако я надеюсь, что люди обратятся к моему вопросу о проблемах согласования, присущих этому подходу. Спасибо!