That example leaks. It also requires the user (of the code) to be aware of the contents of the union, such that they have to make sure they assign the right types to the right variables.
This sort of defeats the idea of an easy to use any-data type.
creating a dynamic variable type
Quote:
I wrote you small example. It is not perfect, no error checking, but it solves your solution.
It actually doesn't -- your 'solution' contains an non-trivial operator=. An object of a class with a non-trivial default or copy constructor, a non-trivial destructor, or a non-trivial assignment operator cannot be a union member.
Quote:Original post by tychon
That example leaks. It also requires the user (of the code) to be aware of the contents of the union, such that they have to make sure they assign the right types to the right variables.
This sort of defeats the idea of an easy to use any-data type.
Yes I know. As I said it isn't perfect. It just shows my opinion on this question.
Assigning right values to union isn't so hard to do,
enum TYPE { eSTRING, eINT, etc... };
struct custom_value
{
TYPE typeOfVariable;
union my_data ....
};
Quote:Original post by jpetrieQuote:
I wrote you small example. It is not perfect, no error checking, but it solves your solution.
It actually doesn't -- your 'solution' contains an non-trivial operator=. An object of a class with a non-trivial default or copy constructor, a non-trivial destructor, or a non-trivial assignment operator cannot be a union member.
Actually I made this in VS 2005, compiled, runned and worked.
From the boost::variant docs...
Clearly another approach is required. Typical solutions feature the dynamic-allocation of objects, which are subsequently manipulated through a common base type (often a virtual base class [Hen01] or, more dangerously, a void*). Objects of concrete type may be then retrieved by way of a polymorphic downcast construct (e.g., dynamic_cast, boost::any_cast, etc.).
However, solutions of this sort are highly error-prone, due to the following:
* Downcast errors cannot be detected at compile-time. Thus, incorrect usage of downcast constructs will lead to bugs detectable only at run-time.
* Addition of new concrete types may be ignored. If a new concrete type is added to the hierarchy, existing downcast code will continue to work as-is, wholly ignoring the new type. Consequently, the programmer must manually locate and modify code at numerous locations, which often results in run-time errors that are difficult to find.
Furthermore, even when properly implemented, these solutions tend to incur a relatively significant abstraction penalty due to the use of the heap, virtual function calls, and polymorphic downcasts.
Clearly another approach is required. Typical solutions feature the dynamic-allocation of objects, which are subsequently manipulated through a common base type (often a virtual base class [Hen01] or, more dangerously, a void*). Objects of concrete type may be then retrieved by way of a polymorphic downcast construct (e.g., dynamic_cast, boost::any_cast, etc.).
However, solutions of this sort are highly error-prone, due to the following:
* Downcast errors cannot be detected at compile-time. Thus, incorrect usage of downcast constructs will lead to bugs detectable only at run-time.
* Addition of new concrete types may be ignored. If a new concrete type is added to the hierarchy, existing downcast code will continue to work as-is, wholly ignoring the new type. Consequently, the programmer must manually locate and modify code at numerous locations, which often results in run-time errors that are difficult to find.
Furthermore, even when properly implemented, these solutions tend to incur a relatively significant abstraction penalty due to the use of the heap, virtual function calls, and polymorphic downcasts.
Quote:Original post by streamer
Actually I made this in VS 2005, compiled, runned and worked.
This won't necessarily do much good for people like me that work pretty much exclusively with gcc. If cross platform is a concern for them, this is something you have to take into consideration.
Quote:Original post by jpetrie
That's nice. Doesn't make it correct, or a good idea. See section 9.5 of the standard.
Well, nevermind. That was my reply to this thread, actually I never said that it is perfect or right approach. This was my opinion. There are always smarter and better programmer than me, and possibly they know better. That is the way people learn. From own mistakes.
For example I'd preferably use LUA for scripting language and not write my own. 3dmodelerguy's opinion is that he want to make his own scripting language. He want to try hard way. I appreciate that. Maybe he will be better programmer than you and me.
This was just my humble try to help someone.
Quote:Original post by streamer
That was my reply to this thread, actually I never said that it is perfect or right approach.
If you don't think it's the right approach, then don't post it. Especially in the For Beginners forum.
EDIT: Sorry, this is a little off-topic. However, this is the beginners' forum, so I think this is worth mentioning...
I would argue that at an early stage in development, incorporating a scripting language into your game is a complete waste of time from a productivity standpoint. A scripting system is NOT a requirement of any game. The valuable time spent early in the project in incorporating a scripting language is valuable time that could be spent implementing features that the majority of players actually will care about.
With a little bit of forethought and planning, your game can be designed so that a scripting component could be implemented later. You may decide you don't even need it.
Quote:Original post by tychon
I'm won't speak ill of making a language, I admit I enjoy tinkering in it myself. Yet I also realize that it's a waste of time from a productivity standpoint.
I would argue that at an early stage in development, incorporating a scripting language into your game is a complete waste of time from a productivity standpoint. A scripting system is NOT a requirement of any game. The valuable time spent early in the project in incorporating a scripting language is valuable time that could be spent implementing features that the majority of players actually will care about.
With a little bit of forethought and planning, your game can be designed so that a scripting component could be implemented later. You may decide you don't even need it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
