views:

1617

answers:

18

When i first learned c++, I had already coded in many other languages prior to it, which made the prospect of headers really depressing. So far, my solution to coding without header files in c++ has been far from optimal, limiting what I can do in the language.

Is there any way to not have to write function declarations twice (headers) and still retain the same scalability in compiling, clarity in debugging and flexibility in design?

so: Is it possible to code C++ without headers? If yes, how?

+6  A: 

There is no practical way to get around headers. The only thing you could do is to put all code into one big c++ file. That will end up in an umaintainable mess, so please don't do it.

At the moment C++ header-files are a nessesary evil. I don't like them, but there is no way around them. I'd love to see some improvements and fresh ideas on the problem though.

Btw - once you've got used to it it's not that bad anymore.. C++ (and any other language as well) has more anoying things.

Nils Pipenbrinck
-1 as there seems to be more constructive answers below.. sry.
0scar
+5  A: 

You have to write function declaration twice, actually (once in header file, once in implementation file). The definition (AKA implementation) of the function will be written once, in the implementation file.

You can write all the code in header files (it is actually a very used practice in generic programming in C++), but this implies that every C/CPP file including that header will imply recompilation of the implementation from those header files.

If you are thinking to a system similar to C# or Java, it is not possible in C++.

Cătălin Pitiș
"this implies that every C/CPP file including that header will imply recompilation of the implementation from those header files." Which is a lesser problem if actually all of your code is in headers, since you'll presumably only have one cpp file to compile. So you'll have one huge compilation, but at least it will only be one. The typical C++ project in header hell has many cpp files, each of which compiles most or all of the header code, for more work in total.
Steve Jessop
Ok. In priciple you're right. But, if you have hundreds or thousands of translation units, then trying to make them one translation unit (through file inclusion) will be a nightmare. I would never try it this way.
Cătălin Pitiș
thanks, corrected the mixup with declaration/definition.
thewreck
@onebyone: but if you write all your code in ehaders and include from a single cpp, then you have only a single translation unit and changing any of the ehaders requires the whole thing to be recompiled while if you properly split the code amongst headers and cpp files, then only the translation units that actually change need to be recompiled.
Dan
@Dan: Good point. I wonder why I forgot about it. It is the most obvious reason :-)
Cătălin Pitiș
Absolutely true: scalability is still a problem, and the questioner needs to suck it up and do things "properly", if only in order to learn to play nicely with others. I'm just pointing out that the problem doesn't *necessarily* bite sooner for one-big-translation-unit than for multiple-TUs. It comes down to how disciplined you are at minimising the headers used by each cpp file. You don't get proper division of dependencies unless you plan for it, and most people (me and most likely the questioner included) get it wrong on the first attempt...
Steve Jessop
I should say that when I said "lesser", I meant compared with other options where every header contains implementation, hence has to include other headers, and everything ends up depending on everything else. I don't mean it's a lesser problem compared with doing it well using the normal means :-)
Steve Jessop
+1  A: 

As far as I know, no. Headers are an inherent part of C++ as a language. Don't forget that forward declaration allows the compiler to merely include a function pointer to a compiled object/function without having to include the whole function (which you can get around by declaring a function inline (if the compiler feels like it).

If you really, really, really hate making headers, write a perl-script to autogenerate them, instead. I'm not sure I'd recommend it though.

mikek
+1  A: 

Actually... You can write the entire implementation in a file. Templated classes are all defined in the header file with no cpp file.

You can also save then with whatever extensions you want. Then in #include statements, you would include your file.

/* mycode.cpp */
#pragma once
#include <iostreams.h>

class myclass {
public:
  myclass();

  dothing();
};

myclass::myclass() { }
myclass::dothing()
{
  // code
}

Then in another file

/* myothercode.cpp */
#pragma once
#include "mycode.cpp"

int main() {
   myclass A;
   A.dothing();
   return 0;
}

You may need to setup some build rules, but it should work.

Kieveli
I gotta add... The biggest rule for coding is to make it easy for others to read. So C++ people wouldn't know what the hell is going on. This isn't recommended, but it's possible ;)
Kieveli
Also, the OP asked about scalability of compiling, which this would definitely impact.
Lou Franco
Truche.........
Kieveli
#including a .cpp file will definitely get the maintenance programmers on your case (In a bad way).
C Johnson
A: 

You can carefully lay out your functions so that all of the dependent functions are compiled after their dependencies, but as Nils implied, that is not practical.

Catalin (forgive the missing diacritical marks) also suggested a more practical alternative of defining your methods in the header files. This can actually work in most cases.. especially if you have guards in your header files to make sure they are only included once.

I personally think that header files + declaring functions is much more desirable for 'getting your head around' new code, but that is a personal preference I suppose...

John Weldon
+4  A: 

What I have seen some people like you do is write everything in the headers. That gives your desired property of only having to write the method profiles once.

Personally I think there are very good reasons why it is better to separate declaration and definition, but if this distresses you there is a way to do what you want.

T.E.D.
+17  A: 

Sorry, but there's no such thing as a "best practice" for eliminating headers in C++: it's a bad idea, period. If you hate them that much, you have three choices:

  • Resign yourself to hellish problems down the road because you don't use headers
  • Pick a language you can use "right" without getting depressed
  • Get a tool to generate them for you; you'll still have headers, but you save some typing effort

Edit: Feel free to comment with your downvotes; I'm assuming it's just an unwelcome opinion. If there's something that's objectively wrong with my opinion, I'd definitely like to know.

ojrac
-1 The lzz-tool mentioned in an answer here solves the problems implied by the "asker" without the negative effects you described (as the lzz-tool does use headers. You just don't have to actually write them). That makes this answer unconstructive. sry.
0scar
Fair point. I'll acknowledge the 3rd option -- thanks for explaining the flaw.
ojrac
+4  A: 

In his article Simple Support for Design by Contract in C++, Pedro Guerreiro stated:

Usually, a C++ class comes in two files: the header file and the definition file. Where should we write the assertions: in the header file, because assertions are specification? Or in the definition file, since they are executable? Or in both, running the risk of inconsistency (and duplicating work)? We recommend, instead, that we forsake the traditional style, and do away with the definition file, using only the header file, as if all functions were defined inline, very much like Java and Eiffel do.

This is such a drastic change from the C++ normality that it risks killing the endeavor at the outset. On the other hand, maintaining two files for each class is so awkward, that sooner or later a C++ development environment will come up that hides that from us, allowing us to concentrate on our classes, without having to worry about where they are stored.

That was 2001. I agreed. It is 2009 now and still no "development environment will come up that hides that from us, allowing us to concentrate on our classes" has come up. Instead, long compile times are the norm.

Fortunately we now have C#, where we can enjoy no header files... and long compile times :)

Daniel Daranas
+21  A: 

I felt the same way when I started writing C, so I also looked into this. The answer is that yes, it's possible and no, you don't want to.

First with the yes.

In GCC, you can do this:

// foo.cph

void foo();

#if __INCLUDE_LEVEL__ == 0
void foo() {
   printf("Hello World!\n");
}
#endif

This has the intended effect: you combine both header and source into one file that can both be included and linked.

Then with the no:

This only works if the compiler has access to the entire source. You can't use this trick when writing a library that you want to distribute but keep closed-source. Either you distribute the full .cph file, or you have to write a separate .h file to go with your .lib. Although maybe you could auto-generate it with the macro preprocessor. It would get hairy though.

And reason #2 why you don't want this, and that's probably the best one: compilation speed. Normally, C sources files only have to be recompiled when the file itself changes, or any of the files it includes changes.

  • The C file can change frequently, but the change only involves recompiling the one file that changed.
  • Header files define interfaces, so they shouldn't change as often. When they do however, they trigger a recompile of every source file that includes them.

When all your files are combined header and source files, every change will trigger a recompile of all source files. C++ isn't known for its fast compile times even now, imagine what would happen when the entire project had to be recompiled every time. Then extrapolate that to a project of hundreds of source files with complicated dependencies...

rix0rrr
+1: Agrees completely with my answer, but replaces harsh statements with helpful explanations. ;)
ojrac
+1  A: 

You can do without headers. But, why spend effort trying to avoid carefully worked out best practices that have been developed over many years by experts.

When I wrote basic, I quite liked line numbers. But, I wouldn't think of trying to jam them into C++, because that's not the C++ way. The same goes for headers... and I'm sure other answers explain all the reasoning.

Scott Langham
A: 

For practical purposes no, it's not possible. Technically, yes, you can. But, frankly, it's an abuse of the language, and you should adapt to the language. Or move to something like C#.

Paul Nathan
+3  A: 

There's header file generation software. I've never used it, but it might be worth looking into. For instance, check out mkhdr! It supposedly scans C and C++ files and generates the appropriate header files.

(However, as Richard points out, this seems to limit you from using certain C++ functionality. See Richard's answer instead here right in this thread.)

0scar
Have they addressed templates yet? At least not according to the documentation: "Note that makeheaders does not understand some of the more obscure C++ syntax such as templates. Perhaps these issued will be addressed in future revisions.". It seems to be more of a "C with classes" type utility.
Richard Corden
Good point. Edited!
0scar
+20  A: 

Use lzz. It takes a single file and automatically creates a .h and .cpp for you with all the declarations/definitions the the right place.

lzz is really very powerful, and has handles 99% of full C++ syntax, including temples, specializations etc etc etc.

Richard Corden
+1 This seems very interesting. Makes me consider fooling around with C++ this weekend :)
0scar
+1: Actually, lzz is designed the *good* way around : as a source language that produces C++.
Steve Schnepp
+1  A: 

You can avoid headers. Completely. But I don't recommend it.

You'll be faced with some very specific limitations. One of them is you won't be able to have circular references (you won't be able to have class Parent contain a pointer to an instance of class ChildNode, and class ChildNode also contain a pointer to an instance of class Parent. It'd have to be one or the other.)

There are other limitations which just end up making your code really weird. Stick to headers. You'll learn to actually like them (since they provide a nice quick synopsis of what a class can do).

bobobobo
A: 

It is best practice to use the header files, and after a while it will grow into you. I agree that having only one file is easier, but It also can leed to bad codeing.

some of these things, althoug feel awkward, allow you to get more then meets the eye.

as an example think about pointers, passing parameters by value/by reference... etc.

for me the header files allow-me to keep my projects properly structured

+1  A: 

To offer a variant on the popular answer of rix0rrr:

// foo.cph

#define INCLUDEMODE
#include "foo.cph"
#include "other.cph"
#undef INCLUDEMODE

void foo()
#if !defined(INCLUDEMODE)
{
   printf("Hello World!\n");
}
#else
;
#endif

void bar()
#if !defined(INCLUDEMODE)
{
    foo();
}
#else
;
#endif

I do not recommend this, bit I think this construction demonstrates the removal of content repetition at the cost of rote repetition. I guess it makes copy-pasta easier? That's not really a virtue.

As with all the other tricks of this nature, a modification to the body of a function will still require recompilation of all files including the file containing that function. Very careful automated tools can partially avoid this, but they would still have to parse the source file to check, and be carefully constructed to not rewrite their output if it's no different.

For other readers: I spent a few minutes trying to figure out include guards in this format, but didn't come up with anything good. Comments?

Novelocrat
A: 

Learn to recognize that header files are a good thing. They separate how codes appears to another user from the implementation of how it actually performs its operations.

When I use someone's code I do now want to have to wade through all of the implementation to see what the methods are on a class. I care about what the code does, not how it does it.

Richard
A: 

I understand your problems. I would say that the C++ main problem is the compilation/build method that it inherited from the C. The C/C++ header structure has been designed in times when coding involved less definitions and more implementations. Don't throw bottles on me, but that's how it looks like.

Since then the OOP has conquered the world and the world is more about definitions then implementations. As the result, including headers makes pretty painful to work with a language where the fundamental collections such as the ones in the STL made with templates which are notoriously difficult job for the compiler to deal with. All those magic with the precompiled headers doesn't help so much when it comes to TDD, refactoring tools, the general development environment.

Of course C programmers are not suffering from this too much since they don't have compiler-heavy header files and so they are happy with the pretty straightforward, low-level compilation tool chain. With C++ this is a history of suffering: endless forward declarations, precompiled headers, external parsers, custom preprocessors etc.

Many people, however, does not realize that the C++ is the ONLY language that has strong and modern solutions for high- and low-level problems. It's easy to say that you should go for an other language with proper reflection and build system, but it is non-sense that we have to sacrifice the low-level programming solutions with that and we need to complicate things with low-level language mixed with some virtual-machine/JIT based solution.

I have this idea for some time now, that it would be the most cool thing on earth to have a "unit" based c++ tool-chain, similar to that in D. The problem comes up with the cross-platform part: the object files are able to store any information, no problem with that, but since on windows the object file's structure is different that of the ELF, it would be pain in the ass to implement a cross-platform solution to store and process the half-way-compilation units.