# [C++] String-based type system?

This topic is 3174 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm trying to build a console that allows the dynamic creation of objects. I have a base class, and a vector<BaseClass*> in which I store the objects. I'm having difficulty with derivation, though: the BaseClass* pointers have to be recasted to the respective derived type in order to use any of the members. I'm pretty sure I'm doing it wrong :P Basically I need a way to create a derived object from its proper name as a string, which is simple enough if you map up a pointer to its constructor... except for the fact that they're all of different classes so the function types will be different, and therefore can only coexist as LPVOIDs. This, of course, requires yet another recasting for each type. I also need a way to store all the objects (of different types) in the same array. I thought a base class would accomplish this, but apparently it's no better than an LPVOID. The only thing I can think of now is either to write my own runtime class system from scratch, or to map up a ton of casting and conversion function pointers and use strings to access them. Either of these would work, but the source might get ugly. And so I'm asking: Is there another way, or am I on the right track with a runtime class system or a map of function pointers?

##### Share on other sites
Quote:
 And so I'm asking: Is there another way, or am I on the right track with a runtime class system or a map of function pointers?

Hammers, nails and planks.

The first problem to solve is the style and shape of house to build. The tools come later.

Quote:
 have to be recasted to the respective derived type in order to use any of the members

Add members that can be called to BaseClass, then have factory return BaseClass *, and its members can be called directly without casting.

Casting to call members, or using stuff like dynamic_cast or instanceof or similar is almost without an exception a design flaw. It exposes incorrect abstraction.

In case this console is intended as an interpreter:
x = new Foo;x.callMember;x = new Bar;x.callDifferentMember 22 55

The solution to this is very simple:
struct BaseClass {  virtual void invoke(std::string & line) = 0;}

invoke is then responsible for parsing everything beyond the '.', so in last case 'line' would be 'callDifferentMember 22 55', which the concrete instance knows how to do, or it knows it doesn't have such member which takes such parameters.

Finally, Lua or Python are fairly easy to embed, and solve all those and many other problems.

Quote:
 except for the fact that they're all of different classes so the function types will be different
In that case they cannot be put into same container, since they are different types. Simple as that.

In above case, they would all be either BaseClass, or Invokable or similar.

Alternative is to abandon OO design, and use some descriptor class to map each type added to console with associated function pointers or similar. This results in double work, and extra overhead with some universal descriptors.

The code to this solution ends up quite convoluted, since it requires map from type to descriptor, then map to function, then map to parameters.

Again, using Lua with custom types for this purpose would be much shorter and simpler to implement. It requires exactly same semantic overhead, but takes care of parsing, validation and memory management.

##### Share on other sites
So you're saying I need to make the base class expandable enough (via virtualization) that inherited classes needn't define new members? Wow. That's so obvious... how could I miss that. Thanks for the advice.

Pretty much infinite expandability is possible with a virtual function that takes a string and an array anyway, so there's not really any limitations with that. I'll try it :D

1. 1
2. 2
Rutin
19
3. 3
khawk
18
4. 4
5. 5
A4L
11

• 9
• 12
• 16
• 26
• 10
• ### Forum Statistics

• Total Topics
633769
• Total Posts
3013759
×