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

[Dean M. B. <mik...@gm...>]

Hi Matt!

On 7/17/07, Matt Gruenke <mgr...@in...> wrote:
> Glyn Matthews wrote:
>
> > Another thing I see is that boost filesystem and boost program_options
> > have
> > dealt with a very similar problem to this.  But if we use the same
> > approach
> > (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
> > accept the use of a cpp source file, meaning we will no longer have a
> > header
> > only library.
>
>
> Why is that so bad?  More to the point, 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).

* 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.

* 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".

So as much as possible, we avoid dynamic polymorphic types because it
requires Runtime Type Information (RTTI) which tends to slow down
code. We also avoid externally built libraries for applications to
link to because that makes the solution practically more complex -- in
the sense that it introduces (IMO) unnecessary external dependencies.
Couple these things together, having RTTI in external libraries makes
your application bloated and unnecessarily complex.

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. On the other hand, I don't think there is a reason for us _not_ to
strive to make this library header only by exploiting the C++ language
features that we have at our disposal.

I hope this makes sense. :-)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459