It's not wxWidgets, it's GetText library : http://www.gnu.org/software/gettext/

However I think it's bad for some type of games.
The first problem is that it assume you will put text in code and then translate later. If you do that, when you have some short sentences (or one word) that might be used in several context to mean different things, in other languages that might be different text that should be displayed. But then you have only one id, the original text.

However there is almost to other alternative at the moment. One promising library is being developped for boost (C++) but it will not be there until a lot of time. (you can still get in the mailing list if you want to participate to it).


I think a simple localization library + tool might be helpful for everyone here. The main thing that makes it hard to build is that the implementation of localization is really game-relative. I'm making a game where all the texts should be loaded at runtime start because texts are provided as language packs for future extension. Other devs would be happier (and would not worry about memory) with statically compiled texts (making several binaries, one for each language).
Making a good translator tool is also a hard task but it would be so useful. I've used some before, but only in companies I worked for so it's not free or open-source.

Oh, yes, sorry, I didn't sleep enough when I wrote that 

That's not an argument against this specific sentence.

The fact that C++ is longer to write have nothing to do with the fact that it's widely used and there is a lot of support for the language.

And whatever the reason you don't like C++, anyone of the reasons I listed is enough to make a language choice for a project - whatever the language.

It would be a non-obvious choice only if there were only bad reasons to choose C++. There are good. There are good to choose Flash too. But we don't all have the same need. Even on a per project choice.

Anyway, whatever your language of choice, don't blame other's choice. People here are not stupid. Even familiarity with language is a good reason in language choice because it helps getting to the point - even if you can write less code in other languages.

By the way, almost all the games I worked on at home required C++ for technical reasons (and other reasons too). At my day job I worked on Flash games. I don't care as fare as it works for the project. Let people make their choice for themselves.

There can be a lot of reasons to use C++ even for a little game, like :

 - training for building games with the language later, as it's used for more performance-required games;
 - training in hope to get a job in the industry;
 - planning for later additions to the game that will require performance;
 - not targeting web pages or requiring installed software for some features (like "modules" or scriping) - that said a lot of language can provide that but most require additional installations like Virtual Machines... ;
 - liking the way of mind of the language (pay only for what you use, very high and low abstraction layers,deterministic resource management);
 - working with other people already knowing the language;
 - using one or several libraries that are not available in other languages (C++ certainly being the language with the biggest pool of libraries, shared with C);
 - planning for cross-platform stand-alone application (some languages allow easier cross-platform but often fail to be executable on every platform you want to target...);
 - why not use a widely used language? lot of help is available out there if you got any problem.


I guess that's enough for today.

(Yes I know, it's still a hard language to learn, but still, there are good reasons it's used for a lot of games)
 

Personally, I use OIS (C++ lib) that allow to easily manage inputs whatever the keyboard settings.

Klaim, maybe I tend to design the core of my games wrong because I always end up using pointers in most places where I don't use handles, which are of course a completely different story. Even the handles though return pointers when they're dereferenced, not references. (Is it even possible to overload the dereference operator to return a reference instead of a pointer?)

It's not "wrong" as you can still achieve a working and efficient game( or whatever software) with or without pointers everywhere. In C it's the only way and it's efficient.

It's just less safe, more error prone. You could avoid a lot of common bugs and concentrate on those specific about your game.

so when you're converting a pointer to a reference, you've got to do error checking one way or another.

That is only true if you're converting an invalid pointer to a reference and that is bad. The other way around is always right if you don't do this.

So in fact the right way is to put assertions all around pointers usage (getting pointer value, passing it around etc) to make sure it's valid. THEN when you're using references, you don't need to check again, because you assume that your code that have been using pointers was checked.
As you used pointers only where they were necessary, you sudently don't have to check them everywhere in your project, only where necessary (in low level and generic code most of the time).
In other parts of the code, you're passing references or anything else that is suitable, sometimes pointers but only when you need them to be null sometimes. As thay can be null in those parts of the code, your code will naturally take acount of null because it's normal behaviour (like when you return a pointer from a "find" function that could return nothing but life continues if it does).

Then, you start to understand that when you use pointers and references, with and without constness, you, in fact, setup some kind of protocol.
The idea is that when you ask for (non-const) references as function parameter, you suggest that you will modify the given object but it have to exist.
When it's a const reference, you say that you'll just read informations from it but not change it's state in any way (other than mutable state...) but still it have to be an object that exist.
When it's a pointer as parametter, you suggest that, well maybe you'll provide some informations to process, but if you don't (nullptr) it's still fine to execute the function.

When you're returning a const reference from a function, you say that you can read the object but don't touch it!
When you're returning a reference from a function you say that you allow the user to manipulate the object and you suggest (because you write valid code, right?) that the lifetime of the object will be at least as long as the lifetime of the owner of the function (member or not).
If you return a pointer, you suggest that you may, or not, return a result but it's facultative and it's not an error.

So, the practice of reducing use of pointers to where it's necessary will modify how you think and organize your code from bottom layer to top layer, making code easier to manipulate the higher you get.

Sure but aren't pointers implemented the same way? When you say "the compiler remembers" you mean it stores it in a processor register, which is how pointers are typically done.

Just. Forget. About. Reference. Implementation.

As already said, they can be implemented in memory "like" pointers but they are not adn it's not always the case are nothing in the standard say how they should be implemented.

There is no other guarantee about references than they are just nicknames for objects and that they should then never be uninitialized (if your code is correct).

It's specified that dereferencing a null pointer or a pointer pointing to unallocated memory is undefined behaviour. So you should never get to this point. If you do, then you didn't hear the alarm ringing when you started to cast things around too much.

Back to your example, I would have put checking in the two functions each time I assign a value to a pointer. That's the pointer the source of the problem, not the reference.

Again, there is smart pointers too that help having null pointers without manipulating pointers, but we didn't talk a lot about it here. I  agree with Average Software about the alarming count of C++ programmers that prefer allowing mistakes instead of eliminating them where possible.

I almost always use const references rather than passing by value. Do you have some kind of argument why passing by value is better?

If you're using native types as parametters it's better to use value than reference (if it's const).
In function returns you'd better return a local object by value (if possible) than by reference as it's life is limited by the scope of the called function. For example you have to return a std::vector by value in a "search" function. But then don't worry much about performance : there is standardized optimizations that occurs most of the time, named NRVO (http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx for example, buyt it's valid for all recent compiler).

(c++ is really a lot of things to keep in mind together to code well... by the way, you should really read this : http://www.tantalon.com/pete/cppopt/main.htm )

Vino> As I said, pointers have to be used when necessary (when nullptr is needed, when manipulating raw memory etc). But when programming, you want to avoid errors, undefined behaviour and code that is hard to read.
So when you can use a better solution than pointers to achieve those goals, you should use it instead of pointers.
And there are a lot of solutions, that don't all replace pointers, yes.

That's not hate, that's more like knowing when to use the most useful tool for the task (and respect what is powerful/dangerous).

I would say the same thing about template/metaprogramming because, as pointers, it really really is helpful but you really don't need it everywhere it seem you could use it.

muku++ for reference to "modern usage of C++".

Notice: I use pointers when needed, I don't avoid them as a dogma

[require]

Pointers don't imply that at all.  You can easily pass around pointers to stack or global objects.

Pointers don't imply anything, as I said they CAN be source of management problems.

Please don't put what I didn't say in my mouth

You may want to check what you wrote again, you said that they require resource management.

Yes but that don't force you to make errors (that was the assertion I replied to)... Anyway you understood what I meant.

But enough about that, the general advice, which I also espouse, is to use references when you can, pointers when you must.  I would take this advice one step further and say:

Use values whenever possible, failing that, references, failing that, pointers.

Agreed.

I also forgot to add:
use and abuse of assertions, to check the context but also each time you get a pointer, check for it's state and as LemonScented said, be paranoid.

Entirely avoiding pointers is just a cowardly and bad solution.
If you're never going to use them, why even use C/C++?

Not using pointers for any game that takes more than a a night to make is asking for trouble and awkward solutions.
Pointers that are correctly used are powerful, and if you know how to use them, they don't cause trouble.

Who said "entirely avoiding pointers"?

I say "use them when you must, not when you can".

Pointers don't imply that at all.  You can easily pass around pointers to stack or global objects.

Pointers don't imply anything, as I said they CAN be source of management problems. Avoiding manual management when not necessary is just preventing future coding madness. Sometimes you need it, sometimes not. When you don't need it, why use pointers? You have other cheap solutions that almost totally negate common errors of manipulation of pointers.

Please don't put what I didn't say in my mouth, that's obvious that you can't use C++ without pointers in a big project, but that don't force you to use them every time you have to provide some kind of reference to an object.

By the way, recently I've made a game (SHMUP) prototype with only C++/Boost/SFML and there is almost no raw pointers in my code (only some in one array). That was just not necessary most of the time, and I see the same thing in my dayjobs too.

Use pointers when you MUST.

LemonScented have a good point, and that's exactly where I use them most of the time. In fact in those case I also have other solutions but they often become too overkill compared to pointers.

It's not about not using at all pointers, they are necessary for a lot of manipulations (mostly low layer) but you can avoid them most of the time (in fact in a lot of high layer code)

I have simpler rules of  thumb with pointers and references that make things easier:

 1. References are nicknames. Forget about how they are implemented, it's not important. Just think of them as nicknames.
 2. Don't use pointers.
 3. If you have to use pointers, because there is no choice, then try using smart pointers instead.
 4. If you can't use smart pointer and have to use pointer, use pointer.


About 2,3 and 4 : the idea is that raw pointers require resource management that can easily become source of bugs, so if you use references and smart pointers instead of raw pointers when you can, you limit the parts of code where there might be pointer management bugs.

One case where you have to use smart pointers (whatever smart pointer appropriate) or raw pointer (if appropriate) is when storing them in STL container.

The reasons is that as references are nicknames, they can't be nicknames of nothing, they really have to be initialized with something to be nickname of.
In the containers, the objects have to be constructible and copyable. Nicknames can't be copied! They are just nicknames! Not objects!

About smart pointers : std::shared_ptr (if you have a recent compiler) is the most common because you dont have to manage it at all. The coming standard will have std::unique_ptr that is excelent to manage ownership in some cases where std::shared_ptr is not "right".

Why not create another twitter? Just use a name like the team name (even if you're alone) or something like that.

I totally forgot this topic!

I'm currently working on a tool made to allow easily building digital comics! And its free and open source! Stay tunned!

Anyway, I translated my webcomic and added flattr buttons : http://lifeturtle-en.webcomics.fr

And I wanted to point this as it's inspiring me since it's out (and I had some real world chat with the author) : http://balak01.deviantart.com/art/about-DIGITAL-COMICS-111966969?q=&qo=

No (sorry for the late answer).
Don't forget it's to help YOUR game that you add localization, not to help others (and French are often egocentric).

So in your case (and I'm in the same one in fact) I would ALLOW localization and then focus on english, and see later for other languages maybe helped for free by community members.

1. Boost being the nest of most new standard libraries, most new standard libraries comes from boost.

 1. The random library is basically from boost, so if you want to try it, get boost
 2. The closure feature and many other are already implemented in VC10 and a lot more in gcc http://gcc.gnu.org/projects/cxx0x.html
 3. C++0x will allow us to write clearer code with less typing; in theory at least.

I've learn so much since I started my project that I can't wait to get back on it (paused for another "shorter" project since the start of the year). The more time I spend doing something else, the more details I clean in my head to simplify everything when I get back to it.

Now, as I explained before, I really think that most games really require "long" time periods to be mature, but also require "short" release iteration rythm.

For example, if you can make a game working in a month or two, then polish it enough for a month to make it showable/sellable, then release it; then work on it 2 more months, polish 1 month, release it... until you aren't motivated enough to continue or any other "good" reason.

My wish is becoming true : http://area51.stackexchange.com/proposals/2825?phase=definition

IF YOU WANT TO MAKE ME LOVE, PLEASE VOTE FOR IT!!!! XD

(and for the "Making Comics" one that I created too, if you're interested)

I was really hoping the C++0x would add some kind of static initializer capability.  Ada and Java (I think C#) can do it, and Ada even goes the extra mile and lets you control static initialization order.

You will have to wait for a module system to allow some kind of global initialization order. That'll be discussed again for the next-c++0x standard. You can read what was the last draft there : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf