Whenever you deviate from the standard way to doing things, you run the risk of making the lives of your coworkers harder, either by making your code less readable or harder to interact with. While it is acceptable to deviate from the standard approach when developing the implementation of a complex module (for expressiveness or performance reasons) altering the interface of your code in any way beyond what your standards mandate is just a recipe for teamwork disaster.

Besides, you always work as a team: the "you" from today is a different person from the "you" two months from now. So this also applies if you're alone.

The end result is that if everyone in a company or team (or your own experience, if you work alone) uses solution A instead of solution B, then everyone will use that solution until the benefits of switching to another solution exceed the pain of doing so.

Since games are not big users of strings, deciding which strings to use is not important, regardless of the arguments towards either choice. Unless you're ready to dive in for a complete re-learning of all string techniques, use whatever takes you the least time to implement (or is already used by your team).

As for pointers/references, it is a matter of taste—C programmers have years of experience using pointers to implement reference semantics and thus can cleanly avoid most null pointer issues. C++ programmers have more experience with references. Therefore, beware the programmer that uses pointers but does not know how to avoid their pitfalls, but do not complain beyond reasonable limits about people who use their tools appropriately.

I always use std::strings now since they give me everything that I need in a nice clean interface. I especially like how it dynamically allocates memory for me on the fly and I don't have to worry about it.

Dulce bellumoptimization inexpertis.

Quote:Michael A. Jackson
The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.

Quote:Rob Pike
Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is.

Quote:Donald Knuth
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

The moral of the story being that using your own implementation is sane, if and only if you have proven* that in your real life code (and not in useless micro benchmarks) the implementation that is blessed by standards is a serious bottleneck.

* by using a profiler, e.g. valgrind, or one of Intel's or AMD's

std::string is excellent as a general string class and there is no reason to, or point in, rolling your own equivalent. I use it all the time.

Sometimes I work directly with const char *'s if I'm dealing with string literals but not actually doing any processing on them. In this case I don't require any of the functionality that std::string provides so it's more efficient not to use it and, I think, a clearer hint to prospective readers of my code for reasoning about the purpose of those strings.

Perhaps, I wouldn't use std::string as much if Boost/SC++L introduced a library for different kinds of string with different implementations. As it is now the standard leaves a lot of leeway when it comes to the exact implementation of std::string and by and large this is a good thing, but for optimisations and even just to avoid the ugly const char *'s it would also be nice to be able to switch to a std::literal or std::cow_string.