Question

I have an implementation of a queue, something like template <typename T> queue<T> with a struct QueueItem { T data;} and I have a separate library that times the passage of data across different places (including from one producer thread to consumer thread via this queue). In order to do this, I inserted code from that timing library into the push and pop functions of the queue so that when they assign a BufferItem.data they also assign an extra member i added of type void* to some timing metadata from that library. I.e. what used to be something like:

void push(T t)
{
  QueueItem i;
  i.data = t;
  //insert i into queue
}

became

void push(T t)
{
  QueueItem i;
  i.data = t;

  void* fox = timinglib.getMetadata();
  i.timingInfo = fox;
  //insert i into queue
}

with QueueItem going from

struct QueueItem
{
 T data;
}

to

struct QueueItem
{
  T data;
  void* timingInfo;
}

What I would like to achieve, however, is the ability to swap out of the latter struct in favor of the lighter weight struct whenever the timing library is not activated. Something like:

if timingLib.isInactive()
 ;//use the smaller struct QueueItem
else
 ;//use the larger struct QueueItem

as cheaply as possible. What would be a good way to do this?

Answer 1

You can’t have a struct that is big and small at the same time, obviously, so you’re going to have to look at some form of inheritance or pointer/reference, or a union.

A union would be ideal for you if there’s “spare” data in T that could be occupied by your timingInfo. If not, then it’s going to be as ‘heavy’ as the original.

Using inheritance is also likely to be as big as the original, as it’ll add a vtable in there which will pad it out too much.

So, the next option is to store a pointer only, and have that point to the data you want to store, either the data or the data+timing. This kind of pattern is known as ‘flyweight‘ – where common data is stored separately to the object that is manipulated. This might be what you’re looking for (depending on what the timing info metadata is).

The other, more complex, alternative is to have 2 queues that you keep in sync. You store data in one, and the other one stores the associated timeing info, if enabled. If not enabled, you ignore the 2nd queue. The trouble with this is ensuring the 2 are kept in sync, but that’s a organisational problem rather than a technical challenge. Maybe create a new Queue class that contains the 2 real queues internally.