• Advertisement
Sign in to follow this  

Is this a valid usage for unions?

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

Hello all,

recently I decided to discard my hand-written math library code and use the GLM library.

Because I want to make it "feel" like my own code need some thin wrapper around it. Because performance matters I don't want to
write the wrapper using inheritance like this:


class Vector3 : public glm::dvec3
{
};


Now I have the idea to use a union and write code like this:


union Vector3
{
public:
Vector3(double x, double y, double z)
: v(x, y, z)
{
}

double x, y, z;

private:
glm::dvec3 v;
};


Is this valid code (using C++11)? Edited by madRenEGadE

Share this post


Link to post
Share on other sites
Advertisement
Access to members of a virtual base and calling virtual functions will typically result in a small performance penalty, but in the kind of inheritance you've shown, there will be none.

The doubles x, y and z in your union all occupy the same memory location. Presumably that's not intended.

I also suspect that you're heading down the road of type punning through the union, which strictly speaking is illegal, though some compilers explicitly support it. Take care.

My recommendation: typedef glm::dvec3 Vector3;

Share this post


Link to post
Share on other sites
Partially answering myself.

of course
double x, y, z
does not work.

So I have to use something like this:

union Vector3
{
public:
Vector3(double x, double y, double z)
: v(x, y, z)
{
}
inline double x() { return d[0]; }
inline double y() { return d[1]; }
inline double z() { return d[2]; }

private:
double d[3];
glm::dvec3 v;
};


Actually I wanted to avoid the method calls for accessing the data members...

Are compilers smart enough to optimize this code (this post) so that it performs as fast as the first one (previous post)?

Share this post


Link to post
Share on other sites
Using
typedef glm::dvec3 Vector3
was my first idea BUT I want things like the cross product to be used as member functions. GLM implements them as
normal functions taking the two vectors as parameters.

But when the inheritance I have suggested does not have any performance penalties I will go that way. Edited by madRenEGadE

Share this post


Link to post
Share on other sites


GLM implements them as normal functions taking the two vectors as parameters.


That makes perfect sense I'd say; as a cross product is a pure function, to have it appear to "act upon" any particular vector would be strange. A cross product also has no need to access or manipulate the (non-existent) private state of a vector. Free functions also play nicer with generic code, FWIW.

Share this post


Link to post
Share on other sites
Same reasoning (IMO). One input, one output, no dependency on the private state. Edited by edd²

Share this post


Link to post
Share on other sites
I don't think you want to be using a union here, it might work one way or another, but I can't see this as being considered good practice

I'd just go with the inheritance if you want to add some of your own functions, I can assure you that the "performance penalty" that could possibly be introduced by it will be least of your worries in the end. Otherwise go for the typedef, clean and simple.

By the way, only worry about optimizing these little things like inheritance overhead if they actually pose a problem, and in this case it'll probably never become a problem. In the end there will be loads of better candidates for optimization before you should even consider looking at overhead caused by language mechanisms.

Share this post


Link to post
Share on other sites

Same reasoning (IMO). One input, one output, no dependency on the private state.

I think you are right, at least if normalize creates a new vector. But when I really want to normalize the instance normalize is invoked on, it needs access to the state. But maybe that is not the problem as the state is public...



I don't think you want to be using a union here, it might work one way or another, but I can't see this as being considered good practice

"Good practice" is enough of a reason for me to not use unions for this smile.png

So decision has to be made between "inheritance" and "typedef + free functions" Edited by madRenEGadE

Share this post


Link to post
Share on other sites
You might want to look at the coding style for the rest of your code (I assume you're writing a game?) and adapt to what fits best with that so you can save yourself the headache of having to keep different coding styles in mind later on

If there's no other code to speak of and if you're comfortable with it I'd say go with edd's suggestion. Edited by Radikalizm

Share this post


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

  • Advertisement