C++ is my language of choice. There's really one big unavoidable reason for this: Outside of C and maybe HTML5/javascript it's the most portable language there is, and I like having the choice of using the extra features C++ provides over C. Part of our business plan is to jump on new platforms early. Since we don't have to support most of the community we can beat Unity to market by a month or two except when they get early access. This leads to lots of sales we wouldn't otherwise get.
Outside of that simple business reason, I really like C++. It's built on the foundation of being able to ignore any features you don't like. It's also huge and not a lot of people understand everything inside it. Many companies define their own individual subset of features they allow and don't allow. Some of these have good reasons and others are just traditions.
This is not a post about what all companies or even you should use when dealing with C++. It's just the current state of our own guidelines. We currently work with iOS, OSX, Win8, Win7, WP8, Android NDK, and Blackberry. We have also worked with Wii in the past, and have been looking at some more exclusive platforms.
C++11:
I've been holding off on the C++11 features because not all platforms we work with had full support for it yet. This has been changing rapidly. It might be time to lift the veil on it and start using at least some limited features but I need to research the support first.
Operator Overloading:
Operator overloading is not banned and is used in our code, but carefully. I'm not a big fan of operator overloading for two reasons. Firstly it can be non-obvious what is happening in the code with a cursory glance, especially if implicit casting comes into play. Secondly some operators can lead to extra allocations that don't need to happen. I really don't like the + operator for this reason and prefer to use += just for the reason that if + exists it will be used in some places without caution. If I could make the IDE pop up a warning every time + is used I'd be more likely to allow it. Some of the C++11 features might make this a non-issue.
Templates:
I love templates. Since I'm not working on embedded systems, code text size is more important to me than compiled code size. Even so, Trick Shot Bowling's lib comes in under 1 meg. We don't have vec2, vec3, vec4, mat16. Instead we have GHPoint templated with type and count. The amount of code we can share because of this is awesome. I tend to think that companies avoiding templates due to compiled code size are often not aggressively shrinking their uncompiled code size and dependencies.
Also, templates can be a great optimization for removing virtuals where needed.
Virtual Functions:
Most of your code is not called at a frequency where virtual functions matter. Most of your objects are not instantiated enough for the virtual function table pointer size to matter. The trick is to figure out which parts of your code are too high frequency, and avoid virtuals there. We don't use virtual functions inside TransformNode or Point due to volume of objects. If we were using a software renderer we wouldn't use virtuals on a per-pixel basis. It's a fuzzy line of where in the engine to stop using virtuals.
STL:
We fully allow STL everywhere. Part of the reason we can do this is we only have two programmers who both have a pretty good understanding of what STL is doing. We are not likely to grow a vector of concrete objects a bunch of times by repeatedly pushing back without first ensuring the vector is big enough to hold everything.
This has been a somewhat controversial subject among programmers in my career. I have interviewed people who said we should ban STL and couldn't tell me why. I always ask why when I encounter resistance to STL. Some of the reasons are pretty sound.
1) STL is slow
I don't believe this has been true for many years. Poor use of STL without understanding how/when it allocates is slow, or using the wrong container for the job is slow. I don't expect people to achieve speed improvements by writing their own containers that conform to the same model as the STL containers. There are always exceptions.
2) STL is not supported cross platform
This was true 3-4 years ago when the Android NDK first came out. I don't currently know of any platforms that don't have good STL support.
3) You don't know what the implementation will do on different platforms.
This is partially true. The STL spec provides some things you know to be true everywhere, and leaves others up to the individual compiler. There's always the chance of a rogue implementation out there that isn't quite STL but conforms to the interface.
4) Dynamic allocations all the way down.
Map and set are really bad for causing memory fragmentation without spending a lot of effort on a custom allocator. A misused vector can easily cause a ton of memory problems, such as often removing an item from the middle of a vector. I have seen map replacements that stored entries of pairs in a vector instead of a tree which actually searched faster than map for under 1000 elements. If I were to ban any part of STL it would be map/set, but they are currently flagged as use with caution, and use due to laziness but remove if it becomes an issue.
5) We use a fixed memory layout and STL causes problems with that.
I can't argue with this reason. Having a completely fixed memory layout has a lot of advantages and is pretty difficult to do overall. I'm not sure this is really required for any modern platforms outside of the Wii with its tiny Mem1. We have chosen not to go down this path for development speed reasons.
6) STL has a complicated/hard-to-control memory pattern.
This is another reason I can't argue with, and I've been told I should look at EASTL which is something I intend to do.
RTTI:
I freely admit that I don't use RTTI simply because it used to be slow. I have no idea if it's still slow or not.
Exceptions:
Exceptions are banned partially for the "used to be slow" reason, and partially because I think the flow of control can become hard to understand.
Multiple Inheritance:
Multiple inheritance is currently banned partially for experimental reasons. We looked at porting to WP7 using an automated C++ to C# converter with the old engine and were prevented from continuing due to our use of multiple inheritance. The new engine instead uses inner classes of the type we would otherwise multiple inherit, such as MessageListener. This does lead to extra boilerplate but overall feels cleaner and safer.
Deep Inheritance Trees:
There's no explicit ban on having a long inheritance structure but it is not used. Probably the deepest we go would be Interface->Concrete->Specialization. We prefer the has-a model to the is-a model due to placing a huge emphasis on re-usable widgets.
Raw Pointers:
We use them willy nilly. If we had to deal with less experienced programmers this might be revised to only allowed in certain parts of the codebase. I can see how this could make our codebase dangerous because of potential confusion about who owns the pointer. We use a templated ref count wrapper for objects that have shared ownership.
Void*:
Yup. We use void* as return values in our loading code combined with a lack of RTTI and this has caused us problems. The caller of loading something from xml or the resource cache needs to know what to expect from the data, and the data has to match up with those expectations. I'm not sure I could begin to justify this in a larger company environment. It does give us an extremely powerful loading structure with a tiny interface though.
