C++ programming style

Question

I\'m an old (but not too old) Java programmer, that decided to learn C++. But I have seen that much of C++ programming style, is... well, just damn ugly!

All that stuff

Answer 1

If you want to do game programming, you probably want to work with other C++ developers, and this means you have to do things in a way they'll understand. If you hope to have any collaboration at all, your code will have to be in a reasonable C++ style. If you intend to be a lone developer, and have your code essentially die with you, use any style you like.

Moreover, C++ and Java are two different languages, and need to be used in different ways. There are reasons for the header files (think of it as declaring the interface), for example.

Answer 2

Find a style that works for you, just like everyone else did. Nobody is forcing you to use one of the "ugly" styles, unless it's your employer enforcing a guidelines document. ;-)

Though keep in mind that placing member function definitions inside the class as opposed to outside has different semantics. When you define a member function inside the class, it's implicitly inline, for better or worse.

Answer 3

I think many programmers cut their teeth with MicroSoft products (and their example code) and/or programming for Windows API and the early Microsoft coding conventions which were used in the code fragment in your question (I.e. Hungarian notation, capitalization of defined types, etc..). I loathe looking at source code from MicroSoft which looks like it has been run through a crosscut paper shredder and glued back together. But an ugly coding convention is not a function or reflection of the C++ language which I find no more beautiful or ugly than most other languages.

Actually, I find the C++ syntax with minimal keywords, curly braces and rich set of symbolic operators serves to not distract from or crowd out the important stuff: my variables, my type defs, my methods; which, of course, allows me to make the most beautiful code of all :-)

Answer 4

That's called seperating interface and implementation. That allows clients to figure out how to call your class without having to wade through all the code too. Frankly I think it's practically insane that people could consider it "wrong".

However, you will be quite pleased to find out that many C++ developers agree with you on that score. So go ahead and put your entire implementation in *.h files. There's a school of style out there that agrees with you.

Answer 5

That's not ugly at all. I would say it is... mhhh different. Bringing your old style to a new platform, that's ugly (I have had a lot of discussions about this with Mr. Skeet).

Remember Java was defined years after C++, so it is reasonable they've fixed some constructs (in the same fashion C# learn from Java).

So, I would suggest to keep in that C++ style.

Think about this. Header files are like interface declarations and cpp files are implementation.

I think C++ does not have "interface" keyword, and this is the way you separate the interface of a class from its implementation. Similar to this in Java:

public interface Some { 
    public void method();
}

public class SomeImpl implements Some { 
    public void method(){}
}

Answer 6

When the code builds, the C++ preprocessor builds a translation unit. It starts with a .cpp file, parses the #includes grabbing the text from the headers, and generates one great big text file with all the headers and the .cpp code. Then this translation unit gets compiled into code that will run on the platform you're targeting. Each translation unit ends up as one object file.

So, .h files get included in multiple translation units, and a .cpp file just gets included in one.

If .h files contain lots of stuff (including implementation), then the translation units would be correspondingly bigger. Compile times would increase, and when you change anything in a header... every translation unit that uses it would need to be recompiled.

So.. minimizing stuff in .h files drastically improves compile time. You can edit a .cpp file to change a function, and only that one translation unit needs to be rebuilt.

To complete the story on compiling...
Once all the translation units are build into object files (native binary code for you platform). The linker does its job, and stitches them together into you .exe, .dll or .lib file. A .lib file can be linked into another build so it can be reused in more than one .exe or .dll.

I suppose the Java compilation model is more advanced, and the implications of where you put your code have less meaning.