New libraries should provide forward declarations?
Hi Boost community, Would it practical to add a rule of thumb to the developer guidelines that library developers should offer a fwd declaration header for their library when possible? For me the rationale is as follows: - Boost headers are relatively heavy includes - Pre-compiled headers are only available on a subset of compilers. - Client side forward declarations are often problematic. E.g. - - Boost.Tuple: redeclarations of default template arguments are illegal (although MSVC lets you do it if you are prepared to suffer a warning) so including boost/tuple.hpp after mylibraryutils/boost_tuple_fwd.hpp is illegal. - - Boost.Function : The removal of the allocator template parameter has broken our code when we experimentally checked the 1.36 beta, as our forward declarations of Boost.Functions are now wrong. The existence of boost/tuple/tuple_fwd.hpp and boost/function/function_fwd.hpp would thus have significantly improved the user experience in my case. Thanks for listening, Pete Bartlett
I second this question. In fact, i am wondering whether it would not be even more effective to suggest the separation of each (public) template class into 3 different header files : one containing a forward declaration header, one containing the template class definition and the last one with the definition of its member functions. That would make it possible to easily separate the compilation of boost classes (or at least their methods) from that of user-defined classes. Not sure if this has ever been proposed, but i would certainly like that. Thanks ! Benoît Casoetto
Would it practical to add a rule of thumb to the developer guidelines
library developers should offer a fwd declaration header for their
OP wrote: that library
when possible?
Benoit wrote:
I have found in my template programming that it is highly beneficial to separate the template class declaration from the definition of its member functions. This leads to a much more readable set of header files similar to what people are used to reading when definitions are contained within a cpp file. I find the boost code somewhat hard to read because the header files contain all the implementation details that could have been put in a separate definitions hpp. At the very least definitions can be moved to the bottom of the same header file. This does have the drawback, however, that the compiler will complain about cyclic dependencies that it would not otherwise.
No, unfortunately, it wouldn't, because you have to pull in the definitions to use the template class, what you want is precompiled headers. It would, however, allow a header file that makes declarations that include boost references to not have to pull in all the related boost implementation details and slow down the compile time of every compilation unit that depends on it. I consider this benefit secondary to the readability benefit. I third the question, should we make separating template declarations from their definitions a preferred practice? Luke
On 20/08/2008, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
I third the question, should we make separating template declarations from their definitions a preferred practice?
Some libraries don't do this because they still support older compilers where template functions have to be defined inline. Daniel
On 20/08/2008, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
Daniel wrote:
Some libraries don't do this because they still support older compilers where template functions have to be defined inline.
Is this rational still valid for new libraries? I would imagine that there are a number of recent libraries accepted that don't support the older compilers for other reasons. I was proposing we make it a preferred practice for ongoing and future development. I would not suggest we revise mature libraries to conform to this style. Do you think that is reasonable? Luke
On 20/08/2008, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
It's reasonable but I'm currently working on a new library that will support older compilers so I won't be following it. I think this kind of thing is up to the developer. But feel free to suggest a patch for the guidelines. They live at: http://svn.boost.org/svn/boost/website/public_html/beta/development/header.h... I'll apply it if it seems decent and no one objects. Daniel
On Aug 20, 2008, at 3:47 PM, Daniel James wrote:
Is this just about separating the member definitions from their home class template, or is it also about which header those member definitions should go into? [An suggestion was moving the m.d. to a new header.] I think that the m.d. should stay in the same header file as class-template definition (but afterwards), so we don't have a lot of files lying around. Exceptions would be if the number of member functions (templates) was huge, or if a small fraction of the m.d. require a lot of outside headers that the other m.d. don't need. I want to go the other way briefly. This thread also talked about forwarding headers. I think those should be grouped together, by family like <iosfwd> does, to reduce proliferation and the fact that classes in a family need each others' declarations anyway. I think the headers should be like <iosfwd>, and generally only have declarations for classes, class templates, and typedefs of such, and not include functions and function templates. Leave the function- related forward declarations to the core header of the related types. (I think that C++0x adds forward declarations for enums, those can go in our headers too.) A difficulty for now is sometimes we want to use a template parameter default that doesn't have a forwarding header, which means that either the default is skipped or a heavier header is #included. The prime example is anything from the standard library that isn't needed in <iosfwd>, especially the containers. For Boost, we could retroactively add forwarding headers. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
on Wed Aug 20 2008, "Simonson, Lucanus J" <lucanus.j.simonson-AT-intel.com> wrote:
Frankly I find that style adds so much syntactic overhead that it seldom benefits readability. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
the
I agree with you that while implementing a template library keeping the definitions in the declaration area is much more convenient and helpful than separating them. It avoids cyclic dependency problems in definitions, it reduces the number of files and it makes writing the code all around easier. Defining a template function of a template class separate from its declaration does require a lot of extra syntactic overhead in the definition, but it certainly doesn't hurt the readability of the declaration, and that is the readability I'm concerned with. Luke _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This is not exactly true. I already use such an approach in my own developments. The idea is to use concepts to make sure that the right member functions are called inside a cpp file and therefore will be compiled and usable everywhere.That would mean pulling in all related implementation details... But only for one compilation unit (created with that purpose in mind). Other compilation units would only have access to template class definitions. For that matter, i personally use the .h extension for template class definitions and .hpp for template class method definitions (but that's only an example of what could be done). Note that i agree that it would also bring a readability benefit to the source code. Benoît
participants (6)
-
Benoit -
Daniel James -
Daryle Walker -
David Abrahams -
Peter Bartlett -
Simonson, Lucanus J