Kevin Goodsell said:
You need a return type for this function. ALL functions (except
constructors, destructors, conversion operators, and maybe some other
special cases I'm forgetting) must have explicit return types.
reinterpret_cast is the Wrong Thing to do in that case. In fact, this
reeks of poor organization. What is the relationship between GenericData
and MyClass? If there is none, then you shouldn't be treating one as if
it is the other. If there is a relationship between the two, then it
should probably be modeled through inheritance, which should make any
cast unnecessary.
A cast is often an indication of a design error, and always a potential bug.
If you tell us what you really want to do, we can probably recommend a
cleaner way to do it.
-Kevin
Thank you C++ people! I am being very late on the thread.
The problem is perhaps discussed here several times: it is
about message routing and dispatching. Concretely, we
have the following structure:
------- --------
| App0 | | App1 |
--o---- ----o---
| |
--o-----------o---
| Communication |
------------------
The communiation is socket based and it only cares about
the so called generic message header, the message body
is casted to and from in App0, App1, .... For App0, App1
etc's entry point, there is a message dispathing entity.
To add a little complexity to the discussion, some of the
Apps (protocol layers) is/are implemented in C on different
HW architecture.
Currently our engineer who architect the development have
the following C++ message structure definition:
typedef struct {
GenericHeader* pHead;
AppxData data;
} GenericMesage;
And then the ugly casts when AppxData is needed in Appx...
Best regards,
Wenjie