8

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?

Improve this question
8
  • 2
    You probably will have problems with templates. Commented Dec 21, 2012 at 0:26
  • 1
    and name mangling Commented Dec 21, 2012 at 0:26
  • @ThomasEding could you elaborate? I changed struct B in the example to a template and it compiled just fine. Commented Dec 21, 2012 at 0:56
  • 1
    I don't understand the point of the article. It goes agains everything considered good modern code in C++... Commented Dec 21, 2012 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). Commented Dec 21, 2012 at 18:16

4 Answers 4

Reset to default
13

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.

Improve this answer
1
  • 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. Commented Dec 21, 2012 at 20:05
9

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.

Improve this answer
7

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.

Improve this answer
1
  • 1
    You know, I just had to downvote for that link to the Google Style Guide. It is such a gigantic pile of wrong. We should be blacklisting it, not linking to it. Commented Dec 21, 2012 at 23:10
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.