Task ownership in Factory-Processor model - c++

Question

Factory supplies Tasks of different types to Processor asynchronously. Processor doesn't know details of Tasks and executes them via known Interface. Dynamic allocation is prohibited due to performance reasons. Factory should not own Tasks because otherwise Processor would need to inform Factory when he finishes execution of Task to do the cleanup. Processor should know only Interface, but not Tasks themselves. Processor may own Tasks as opaque objects while he processes them.
One possible solution is: store all kinds of Tasks inside the union of "Interface & padding buffer". Please, consider the following working example (C++11):
#include <iostream>
struct Interface
{
virtual void execute() {}
};
union X
{
X() {}
Interface i;
char padding[1024];
template <class T>
X& operator= (T &&y)
{
static_assert (sizeof(T) <= sizeof(padding), "X capacity is not enough!");
new (padding) T(y);
}
};
struct Task : public Interface
{
Task() : data(777) {}
virtual void execute() { std::cout << data << std::endl; }
int data;
};
int main()
{
Task t;
X x;
x = std::move(t);
Interface *i = &x.i;
i->execute();
};
The snippet works well (prints 777). But are there any dangers (like virtual inheritance) in such approach? Maybe any better solution is possible?

Answer 1

Your solution seems to involve both an unnecessary copy operation, and making assumptions about the layout of your objects in memory that are not guaranteed to be correct in all circumstances. It further invokes undefined behaviour by using memcpy to copy an object with virtual methods, which is explicitly disallowed by the c++ spec. It also has the potential to cause confusion over when object destructors run.
I would use an arrangement like this:
class Processor has an array of buffers, each of which is large enough to contain any defined subclass of your task interface. It has two methods used in submitting tasks:
one to return a pointer to a currently available buffer
one to submit a job
The job interface is extended with a requirement to track the pointer to the buffer that contains it (which will be supplied as a constructor parameter), and has a method to return that pointer.
Submitting a new task is now done like this:
void * buffer = processor.getBuffer();
Task * task = new (buffer) Task(buffer);
processor.submitJob(task);
(this could be simplified using a template method in Processor if required). Then, the processor simply executes jobs, and when it's done with them it asks them for their buffer, runs their destructor, and adds the buffer back into its free buffer list.

Answer 2

Updated answer.
See: std::aligned_union (en.cppreference.com). It is designed to be used together with placement new and explicit destructor call.
Below is the earlier answer, now retracted.
From the design perspective,
Avoiding dynamic allocation seems a drastic requirement. It requires some extraordinary justification.
In case one does not trust the standard allocator for any reason, one could still implement a custom allocator, in order to have full control of its behavior.
If there is a class or method that "owns" all instances of everything: all Factories, all Processors, and all Tasks (as is the case in your main() method), then it is not necessary to copy anything. Just pass references or pointers around, since this "class or method that owns everything" will take care of object lifetime.
My answer is only applicable to the question about "memcpy".
I do not try to cover the issue of memcpy-ing between "Task which has Interface as base class, and X which has Interface as member". This doesn't seem universally valid for all of the C++ compilers, but I don't know offhand which C++ compilers would fail this code.
Short answer, which is applicable to all C++ compilers:
To use memcpy on a type, the type needs to be trivially copyable.
Currently, trivially copyable lists "no virtual functions" as one of the necessary conditions, so the "according to the spec" answer is that your struct Task is not trivially copyable.
The longer, non-standard answer is whether your particular compiler will synthesize the struct and the machine code that would be effectively copyable (i.e. without ill-effects), despite the C++ specification saying no. Obviously this answer will be compiler-specific, and will depend on a lot of circumstances (such as optimization flags and minor code changes).
Remember that compiler optimization and code generation can change from version to version. There is no guarantee that the next version of the compiler will behave exactly the same.
To give an example of something that would be likely to be unsafe for memcpy-ing between two instances, consider:
struct Task : public Interface
{
Task(std::string&& s)
: data(std::move(s))
{}
virtual void execute() { std::cout << data << std::endl; }
std::string data;
};
The reason this is problematic is that, for sufficiently long strings, std::string will allocate dynamic memory to store its content. If there are two instances of Task, and memcpy is used to copy its bytes from one instance to another instance (which would have copied over the internal fields of the std::string class), their pointers will point to the same address, and therefore their destructors will both try to delete the same memory, leading to undefined behavior. In addition, if the instance that was being overwritten had an earlier string value, the memory will not be freed.
Since you have said that "dynamic allocation is prohibited", my guess is that you will not be using std::string or anything similar, instead opting to write C-like code exclusively. So this concern may not be relevant to you.
Speaking of "low level C-like code", here is my idea:
struct TaskBuffer
{
typedef void (*ExecuteFunc) (TaskBuffer*);
ExecuteFunc executeFunc;
char padding[1024];
};
void ProcessMethod(TaskBuffer* tb)
{
(tb->executeFunc)(tb);
}