Talk:C++ Programming/Unions

We need a better Unions example
This book contains a textbook example of C unions, a textbook example which is also wrong. In fact, it's so wrong that it's technically not spec-valid: The C and C++ specifications don't allow you to use union as a reinterpret cast or a bit-manipulation tool. It specifically says only use one of the union members, not to do something stupid like putting multiple integer types in a union so you can get the individual bits out. We have masks and shifts for that; bitfield structures for the super-fancy types; and if you're really dead set on demonstrating the 'shares memory' use of unions, Byuu has a nice bitfield template hack which does even more than standard C++ bitfield structures.

The SDL_Event example is better, but it's C specific, and it doesn't communicate why unions are used. After all, in the next page over, the reader is going to learn about polymorphism, which is much more open-ended than a tagged union type. Part of this is the fact that unions are more useful in C than in C++; again, in C++ you have polymorphism so that you can have the program select implementations for you at runtime. Part of this is that C and C++ have really crappy union support in general - in functional languages like SML you get tagged unions which automatically trigger different function implementations based on the union tag.

Here's my recommendations. First, we need to push back unions until after classes. Classes and structures are much more useful than unions in day-to-day programming work. I'm operating under the principle that we should be teaching the most useful tools first, as most programmers are going to be focusing on the first few tools we give them. We also need to teach enums at the same time as unions because all the useful things you can do with unions also involve enums. (Going back to the C/C++ have crap unions thing, in languages with good union support, enums are just unions with no members. In a way they're really the same thing.)

Secondly, we need a better example than "unions let you share memory". Really, the purpose of unions is polymorphic data. You use them when you want a piece of data to be one of multiple possible types. Say you have a function which can take a list of items, possibly for serialization or what have you, and those items can be integers, floats, STL strings, or complex numbers. The unions way to handle this is to have an enum type with a value for each possible data type, and a union type with each possible data type inside. The example would have to demonstrate both storing data in a union type as well as doing something useful with it. But I'm not creative enough to think of a better example than a set of miscellaneous types. Maybe later. Libertardian (discuss • contribs) 22:28, 25 December 2012 (UTC)


 * I haven't looked to the example only to this post, if your assertions are correct I'm with you all the way and do not mind any of the proposed changes, I will even try to do it myself has time allows the only concern I have is in the bit about putting structures after classes.
 * The issue really depends on the type of logic one adopts, since this book uses the C first option (there has been many people objecting to the approach, but I still think it is the one that is most logical to the student of the language, especially if he already understands C, the objective of the book is not to lock anyone into a specific language or mindset but to expose it openly. C to a large degree is C++ also.)
 * In that regard I have taken all the chances I had to promote the proper C++ way of implementing and any C vs C++ approaches advantages. I also think that this is beneficial as it promotes educated choices not simple adoption of default approaches. I think the text about unions that I wrote (I don't know if many changes have been made to it, clearly states that there is rarely any reason to use unions.)
 * In any case I will try to look into it but if you have the time do it yourself... --Panic (discuss • contribs) 00:03, 26 December 2012 (UTC)