Re: [cpp-netlib-devel] Why header only? (was Re: Dependence on std::string)

[Matt G. <mgr...@in...>]

Dean Michael Berris wrote:

>On 7/17/07, Matt Gruenke <email address removed by me> wrote:
>  
>
>>why would it be a requirement
>>for something as big as a network protocol library to be header-only?
>>    
>>

>Okay, let me try to answer why it should be header only:
>
>* Only pay for what you use -- with how templates work in C++, only
>the things that are actually used will be made part of the binary
>output. That means, even if you have a class that has an inordinate
>number of member methods, only those methods you actually use will be
>compiled to the final output binary. That's space efficiency without
>having to rely on the compiler's non-standard optimizations (like dead
>code removal, etc. if you didn't use templates).
>  
>

All linkers I'm aware of pull in only those symbols that are needed.


>* Cross-platform functionality without the baggage -- with the target
>of being usable on all platforms on which the Boost C++ library can be
>used in, the idea now is to not require applications that need to use
>the network library to link externally to a shared library. This
>allows the users to actually get the functionality they need into the
>application -- and since we're not implementing system-level
>implementations of the network protocols, making your applications
>require a shared library would be just "not courteous". Again, the
>point here is that we can allow people to leverage on client/server(?)
>source-level implementations without having them link to an external
>library.
>  
>

I thought the Boost version of ASIO was no longer header-only.  If 
that's true, then you still have a link dependency.  Even if it weren't, 
wouldn't you still have link dependencies on system libraries, on some 
platforms?  Having a non-header-only library allows you to abstract upon 
which underlying libraries yours depends, which could actually simplify 
life for users.


>* Version Freeze and Backward Compatibility -- as an offshoot of the
>above, when we put out changes we just need to worry about people who
>will be using the new version of the library in their projects "to
>build" and not have to worry about applications that link to the
>library externally and breaking API's in that manner. I envision the
>library to be useful for enabling applications to invoke remote
>network resources using a simple set of functions and objects in a
>very efficient manner -- adding an external library to be required to
>run the application is _not_ included in the "simple set of functions
>and objects in a very efficient manner".
>  
>

Shared libraries provide the opportunity to fix application bugs that 
reside in dependent libraries, by using a patched version of said 
libraries.  If you don't value that capability, then you can use static 
libraries.


>So as much as possible, we avoid dynamic polymorphic types because it
>requires Runtime Type Information (RTTI) which tends to slow down
>code.
>

I didn't say anything about dynamic polymorphic types.  I don't know if 
you're referring to the string issue, but I wasn't advocating a specific 
solution to that problem.


>If there's one compelling reason why we should build external
>libraries (which I honestly think there isn't) I would love to hear
>it.
>

Reduced compile times.  Potentially simplified link dependencies.  
Avoiding inclusion of system & other library header files, which often 
have side-effects.

In general, I mostly agreed with the decisions Boost has made, in this area.


>I hope this makes sense. :-)
>  
>

I understand it's a tradeoff.  Thanks for taking the time to articulate 
your position.


Matt