Is it a bad or a good idea to include STL within a header file? Wherein you use them as a member variable of your own defined class.
My assumption is, there are people who really wanted their created library to be very independent on C++ standard library. So they are forced to rewrite again a type similar to the functionality available in C++ STL while other's try to forward declare in their header file the type they will be needed later. Which is other's sees this as a bad practice and not a good idea at all.
Please correct me if I'm wrong (I don't know much that's why all is just an assumption):
So what are the effects in terms of code portability (for those who really wanted their code to be platform independent) when forward declaring a type available on STL ?(I only know of a type of vector as suggested by MSDN can be forward declared but not guaranteed to work at all times).
If I include the STL in my header file, what problem could exist? And will this affect the portability of my code?
What if I include STL in the header file of my DLL and bring that DLL in other computers, what problem could I encounter?
And, can you give me an enlightenment why I should (should not) include STL in my header?
So what are the effects in terms of code portability (for those who
really wanted their code to be platform independent) when forward
declaring a type available on STL ?
Using standard C++ and the standard libraries at all times is the hallmark of portability.
If I include the STL in my header file, what problem could exist? And
will this affect the portability of my code?
Longer compile time perhaps? And again, see the above answer.
What if I include STL in the header file of my DLL and bring that DLL
in other computers, what problem could I encounter?
Mostly and AFAIK, DLLs only "store" the method definitions of your classes. You still need to include the STL headers in your .h files.
And, can you give me an enlightenment why I should (should not)
include STL in my header?
You should, because you almost always want to use STL. Come to Lounge<C++> and you'll sure be enlightened.
Use PIMPL idiom to create a compilation firewall on headers that expose / export STL types : Details
class MyList{
public:
//Some functions
private:
std::vector<int> _content;
};
If you create MyList in Vs2012 but the component is built in VS2008, then the code inside VS2008 will expect the memory layout as per STL 2008 but the layout will be that of STL 2012. This will create a whole host of issues.
Your component will not be portable across compilers let alone platforms. A component built in VS2008 using std::vector as a member variable will have a different size to the same compiled in VS2012 for example.
Yes, your code will be compatible across compilers in most scenarios except when you are using features of STL that is more up to date in older versions.
No problem as long as you have the runtime for the dll in the other computer.
You should not have stl types across dll/component boundaries for reusable code.
If you are using Standard C++ STL library then you may not have porting issues as both Microsoft Visual C++ and g++ support these.
Unless you you non standard STL headers then you will have issues.
Avoid STL in headers at all costs:
STL is full of implementation details. Leave that to source code.
Headers are your API, you only want to be exposing functions, structs and interfaces.
You may want to compile and link libraries in different modes - that leads to cross module errors if you are say allocating in debug and deleting memory in release. So do not use std::string to pass information across the API.
One you start to include just one header from STL you will find other modules start to leak in. You will end up with STL poisoning everything, no real interface and build times in minutes when it should be in seconds.
How would STL improve the following API? Consumers of IDog do not need to know the internal structure of a dog, only that it barks.
struct IDog
{
virtual void Bark() = 0;
virtual void Free() = 0;
}
IDog* CreateDog();
In your source code you might have
struct Dog: IDog
{
Dog() {...}
std::vector<VocalChord> vocalChords;
void Bark() override { Resonate(vocalChords); }
void Free() { delete this; }
};
IDog* CreateDog() { return new Dog(); }
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I admit that this question sounds quite general. But after all, exporting classes from DLLs is a general and difficult topic, and frankly, I am currently confused on a quite general level.
The short question: How do object-oriented programming in C++ and DLLs fit together?
The long question: After reading this and this, I was slightly disappointed and confused because I wonder how object-oriented programming can work with DLLs if the DLL borders do not allow objects to be shared (assuming that two DLLs have used different compilers or compiler versions). The only options for exporting classes are these (as explained here or here):
export create and delete methods (C style, danger of dangling pointers, no objects as parameters, ugly)
export a pure virtual class and a factory function which creates an instance of the actual implementation class derived from the pure virtual class (needs inheritance, object deletion needs to be taken care of)
For example, I'd like to put common utility classes in one DLL, which I then use in several classes in other DLLs, which are themselves used in other DLLs. How can I do this? Is this an ill-defined way to organize my classes?
Bonus question: If I export a class having a pointer to implementation, is this equivalent to exporting a pure virtual class and a factory function? Or do the exported member functions have to be virtual?
EDIT: If it matters, I am on Windows 7 using Visual Studio 2010. Migrating vom an older Visual Studio made me sensitive to this problem.
TL;DR : it depends.
The Simple Case
When the two DLLs (or a DLL and an executable) have been built with the same compiler and compiler version, and they use the same flavor of runtime (debug or release), and they link against the dynamic version of the runtime, you can do whatever you want. Delete across DLL boundaries for example.
The Less Simple Case
When one DLL link against a debug runtime and the other link against a release runtime, things get more complicated. This is because the debug runtime have different STL templates, for debugging purposes. For example, you can't manipulate an std::vector allocated from a debug DLL in the release DLL, and vice-versa. As long as you confine these STL templates into the right DLL, things should work. Obviously, you'll run into problems if you expose different ABI's yourself, for example by declaring a member in a #ifndef NDEBUG block.
You may have to force things a little bit with _CRT*defines for this to work, depending on what templates the debug DLL uses.
You should also create and destroy objects from the same DLL.
The Terrible (a.k.a. Real World) Case
When compiler versions don't match, on when at least one DLL is linked with a static runtime.
You'll run into a ton of ABI problems. The only safe thing to do is to rely (extensively) on the C ABI via extern "C". This is also probably what you want to do if you load the DLL at runtime.
A good thing to do at this point:
Write your DLL in C++
Do not expose (dllexport) anything using the C++ ABI.
Write a thin C wrapper around your C++ code.
Expose this C API with __declspec(dllexport)
Write a header-only C++ wrapper around the exposed C API.
Clients will then use your header-only wrapper, so every call to your DLL code will be made using the C ABI, which is extremely stable and unlikely to break.
It's been a long time since I wrote one of the questions you linked, but let me try to help.
The short question: How do object-oriented programming in C++ and DLLs fit together?
That depends entirely on what your objects are exposing. If your objects are returning plain-C values, you should be okay. If your objects are returning POD classes containing plain-C values, you should also be okay. The headaches I was trying unsuccessfully to solve in that question/answer pair were almost entirely STL related.
To answer the natural followup question, the STL plays very badly with DLLs. C++ classes have innate cross-compiler compatibility issues due to different packing, member reordering, etc. The STL adds an extra layer of potential incompatibility because, when built into a debug DLL, extra members can be added.
For example, I'd like to put common utility classes in one DLL, which I then use in several classes in other DLLs, which are themselves used in other DLLs. How can I do this?
After failing to pass STL types successfully, I ultimately wrapped my C++ classes in a layer that translated them to and from their C counterparts. Where possible, I returned basic datatypes. Where I had to allocate memory (string, vector, etc.) I ended up with c-style create/delete functions. I believe I still exposed a pure virtual interface to protect as many implementation details as possible; I just didn't attempt to pass any STL objects directly across the DLL boundary.
If I export a class having a pointer to implementation, is this equivalent to exporting a pure virtual class and a factory function? Or do the exported member functions have to be virtual?
If I understand the question correctly, you want to do both.
struct MyDLL
{
virtual void DoSomething() = 0;
virtual int AddSomething(int argument1, int argument2) = 0;
}
extern "C" __declspec(dllexport) MyDLL* GetMyDLL();
Now your caller can call GetMyDLL and have a pointer to your class, and you can safely implement the virtual functions behind-the-scenes without worrying about your caller seeing what you're doing.
In C++ the standard library is wrapped in the std namespace and the programmer is not supposed to define anything inside that namespace. Of course the standard include files don't step on each other names inside the standard library (so it's never a problem to include a standard header).
Then why isn't the whole standard library included by default instead of forcing programmers to write for example #include <vector> each time? This would also speed up compilation as the compilers could start with a pre-built symbol table for all the standard headers.
Pre-including everything would also solve some portability problems: for example when you include <map> it's defined what symbols are taken into std namespace, but it's not guaranteed that other standard symbols are not loaded into it and for example you could end up (in theory) with std::vector also becoming available.
It happens sometimes that a programmer forgets to include a standard header but the program compiles anyway because of an include dependence of the specific implementation. When moving the program to another environment (or just another version of the same compiler) the same source code could however stop compiling.
From a technical point of view I can image a compiler just preloading (with mmap) an optimal perfect-hash symbol table for the standard library.
This should be faster to do than loading and doing a C++ parse of even a single standard include file and should be able to provide faster lookup for std:: names. This data would also be read-only (thus probably allowing a more compact representation and also shareable between multiple instances of the compiler).
These are however just shoulds as I never implemented this.
The only downside I see is that we C++ programmers would lose compilation coffee breaks and Stack Overflow visits :-)
EDIT
Just to clarify the main advantage I see is for the programmers that today, despite the C++ standard library being a single monolithic namespace, are required to know which sub-part (include file) contains which function/class. To add insult to injury when they make a mistake and forget an include file still the code may compile or not depending on the implementation (thus leading to non-portable programs).
Short answer is because it is not the way the C++ language is supposed to be used
There are good reasons for that:
namespace pollution - even if this could be mitigated because std namespace is supposed to be self coherent and programmer are not forced to use using namespace std;. But including the whole library with using namespace std; will certainly lead to a big mess...
force programmer to declare the modules that he wants to use to avoid inadvertently calling a wrong standard function because standard library is now huge and not all programmers know all modules
history: C++ has still strong inheritance from C where namespace do not exist and where the standard library is supposed to be used as any other library.
To go in your sense, Windows API is an example where you only have one big include (windows.h) that loads many other smaller include files. And in fact, precompiled headers allows that to be fast enough
So IMHO a new language deriving from C++ could decide to automatically declare the whole standard library. A new major release could also do it, but it could break code intensively using using namespace directive and having custom implementations using same names as some standard modules.
But all common languages that I know (C#, Python, Java, Ruby) require the programmer to declare the parts of the standard library that he wants to use, so I suppose that systematically making available every piece of the standard library is still more awkward than really useful for the programmer, at least until someone find how to declare the parts that should not be loaded - that's why I spoke of a new derivative from C++
Most of the C++ standard libraries are template based which means that the code they'll generate will depend ultimately in how you use them. In other words, there is very little that could be compiled before instantiate a template like std::vector<MyType> m_collection;.
Also, C++ is probably the slowest language to compile and there is a lot parsing work that compilers have to do when you #include a header file that also includes other headers.
Well, first thing first, C++ tries to adhere to "you only pay for what you use".
The standard-library is sometimes not part of what you use at all, or even of what you could use if you wanted.
Also, you can replace it if there's a reason to do so: See libstdc++ and libc++.
That means just including it all without question isn't actually such a bright idea.
Anyway, the committee are slowly plugging away at creating a module-system (It takes lots of time, hopefully it will work for C++1z: C++ Modules - why were they removed from C++0x? Will they be back later on?), and when that's done most downsides to including more of the standard-library than strictly neccessary should disappear, and the individual modules should more cleanly exclude symbols they need not contain.
Also, as those modules are pre-parsed, they should give the compilation-speed improvement you want.
You offer two advantages of your scheme:
Compile-time performance. But nothing in the standard prevents an implementation from doing what you suggest[*] with a very slight modification: that the pre-compiled table is only mapped in when the translation unit includes at least one standard header. From the POV of the standard, it's unnecessary to impose potential implementation burden over a QoI issue.
Convenience to programmers: under your scheme we wouldn't have to specify which headers we need. We do this in order to support C++ implementations that have chosen not to implement your idea of making the standard headers monolithic (which currently is all of them), and so from the POV of the C++ standard it's a matter of "supporting existing practice and implementation freedom at a cost to programmers considered acceptable". Which is kind of the slogan of C++, isn't it?
Since no C++ implementation (that I know of) actually does this, my suspicion is that in point of fact it does not grant the performance improvement you think it does. Microsoft provides precompiled headers (via stdafx.h) for exactly this performance reason, and yet it still doesn't give you an option for "all the standard libraries", instead it requires you to say what you want in. It would be dead easy for this or any other implementation to provide an implementation-specific header defined to have the same effect as including all standard headers. This suggests to me that at least in Microsoft's opinion there would be no great overall benefit to providing that.
If implementations were to start providing monolithic standard libraries with a demonstrable compile-time performance improvement, then we'd discuss whether or not it's a good idea for the C++ standard to continue permitting implementations that don't. As things stand, it has to.
[*] Except perhaps for the fact that <cassert> is defined to have different behaviour according to the definition of NDEBUG at the point it's included. But I think implementations could just preprocess the user's code as normal, and then map in one of two different tables according to whether it's defined.
I think the answer comes down to C++'s philosophy of not making you pay for what you don't use. It also gives you more flexibility: you aren't forced to use parts of the standard library if you don't need them. And then there's the fact that some platforms might not support things like throwing exceptions or dynamically allocating memory (like the processors used in the Arduino, for example). And there's one other thing you said that is incorrect. As long as it's not a template class, you are allowed to add swap operators to the std namespace for your own classes.
First of all, I am afraid that having a prelude is a bit late to the game. Or rather, seeing as preludes are not easily extensible, we have to content ourselves with a very thin one (built-in types...).
As an example, let's say that I have a C++03 program:
#include <boost/unordered_map.hpp>
using namespace std;
using boost::unordered_map;
static unordered_map<int, string> const Symbols = ...;
It all works fine, but suddenly when I migrate to C++11:
error: ambiguous symbol "unordered_map", do you mean:
- std::unordered_map
- boost::unordered_map
Congratulations, you have invented the least backward compatible scheme for growing the standard library (just kidding, whoever uses using namespace std; is to blame...).
Alright, let's not pre-include them, but still bundle the perfect hash table anyway. The performance gain would be worth it, right?
Well, I seriously doubt it. First of all because the Standard Library is tiny compared to most other header files that you include (hint: compare it to Boost). Therefore the performance gain would be... smallish.
Oh, not all programs are big; but the small ones compile fast already (by virtue of being small) and the big ones include much more code than the Standard Library headers so you won't get much mileage out of it.
Note: and yes, I did benchmark the file look-up in a project with "only" a hundred -I directives; the conclusion was that pre-computing the "include path" to "file location" map and feeding it to gcc resulted in a 30% speed-up (after using ccache already). Generating it and keeping it up-to-date was complicated, so we never used it...
But could we at least include a provision that the compiler could do it in the Standard?
As far as I know, it is already included. I cannot remember if there is a specific blurb about it, but the Standard Library is really part of the "implementation" so resolving #include <vector> to an internal hash-map would fall under the as-if rule anyway.
But they could do it, still!
And lose any flexibility. For example Clang can use either the libstdc++ or the libc++ on Linux, and I believe it to be compatible with the Dirkumware's derivative that ships with VC++ (or if not completely, at least greatly).
This is another point of customization: if the Standard library does not fit your needs, or your platforms, by virtue of being mostly treated like any other library you can replace part of most of it with relative ease.
But! But!
#include <stdafx.h>
If you work on Windows, you will recognize it. This is called a pre-compiled header. It must be included first (or all benefits are lost) and in exchange instead of parsing files you are pulling in an efficient binary representation of those parsed files (ie, a serialized AST version, possibly with some type resolution already performed) which saves off maybe 30% to 50% of the work. Yep, this is close to your proposal; this is Computer Science for you, there's always someone else who thought about it first...
Clang and gcc have a similar mechanism; though from what I've heard it can be so painful to use that people prefer the more transparent ccache in practice.
And all of these will come to naught with modules.
This is the true solution to this pre-processing/parsing/type-resolving madness. Because modules are truly isolated (ie, unlike headers, not subject to inclusion order), an efficient binary representation (like pre-compiled headers) can be pre-computed for each and every module you depend on.
This not only means the Standard Library, but all libraries.
Your solution, more flexible, and dressed to the nines!
One could use an alternative implementation of the C++ Standard Library to the one shipped with the compiler. Or wrap headers with one's definitions, to add, enable or disable features (see GNU wrapper headers). Plain text headers and the C inclusion model are a more powerful and flexible mechanism than a binary black box.
I'm new to using DLL's in C++ and I am wondering how to sucessfully load and use classes contained in a DLL without getting a "corrupted stack", a "null pointer" or any application crash ^^. This is a bit confusing to me for now.
Even if it might be safer I don't want to use interface class because it seems too complicated to use. I know that I should have the same include in both DLL and application to prevent crashes. That means that my include file should mention members name.
Here is the problem :
I want to distribute my software (DLL + include file) and I don't want
my customers to see the architecture of my project. But the only class
I want to export from my DLL has as member, objects from other
classes. So my class is dependent of other classes and so on in
cascade.
Is it possible to provide only one include file of one class with just useful methods without having risks of crashes ? If no, what solutions might fit my needs ?
Thanks
FIrst of all, if you use the same include in DLL and in the application using it, if both were compiled with the same compiler and compatible settings, and both use the same runtime library (DLL one, not statically linked), you should have none of the problem you fear.
If you want to hide details of your DLL and provide an alterered, simplified header to the DLL users, you work on your own risk. For example, if there are data members missing (even private ones) of if there are virtual functions missing (even private ones), then it might probably crash, or worse, corrupt something without being noticed. So I'd strongly advise you not to consider this approach unless you're very very experienced with the assembler generated by your compiler.
If you want to hide implementation details of your class, the best approach would probably to design your library around the PIMPL idiom.
We are using a third-party library in our Visual Studio 2013 C++ project. This library I guess uses a different STL library than ours. We are getting some link errors. There are no compile-time errors. As I understand, STL is primarily template-based code thus requiring no linking. Looks like there are some parts of STL that do require linking with an STL library. Wondering if there is a way to force STL to be completely inline. Regards.
There is no single answer to this question. In general, C++ is well known to not be "link-compatible" (or "binary compatible") between different versions of compilers (or different brands of compilers, etc, etc). So someone supplying a library SHOULD specify exactly which compiler they expect to be used, and the user of the library will need to use that one. [I've even seen problems using exactly the same version, but two different "builds" of the compiler]
To POSSIBLY find a solution, you'd have to look at what it is the compiler/linker is attempting to find, and then see if that function is at all present in the sources for the STL - if it is, then possibly applying a liberal sprinkling (on the relevant functins) of "always_inline" or whatever that particular compiler uses for that functionality. But chances are that the functions you're missing aren't provided in the header files in the first place. This of course assumes that you actually have the source for the library, so that it can be recompiled [or you can convince the provider to recompile with new settings].
And you'll potentially still have problems with things that are implementation dependent (the problem with "same version, different build" I mentioned above is that someone who wrote STL implementation decided to change a constructor parameter from "unsigned int" to "size_t" at some point, which [could change or] changes the size of the data passed to the constructor -> not behaving the same when you call the function [but the shared library loader detects it and refuses to even load the executable/shared library combination]
[As Lightness Races in Orbit says, the above applies to the "Standard Template Library", which is things like std::vector, std::map, std::random and many other things, but it does not include ALL of the runtime functionality that is required to write any non-trivial C++ program]
STL is primarily template-based code
The "STL" as the term is commonly used (which in itself is inaccurate) relates only to a very small subset of the C++ standard library, and plenty of the C++ standard library is not templates. And that still doesn't take into consideration any of the C++ runtime that your implementation has to link into your project.
So, assuming you mean either the C++ standard library or (more likely) the whole Visual Studio runtime … no, you can't inline it all.
You should probably rebuild the third-party library against your own toolchain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Many languages, such as Java, C#, do not separate declaration from implementation. C# has a concept of partial class, but implementation and declaration still remain in the same file.
Why doesn't C++ have the same model? Is it more practical to have header files?
I am referring to current and upcoming versions of C++ standard.
Backwards Compatibility - Header files are not eliminated because it would break Backwards Compatibility.
Header files allow for independent compilation. You don't need to access or even have the implementation files to compile a file. This can make for easier distributed builds.
This also allows SDKs to be done a little easier. You can provide just the headers and some libraries. There are, of course, ways around this which other languages use.
Even Bjarne Stroustrup has called header files a kludge.
But without a standard binary format which includes the necessary metadata (like Java class files, or .Net PE files) I don't see any way to implement the feature. A stripped ELF or a.out binary doesn't have much of the information you would need to extract. And I don't think that the information is ever stored in Windows XCOFF files.
I routinely flip between C# and C++, and the lack of header files in C# is one of my biggest pet peeves. I can look at a header file and learn all I need to know about a class - what it's member functions are called, their calling syntax, etc - without having to wade through pages of the code that implements the class.
And yes, I know about partial classes and #regions, but it's not the same. Partial classes actually make the problem worse, because a class definition is spread across several files. As far as #regions go, they never seem to be expanded in the manner I'd like for what I'm doing at the moment, so I have to spend time expanding those little plus's until I get the view right.
Perhaps if Visual Studio's intellisense worked better for C++, I wouldn't have a compelling reason to have to refer to .h files so often, but even in VS2008, C++'s intellisense can't touch C#'s
C was made to make writing a compiler easily. It does a LOT of stuff based on that one principle. Pointers only exist to make writing a compiler easier, as do header files. Many of the things carried over to C++ are based on compatibility with these features implemented to make compiler writing easier.
It's a good idea actually. When C was created, C and Unix were kind of a pair. C ported Unix, Unix ran C. In this way, C and Unix could quickly spread from platform to platform whereas an OS based on assembly had to be completely re-written to be ported.
The concept of specifying an interface in one file and the implementation in another isn't a bad idea at all, but that's not what C header files are. They are simply a way to limit the number of passes a compiler has to make through your source code and allow some limited abstraction of the contract between files so they can communicate.
These items, pointers, header files, etc... don't really offer any advantage over another system. By putting more effort into the compiler, you can compile a reference object as easily as a pointer to the exact same object code. This is what C++ does now.
C is a great, simple language. It had a very limited feature set, and you could write a compiler without much effort. Porting it is generally trivial! I'm not trying to say it's a bad language or anything, it's just that C's primary goals when it was created may leave remnants in the language that are more or less unnecessary now, but are going to be kept around for compatibility.
It seems like some people don't really believe that C was written to port Unix, so here: (from)
The first version of UNIX was written
in assembler language, but Thompson's
intention was that it would be written
in a high-level language.
Thompson first tried in 1971 to use
Fortran on the PDP-7, but gave up
after the first day. Then he wrote a
very simple language he called B,
which he got going on the PDP-7. It
worked, but there were problems.
First, because the implementation was
interpreted, it was always going to be
slow. Second, the basic notions of B,
which was based on the word-oriented
BCPL, just were not right for a
byte-oriented machine like the new
PDP-11.
Ritchie used the PDP-11 to add types
to B, which for a while was called NB
for "New B," and then he started to
write a compiler for it. "So that the
first phase of C was really these two
phases in short succession of, first,
some language changes from B, really,
adding the type structure without too
much change in the syntax; and doing
the compiler," Ritchie said.
"The second phase was slower," he said
of rewriting UNIX in C. Thompson
started in the summer of 1972 but had
two problems: figuring out how to run
the basic co-routines, that is, how to
switch control from one process to
another; and the difficulty in getting
the proper data structure, since the
original version of C did not have
structures.
"The combination of the things caused
Ken to give up over the summer,"
Ritchie said. "Over the year, I added
structures and probably made the
compiler code somewhat better --
better code -- and so over the next
summer, that was when we made the
concerted effort and actually did redo
the whole operating system in C."
Here is a perfect example of what I mean. From the comments:
Pointers only exist to make writing a compiler easier? No. Pointers exist because they're the simplest possible abstraction over the idea of indirection. – Adam Rosenfield (an hour ago)
You are right. In order to implement indirection, pointers are the simplest possible abstraction to implement. In no way are they the simplest possible to comprehend or use. Arrays are much easier.
The problem? To implement arrays as efficiently as pointers you have to pretty much add a HUGE pile of code to your compiler.
There is no reason they couldn't have designed C without pointers, but with code like this:
int i=0;
while(src[++i])
dest[i]=src[i];
it will take a lot of effort (on the compilers part) to factor out the explicit i+src and i+dest additions and make it create the same code that this would make:
while(*(dest++) = *(src++))
;
Factoring out that variable "i" after the fact is HARD. New compilers can do it, but back then it just wasn't possible, and the OS running on that crappy hardware needed little optimizations like that.
Now few systems need that kind of optimization (I work on one of the slowest platforms around--cable set-top boxes, and most of our stuff is in Java) and in the rare case where you might need it, the new C compilers should be smart enough to make that kind of conversion on its own.
In The Design and Evolution of C++, Stroustrup gives out one more reason...
The same header file can have two or more implementation files which can be simultaneously worked-upon by more than one programmer without the need of a source-control system.
This might seem odd these days, but I guess it was an important issue when C++ was invented.
If you want C++ without header files then I have good news for you.
It already exists and is called D (http://www.digitalmars.com/d/index.html)
Technically D seems to be a lot nicer than C++ but it is just not mainstream enough for use in many applications at the moment.
One of C++'s goals is to be a superset of C, and it's difficult for it to do so if it cannot support header files. And, by extension, if you wish to excise header files you may as well consider excising CPP (the pre-processor, not plus-plus) altogether; both C# and Java do not specify macro pre-processors with their standards (but it should be noted in some cases they can be and even are used even with these languages).
As C++ is designed right now, you need prototypes -- just as in C -- to statically check any compiled code that references external functions and classes. Without header files, you would have to type out these class definitions and function declarations prior to using them. For C++ not to use header files, you'd have to add a feature in the language that would support something like Java's import keyword. That'd be a major addition, and change; to answer your question of if it'd be practical: I don't think so--not at all.
Many people are aware of shortcomings of header files and there are ideas to introduce more powerful module system to C++.
You might want to take a look at Modules in C++ (Revision 5) by Daveed Vandevoorde.
Well, C++ per se shouldn't eliminate header files because of backwards compatibility. However, I do think they're a silly idea in general. If you want to distribute a closed-source lib, this information can be extracted automatically. If you want to understand how to use a class w/o looking at the implementation, that's what documentation generators are for, and they do a heck of a lot better a job.
There is value in defining the class interface in a separate component to the implementation file.
It can be done with interfaces, but if you go down that road, then you are implicitly saying that classes are deficient in terms of separating implementation from contract.
Modula 2 had the right idea, definition modules and implementation modules. http://www.modula2.org/reference/modules.php
Java/C#'s answer is an implicit implementation of the same (albeit object-oriented.)
Header files are a kludge, because header files express implementation detail (such as private variables.)
In moving over to Java and C#, I find that if a language requires IDE support for development (such that public class interfaces are navigable in class browsers), then this is maybe a statement that the code doesn't stand on its own merits as being particularly readable.
I find the mix of interface with implementation detail quite horrendous.
Crucially, the lack of ability to document the public class signature in a concise well-commented file independent of implementation indicates to me that the language design is written for convenience of authorship, rather convenience of maintenance. Well I'm rambling about Java and C# now.
One advantage of this separation is that it is easy to view only the interface, without requiring an advanced editor.
No language exists without header files. It's a myth.
Look at any proprietary library distribution for Java (I have no C# experience to speak of, but I'd expect it's the same). They don't give you the complete source file; they just give you a file with every method's implementation blanked ({} or {return null;} or the like) and everything they can get away with hiding hidden. You can't call that anything but a header.
There is no technical reason, however, why a C or C++ compiler could count everything in an appropriately-marked file as extern unless that file is being compiled directly. However, the costs for compilation would be immense because neither C nor C++ is fast to parse, and that's a very important consideration. Any more complex method of melding headers and source would quickly encounter technical issues like the need for the compiler to know an object's layout.
If you want the reason why this will never happen: it would break pretty much all existing C++ software. If you look at some of the C++ committee design documentation, they looked at various alternatives to see how much code it would break.
It would be far easier to change the switch statement into something halfway intelligent. That would break only a little code. It's still not going to happen.
EDITED FOR NEW IDEA:
The difference between C++ and Java that makes C++ header files necessary is that C++ objects are not necessarily pointers. In Java, all class instances are referred to by pointer, although it doesn't look that way. C++ has objects allocated on the heap and the stack. This means C++ needs a way of knowing how big an object will be, and where the data members are in memory.
Header files are an integral part of the language. Without header files, all static libraries, dynamic libraries, pretty much any pre-compiled library becomes useless. Header files also make it easier to document everything, and make it possible to look over a library/file's API without going over every single bit of code.
They also make it easier to organize your program. Yes, you have to be constantly switching from source to header, but they also allow you define internal and private APIs inside the implementations. For example:
MySource.h:
extern int my_library_entry_point(int api_to_use, ...);
MySource.c:
int private_function_that_CANNOT_be_public();
int my_library_entry_point(int api_to_use, ...){
// [...] Do stuff
}
int private_function_that_CANNOT_be_public() {
}
If you #include <MySource.h>, then you get my_library_entry_point.
If you #include <MySource.c>, then you also get private_function_that_CANNOT_be_public.
You see how that could be a very bad thing if you had a function to get a list of passwords, or a function which implemented your encryption algorithm, or a function that would expose the internals of an OS, or a function that overrode privileges, etc.
Oh Yes!
After coding in Java and C# it's really annoying to have 2 files for every classes. So I was thinking how can I merge them without breaking existing code.
In fact, it's really easy. Just put the definition (implementation) inside an #ifdef section and add a define on the compiler command line to compile that file. That's it.
Here is an example:
/* File ClassA.cpp */
#ifndef _ClassA_
#define _ClassA_
#include "ClassB.cpp"
#include "InterfaceC.cpp"
class ClassA : public InterfaceC
{
public:
ClassA(void);
virtual ~ClassA(void);
virtual void methodC();
private:
ClassB b;
};
#endif
#ifdef compiling_ClassA
ClassA::ClassA(void)
{
}
ClassA::~ClassA(void)
{
}
void ClassA::methodC()
{
}
#endif
On the command line, compile that file with
-D compiling_ClassA
The other files that need to include ClassA can just do
#include "ClassA.cpp"
Of course the addition of the define on the command line can easily be added with a macro expansion (Visual Studio compiler) or with an automatic variables (gnu make) and using the same nomenclature for the define name.
Still I don't get the point of some statements. Separation of API and implementation is a very good thing, but header files are not API. There are private fields there. If you add or remove private field you change implementation and not API.