Jump to content
  • Advertisement
Sign in to follow this  
Super Llama

[C++] String-based type system?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!