Jump to content
  • Advertisement
Sign in to follow this  
Adventus

C++ General Variable Class

This topic is 4089 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

Basically, Im trying to create a class which can safely hold a range of different variable types. For instance, i could declare it as a string then at some point redeclare it as a double. Here's what i've come up with so far: class variable {    public:      int type;      void* data;      variable();      variable operator+ (variable param); }; variable::variable(){ type = 0; data = 0; } variable variable::operator+ (variable param){ variable var; if (type != param.type){ //error message return var; } var.type = type; switch(type){ case 0:{ //show error message return var; } case 1:{ //double double d = *((double*)data); d += *((double*)param.data); var.data = &d; break; } case 2:{ //string string s = *((string*)data); s += *((string*)param.data); var.data = &s; break; } } return var; } Im wondering whether theres something i've overlooked, For instance is using a pointer in this scope dangerous? Over time will the actual data reference change? The other possibility is to include a variable of all the different variable types, then switch between them based on type..... although im guessing this would be far less efficent. If i did use the above code should i expect a huge slow down over normal variable types?

Share this post


Link to post
Share on other sites
Advertisement
In general, if you're tempted to do something like this, you're using the wrong programming language. However, if you really want something like this consider looking at boost::any.

Secondly, you're storing the address of stack variables. This is about as non-kosher as eating baby piglets fried in lard.

Share this post


Link to post
Share on other sites
Ahhh, thanks i was hoping there was a decent library for this. Yeah i just wrote up the class then... there was bound to be errors.

Share this post


Link to post
Share on other sites
Well, the + operator doesn't make much sense on generic variable. What does:
Renderer r = ClientConnection + File + char;
evaluate to?

Then again, you cannot add int and a float together under current system.

There's also boost::any and cdiggins::any (use google), which take care of generic types.

And you could use union to store the types. It would have the same effect.

Share this post


Link to post
Share on other sites
Yeah a union could help. I only really need the string and double variables types, so the operators should remain applicable in most cases.... i'll just make it throw an error message if it attempts an invalid operation (aka string*string). I wonder which method is faster, the boost library or my class?

Share this post


Link to post
Share on other sites
Quote:
Yeah a union could help. I only really need the string and double variables types, so the operators should remain applicable in most cases.... i'll just make it throw an error message if it attempts an invalid operation (aka string*string). I wonder which method is faster, the boost library or my class?


If there is a known limited number of types that you want to store then you don't want a boost.any, what you want is a boost.variant, the overhead of retrieving a value from a boost.any is approximately a single virtual function call, however, the data is stored on the heap which adds significant overhead to copying etc... In contrast boost.variant is stack allocated and ensures that you provide an operation for each type, I'm not sure about the overhead of apply_visitor in boost.variant but it wouldn't be more then a single virtual function call and is probably cheaper then even that.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Secondly, you're storing the address of stack variables. This is about as non-kosher as eating baby piglets fried in lard.


SiCrane, do you mean he's storing the address of *local* variables (which I agree is bad)? I don't think storing the address of *stack* variables is necessarily bad?

It may sound pedantic, but it matters for my current project... Is there something inherently bad about this?

Thanks!

Share this post


Link to post
Share on other sites
The local vars are being created and stored on the stack, the address is then stored and passed out of scope, at which point the address is... well, SiCrane put it best "about as non-kosher as eating baby piglets fried in lard".

Storing the address of stacks variables isn't bad as such, but leads to life time issues which can cause the addresses to become invalid as things go out of scope.

Share this post


Link to post
Share on other sites
You can get away with storing stack variables in trivial programs. You have to watch out for object lifetime issues, and in a very small program it's easy to do so. However, in a non-trivial program it's easy to have a stack variable A that you store a pointer to in object B and then pass the object to entity C which then copies the pointer B holds. This is a problem that any use of raw pointer has: raw pointers have no associated ownership or lifetime semantics. But this is exacerbated by the fact that problems with stack pointers can happen iff an exception is thrown, or if foo() is called before bar() but after baz() or can cause a stack trash in seemingly safe code; problems with stack pointers can be a pain to debug. Besides which, it's a lot harder to turn a buffer overrun on a heap pointer into a security issue than it is to turn a buffer overrun on a stack pointer. Also, it limits the flexibility of your code if you have implied relationships like stored stack pointers; this in turn hinders refactoring, which should be considered an integral part of good code development.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!