On Windows machines it's best to place savefiles in %appdata%. Depending on the situation you can also place them directly in the home folder for them to be more accessible to the end user.
On Linux there are a few locations, most applications put user created content in ~/.local/share/<app_name>/ and user configuration files in ~/.config/<app_name>/. System configurations (things the user shouldn't touch) are usually placed in /usr/local/share/<app_name>/. Again, depending on the situation, you may also want to place user files directly in the home folder ~/.
Still... what might "well-coded" games in C look like? Or would it be quite close to a game in C++ but mostly just without the encapsulation given by things like access modifiers, and semi-advanced concepts like templates?
Being someone who is currently coding a game in C for the lulz, I think I can answer this.
The structure of code is quite different than what I'd do in C++, but the same basic concepts apply. For instance, a lot of systems have system_init() and system_deinit() functions instead of constructors/destructors. There are no classes with methods, but there are structs for holding data and functions which act upon the data of these structs. Templates don't exist, but you can implement the majority of what templates are used for with macros. Compositing can be done with structs.
Polymorphism doesn't exist per se. I've seen my fair share of home made polymorphism in C, but I believe it's not really necessary. Most of the time you can composite.
I started a project as a somewhat average programmer with some artists, but I chose a game that was so far out of my league we had to can the entire thing after a few months. I disappointed everyone on the team.
One of the team members wrote me a really long and hurtful message. Spraying salt on my skinned body would have been less painful than some of the things he said, but it was the truth. He felt extremely passionate about what we were creating, and he blamed me for being an incompetent idiot for throwing the entire thing away and wasting everyone's time.
Trust me, you do not want to go through that pain. I learned my lesson the hard way.
(;) is a null statement and usually compiles to nothing at all.
A compiler I was working with for programming MSP430 microcontrollers would interpret a null statement as an actual NOP instruction. If I had pasted that thing into our code a lot of people would have been mad.
I know Ogre3D is using boost.thread in the background for rendering, so it is asynchronously reading from scene nodes, but I'm not synchronising when writing to the scenenodes. Why is this working fine? Is it safe for me to continue doing this?
Another question I have: The thread pool I'm using uses std::thread, but Ogre3D is using boost::thread. How do I synchronise objects being shared between the two?