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.
So my question is:
Are there any serious drawbacks of using this style of coding?
8
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.
As for actual technical problems with it, a few things come to mind.
- All your code effectively becomes
inline. Your compile times will likely increase. - Every recompile will compile the world simply because it has to.
- 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.
1
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.
If you want to Java-style classes, then program in Java !
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).[…much much more, each line more painful than the last…]
Ok, first off, it is not a feature that “very few programmers seem to know about.” Second, this is a complete misunderstanding of forward declaration and what it is used for. Google’s coding style guide has a halfway decent introduction: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Forward_Declarations
They’re meant to simplify the compiler and they reduce compile time substantially.
1
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.