The C and C++ keyword enum is a useful feature in the language(s). What it allows, is, to be blunt, an enumeration. A common example is, a group of constants, that are related. For example, you might have an enum of colors – something like :

By default, the first value is 0, the next is the previous value + 1. However, there’s some variations. First, you can tell the compiler the value of specific constants. For instance, if you want RED to start at 1, then you would do :

You can also declare something to be of type Color (after the enum Color has been defined; though see later about enum classes [feature of C++11]). There’s a common issue though, which I’ll get to in a bit. Firstly, know that there is also the anonymous enum. That generally means something without a name (clever name, I’m sure). What does it look like?

And that concept is useful (though not required) in solving the issue I referred to. More on that later.

Now, in all the above cases, you can refer to the constant (by name, e.g., GREEN) by simply ‘GREEN’. Problem however, is if you have an enum of another type but also could use a name like GREEN. Now, that may not appear to be an issue, but it is. The reason is simple: the variable is of type Color, but that does not mean it is in scope Color. That is to say, it is very much like having two variables with the same name. For instance, an unsigned int called ‘i’ and an long int called ‘i’ in the same scope. The variables cannot be declared more than once by the same name in the same scope (you will get a redeclaration error).

So, C++11 added enum classes (and consequently, enum structs). Recall that a structure access modes are public by default and classes are not (hence the use of the friend declaration in C++). Otherwise, they are the same. So, how can you fix the name clashing?

You use enum classes! And just like a class/struct, in C++, you can also inherit (in the case of enums, as far as I recall, it is of integral types). That means that you can make an enum that inherits from long long (as opposed to the default int).

Here’s how :

However, how do you access it? It’s some what of a ‘static’ variable in a class. What that means, is, you specify the scope, in this case the scope ‘Color’. So, for example, to make a Color variable BLUE in the above enum, you would do this :

Now, back to where I referred to a problem that is commonly encountered. One example, is, the switch statement, and in particular, case blocks. I won’t discuss that one, but when you do encounter it, you can get around it the same way as I will explain. It will basically be a type conversion error. Sure, you can add a cast, but that seems so wrong in a more type strict language. After all, this is C++, and not C – you don’t cast nearly as much, and ideally you don’t cast at all (obviously, that isn’t always possible, say socket handling via the BSD Socket APIs but its best to try to avoid it). Is there really any harm in it, for an enum? Not really for a basic, but it also isn’t necessary (in that case or enum classes).

The specific problem I had, is for example, an enum sort of like this :

Now, although I could prefix DEBUG and LOG with something, I think it makes more sense to have intention fairly clear (and the names [not in this example] were relevant to multiple groups of flag types). So, if I had another enum, or some thing else with the name DEBUG or LOG, then I would have name clashes. So, my attempt to fix it (above) would allow me to specify Flags::DEBUG. However, when you make it a class, it is, well, a class. So, we’ll assume that we have a function called set_bit that takes one argument: an unsigned short. What happens if we try to pass a Flags::LOG to it? It won’t work, because its not actually an unsigned short. To that end, a ‘case’ statement in a switch block, of that type, won’t work either because switch/case expects integral types. So, what can be done to work around this?

Maybe there is a better way, and sure you could just have them be individual variables, but what I found as a nice way, is the following set up:

Use a namespace by the name Flags. Inside that namespace, you can put an anonymous enum (or not anonymous if you want) in with the variables. This will isolate the variable to namespace Flags.
Thus, you can now do :

and indeed pass Flags::DEBUG or Flags::LOG to the set_bit function.

Only thing to be aware of, is that namespaces do have one feature that could be an issue. Its not really hard to fix, though, and issue is relatively speaking (loosely defined). Namespaces can be in multiple files; that is, you can define enums in the namespace in one file, and in another file do the same thing. Basically, though, if you have a risk of that, you can use the same idea. For instance, nesting namespaces (e.g., namespace somenamespace inside another, and inside somenamespace you have the enum).

The real benefit of this idea though, is that it allows you to make more use out of enums (when what you’re doing would make use of enums), without having to use casts or worry about name clashes. And of course, you can also just use a separate variables inside a namespace. It really is up to style and the actual reasons for needing the variables. In my case, I created a dynamically sized set of bits (read : std::bitset but not having to have the size at compile time. And no, it has nothing to do with a vector of bools) and I was tired of having code that looked like a file of #define’s (even though I didn’t use #define, and instead used const’s, the fact is it was individual variables and a long list with prefix’s to each variable). I didn’t like that. This is not C, and anyway C has const too nowadays. So, I wanted to clean things up, and in my case, this was quite useful.

(Update on 09 May 2012 – I fixed the option on the first line. I had by accident put -std=c++1x but it is actually two 1′s, not a 1 followed by an x. The previous version allowed for -std=c++0x and I probably adapted it in my head without thinking about it.)

As of 22 March 2012, GCC 4.7.0 has been marked the latest release. What does this mean? Well, it means that the option -std=c++11 is now allowed. Although RedHat based systems have had builds of it, it is now official. So, on the 22nd, I decided also to backport GCC again. The instructions are nearly the same, only the file from my server you download is http://xexyl.net/rpmbuild/gcc47.tar.bz2 and the spec file you build is ‘gcc47.spec’ instead of ‘gcc46.spec’. Otherwise, you need to adjust a few of the commands. This time I will include a bash script (that also will install svn because it may very well not be installed by default). You can find the script at gcc47-build.sh. Run it in e.g., a mock shell. Note it’ll download everything and then start the build. Note that it might be best to use it more as a reference; that way, you can see the commands to run (it doesn’t take into account you should build as the mockbuild user. But if you don’t do it in a mock shell that might not exist anyway, so you may or may not have to adjust things. Also if the person who made the script [i.e., me] was stupid and wrote yum install svn instead of yum install subversion then it might just fail there too. Fixed as of 2012/05/17. In addition, I will likely be updating the version soon with some cleanup to the rpm spec file as well as shared libs too. Further, it seems binutils more recent version fixed the problem below, so I’ll likely remove that too.).

Note: in Red Hat Linux 6 and higher (<= 5 is not affected. It has to do with binutils version) there is more than one ld (linker) program. In RHEL 6, /usr/bin/ld likely links to /etc/alternatives/ld which will be a link itself to one of /usr/bin/ld.bfd or /usr/bin/ld.gold – and there’s a potential issue. I have in the RPM spec file a variable (called ‘use_gold’) that when it is 1, it will check if /usr/bin/ld.gold exists, and it does, then it checks if /usr/bin/ld is a symbolic link. If both are true, then it will relink it to /usr/bin/ld.gold. On uninstall it does the reverse (I was lazy and did not check /etc/alternatives or use the alternatives command to update it; maybe I should, but for now I haven’t). Why all this? Because I ran into a problem when including some C++ header files (example iostream). The linker ran into an issue and failed to build. ld.gold will work and ld.bfd (at this time) does not.

That out of the way, I’ll say that GCC 4.7.0 is more restrictive and THAT is NOT BAD but actually GOOD. It not only will tell you about more possible issues in your code, it can reveal potential bugs in your program (that end up being compile time errors or warnings in other cases). That is good. Never ignore warnings (obviously errors you can’t). Okay, you can ignore them when say compiling a huge program (like GCC), but those are tested thoroughly and that even runs a test suite after compiling. The reason you don’t want to ignore them at compile time is because if they crop up later in the runtime, then you may be hard pressed to know where the real problem is (I’ve discussed this before: see my article about memory corruption).

Among one of the new features of C++11 is the major improvement to smart pointers. The unique_ptr recognize and accepts move semantics but it does not accept or recognize copy semantics. Some constructors will automatically be default deleted because of this. But that’s not bad, if you think about it: if you have unique ownership, then you aren’t very likely to have one ‘owner’ delete (as opposed to C’s malloc and free functions) it, only to use it later and dump core (and that would be the best option, as I discussed before in the other article).

I’m not about to begin explaining move semantics or perfect forwarding: there’s enough documents out there about it, including the original proposal/draft. Instead, I’ll discuss the smart pointer known as unique_ptr (in namespace std), and unique_ptr’s in standard containers (maps, multimaps, their unordered counterparts [also new feature of C++11], and vectors).

A word about raw pointers. Since unique_ptr’s only allow one owner, you have do have to take care of the fact that you can move it to a new owner, or not. But, what if you want to, say, keep its owner (say, have it in a map or some container). You want the container to be the owner. But then you want to (or need) to modify something in a function or class function. Or what if you need the pointer in more than one location? For example, in the project I referred to in my latest post (before this one), it has a map of ‘characters’ (it’s a rewrite of a type of game that is the predecessor to today’s MMORPGS). This list/map/whatever owns the pointers, and when it is removed from the map, its destructor is called. However, it would be less efficient (certainly more time consuming for the engine) to go through (potentially) the entire list (say, over 2000) just to find a character or item in a location that is already known (we’ll call it a ‘room’, e.g., to look at a character there). In short, it is some times convenient to have a list (e.g., a vector) of raw pointers. The class that has this list does not necessarily own the memory, nor does it have to allocate, or do anything except remove and add the pointer to a list. When its removed from the object, the real piece of memory still exists, just the object no longer has direct access.

So, anyone who has worked with smart pointers would know there is a way to get the raw pointer. A smart pointer has the get() member function. Now, note that the variable in question, is not (for example) a Object*. Instead, it is std::unique_ptr<Object>. What does this have to do with anything? It means as much as this. Normally you  would dereference the pointer to a class or structure, by, say the -> operator, e.g., character->get(). However, it isn’t the way in this case. Remember that the variable is not a pointer. Rather, its std::unique_ptr holding a pointer to an instance of an object (say of type Object). In other words, it holds an Object*. That means we don’t use operator-> but instead the dot operator. What this basically means, is we would do something like this (if we had an unique_ptr and we wanted a raw pointer to pass to some function) :

Object* o = uptr.get();

After that, uptr is the unique_ptr (and still has ownership), o is the raw pointer, and *o is the actual object (recall that * is the dereference operator in this context and to dereference a pointer means to access the actual place in memory that the pointer points to).

Does this change when its a container of std::unique_ptr’s? If you have an iterator for example, then absolutely yes. Why? Well, before you have the actual std::unique_ptr, right? It’s not actually a pointer itself, so you use the dot operator. But if you’re iterating through a vector (for example) then you would use operator-> ( or the equilvalent way: (*iter).member ). This is because again the iterator is not the actual object but (essentially, certainly if you think in terms of functionality) a pointer. And what happens when you want to access a member of a pointer to some structure or class? You dereference it first. To add to that, and possibly confuse matters, if it’s a tuple (of some kind) then you have the first and second members. So if you have a std::pair> called mypair, then mypair.first is an int, and mypair.second is an unique_ptr. So if you’re iterating through a container that holds that pair (say, a map) then you access it more like this :

or

Basically, iter is the iterator, you dereference second (which is in this case an unique_ptr) and then you access the get function. That function will return the raw pointer.

There’s two other new smart pointer types: std::shared_ptr (think of reference counting) and std::weak_ptr (which is used along with shared_ptr’s). There’s many other nice additions. That includes threading support, new usage of auto keyword (yes, folks, it existed for decades despite what some incorrectly think), a new way to work with time (system time, durations, etc.) and much much more. I would suggest you get used to the new standard if you use C++, because it has a lot of nice additions.

To close, I’ll go back to something I said I won’t go into detail with – the move semantics. One thing I will show is an example used in the proposal. Due to variadic templates, we have perfect forwarding. This allows something really cool. Let’s say you don’t know how many arguments will be passed to a constructor. Then, say, you want to create a lot of unique_ptr’s. Well, you could write out the more explicit stuff, or you can do what I do to make code clean. That is to say, have a header file that includes the libstdc++ header file that makes std::unique_ptr (and other things) available and add a function that does perfect forwarding to the constructor. The file is simply this :

To use, simply do something like :

Yes, that’s what auto now does: it automatically deduces the type as best it can. If it can’t, the compiler will tell you so and you’ll have to fix it.