Sign in to follow this  
Dead6re

Game Implementation Issues

Recommended Posts

Hello all, I was wondering if people could voice their own ideas about using std::string vs their own implementation of that class? Would you do it? Why? Why not? (Why recreate something that is optimized for you for example). I was wondering if there were other issues that people have, for example what type of passing parameters do you do? Pointers, Reference etc. Thanks

Share this post


Link to post
Share on other sites
Personally, I would never use my own implementation of a string class. Working with pure strings (i.e. char*) is a huge pain in the neck, and to get a solid, working implementation of a string class is very very time consuming. There are virtually no cases I can think of where std::string isn't fast enough. With that said, I *have* written my own implementation at one point, because I was working with heavy size constraints on my executable. That class turned out to be a source of constant agony, and in the end I threw it out and worked with char* directly instead (something that is highly not recommend).

Stick with std::string, it's fast, stable and solid. My two cents, anyway. ;)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this