Is there a good way to avoid duplication of method prototypes in C++?

Question

Most C++ class method signatures are duplicated between the declaration normally in a header files and the definition in the source files in the code I have read. I find this repetition undesirable and code written this way suffers from poor locality of reference. For instance, the methods in source files often reference instance variables declared in the header file; you end up having to constantly switch between header files and source files when reading code.

Would anyone recommend a way to avoid doing so? Or, am I mainly going to confuse experienced C++ programmers by not doing things in the usual way?

See also Question 538255 C++ code in header files where someone is told that everything should go in the header.

Answer 1

Don't break with convention. In the end, you will make a ball of worms that doesn't work very well. Plus, compilers will hate you. C/C++ are setup that way for a reason.

Answer 2

Virtually the entire Boost library is written in header-only style. Personally I write virtually all of my C++ code in headers only, because I use lots of small objects and functions. It annoys some experienced C++ developers, but it significantly reduces the amount of code that I have to write and maintain. It also is not a problem for people with a Java or C# background.

Postscript: My score just is now down to -10! I guess this StackOverflow's way of maintaining the karmic balance of the universe.

So I'm re-thinking my recommendation to you on header-only code. I would suggest it only if you write code like me or the Boost library. That is to say code which uses templates heavily, has lots of small classes with lots of small functions, and very few translation units.

Answer 3

I assume you're talking about member function declarations in a header file and definitions in source files?

If you're used to the Java/Python/etc. model, it may well seem redundant. In fact, if you were so inclined, you could define all functions inline in the class definition (in the header file). But, you'd definitely be breaking with convention and paying the price of additional coupling and compilation time every time you changed anything minor in the implementation.

C++, Ada, and other languages originally designed for large scale systems kept definitions hidden for a reason--there's no good reason that the users of a class should have to be concerned with its implementation, nor any reason they should have to repeatedly pay to compile it. Less of an issue nowadays with faster systems, but still relevant for really large systems. Additionally, TDD, stubbing and other testing strategies are facilitated by the isolation and quicker compilation.

Answer 4

You "can" get around the problem. You define an abstract interface class that only contains the pure virtual functions that an outside application will call. Then in the CPP file you provide the actual class that derives from the interface and contains all the class variables. You implement as normal now. The only thing this requires is a way to instantiate the derived implementation class from the interface class. You could do that by providing a static "Create" function that has its implementation in the CPP file.

ie

InterfaceClass* InterfaceClass::Create()
{
     return new ImplementationClass;
}

This way you effectively hide the implementation from any outside user. You can't, however, create the class on the stack only on the heap ... but it does solve your problem AND provides a better layer of abstraction. In the end though if you aren't prepared to do this you need to stick with what you are doing.

Answer 5

C++ language supports function overloading, which means that the entire function signature is basically a way to identify a specific function. For this reason, as long as you declare and define function separately, there's really no redundancy in having to list the parameters again. More precisely, having to list the parameter types is not redundant. Parameters names, on the other hand, play no role in this process and you are free to omit them in the declaration (i.e in the header file), although I belive this limits readability.