I came across this article proposing a style of coding in c++ that looks a bit weird at first. But after reading it over and pondering for a bit I'm really considering giving it a try.

The most appealing benefit is the ease of refactoring methods. I find myself constantly changing method names, parameters and so on while writing a new class and in c++ it's quite annoying having to change a method name in two files (.h, .cpp).

I tried to find something wrong with this style but apart from the fact that the code will look and feel really strange to seasoned c++ programmers I can't spot any major flaw. But since I am quite a inexperienced c++ programmer I hope that someone here might alert me to any potential dangers.

@ThomasEding could you elaborate? I changed struct B in the example to a template and it compiled just fine.
–
bughiDec 21 '12 at 0:56

1

I don't understand the point of the article. It goes agains everything considered good modern code in C++...
–
KlaimDec 21 '12 at 1:00

1

I like the seporation of interface from implementation. It is very easy to read the *.h file and see the interface at a glance (becuase it is compact). I probably never need to look at the source file unless it is code I am editing. Bunging everything together in a single file will destroy one of the features of the language I find the most useful (so no thanks).
–
Loki AstariDec 21 '12 at 18:16

4 Answers
4

Yes, you're going to confuse other C++ programmers if you write all your code like that. I have never seen non-template C++ code written that way, with everything in the header file. This has been discussed in depth in a Stack Overflow question as well.

You'll have to be careful to not run afoul of the One Definition Rule. Variable names will have to be unique across all source files, since it effectively becomes one giant file.

You also might want to check out the D programming language, which I hear solves a lot of these problems. The D compiler is designed with this style in mind and doesn't have 30 years of C backward compatibility to support.

We actually wrote C++ that way (everything in .h) in my undergraduate college studies. I'm not sure why. I had to learn how to separate things out and link them properly on my own.
–
KChalouxDec 21 '12 at 20:05

He makes many conjectures in his article that are flat out wrong. In no particular order:

Compile time

This is not issue either. Assuming you have all operating
system headers and frequently used containers (STL) or math libraries
in precompiled headers, and assuming that if your program is really
huge, you have separated it into components as per above, the
remaining amount of code is absolutely negligible for a modern C++
compiler.

This is just wrong, and it shows that he has never worked on a large scale C++ program. Download any large open source C++ program, compile the program, and tell me if you want to wait that long every time you forget a semi-colon.

Declare before Use

There is a C++ feature very few programmers seem to know about (or at
least, have exploited): and that is that inside a class, declare
before use doesn't hold (!). Clearly Bjarne was aware of this legacy
problem in C++ and fixed it for the inside of classes, but couldn't do
the same for top-level declarations because of backwards compatibility
with C (why? there must be some intricacy I am missing here).

That looks to me to be just giving a goofy name to doing forward declarations instead of #include <blah>.

The benefits to the forward declarations is that your compile times can be significantly faster, but the main drawback IMO is you have to be mindful of when you can and cannot get away with a forward declaration, and when you screw it up, you can get seemingly incomprehensible error messages for a trivial error.

It's not exactly a new idea. Beginning programmers avoid declarations like the plague, and mostly get away with it because their programs are so small. The consequence is that you now have to worry about the order you define your functions. The consequence of worrying about definition order is a temptation to minimize the problem by making your functions too big.

You also lose the nice separation of interface and implementation. The author himself laments the private members being part of the header file, then "solves" the problem by making all implementation details a part of the header file.