Quote:Original post by Paradigm ShifterThat has nothing to do with headers. Headers allow you to see interface but not implementation. People don't generally break open stdio.h when they are trying to remember how to use fopen.
Look at FILE* in C, no-one knows or cares about the structure or implementation of them. One of the best examples of object orientated thinking in C.
What do you think of the D language?
Yeah, that's my point. Headers allow you to see interface rather than implementation... I find languages like C#/Java where everything in a class is in the source more confusing than the FILE* example. No-one ever looks at stdio.h, that's a good thing (TM).
[EDIT: But they do look at the documentation... which is more important than the header files of course. But FILE* is an excellent example of object oriented stuff in C anyway... terminal i/o... files... sockets... memory mapped files... etc. all through same interface]
[EDIT: But they do look at the documentation... which is more important than the header files of course. But FILE* is an excellent example of object oriented stuff in C anyway... terminal i/o... files... sockets... memory mapped files... etc. all through same interface]
Quote:Original post by Paradigm ShifterI still don't see how that has anything to do with headers. What you're saying only makes sense if people frequently look at stdio.h but not stdio.c (ie the compiler vendor provided backing implementation).
Yeah, that's my point. Headers allow you to see interface rather than implementation... I find languages like C#/Java where everything in a class is in the source more confusing than the FILE* example. No-one ever looks at stdio.h, that's a good thing (TM).
Yep I realise my argument is flawed (I have the drunkenness!). But I'd still rather glance at a header to see the core interface and then look at the docs than wade through mountain of implementation details as in a C#/Java class file say. I like the separation between the two, personally.
Quote:Original post by Paradigm Shifter
Yep I realise my argument is flawed (I have the drunkenness!). But I'd still rather glance at a header to see the core interface and then look at the docs than wade through mountain of implementation details as in a C#/Java class file say. I like the separation between the two, personally.
But why would you start with looking at the header for the core interface? Why isn't that provided directly in the docs?
Even with my own code, I rely on the Code Browswer to tell me how it all works. It could be written across fifteen different files on eight different PCs and it wouldn't matter to me.
Considering the enormous problems the reliance on header files causes with C++, using them as a form of documentation is a pretty poor excuse for keeping them around longer than needed.
CM
In VS2005 at least, you can collapse C# code to definitions so it looks exactly like a c++ header, only without the compilation annoyances and logistical hooplah.
OK I concede the point. Documentation is more important and I have been annoyed in the past by having to maintain comments and such between headers and code files.
But if there's no documentation then the first place I look is in the header file, and go from there.
But if there's no documentation then the first place I look is in the header file, and go from there.
If you're still not convinced, here's a simple thing you can do. Open the std::map header (that's <map>) and read it to figure out its interface. (Yes, I recognize this is a C++ flaw rather than an inherent problem with headers.)
Nah, I just read the MSDN (or a book) on that one. But in-house it's a different matter.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
