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

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

Hi Matt!

On 7/18/07, Matt Gruenke <mgr...@in...> wrote:
> Dean Michael Berris wrote:
>
> >
> >* 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.
>

Yes, but remember you need to build the shared/static library first --
which takes up space -- then link to the library next.

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

It still is. It does depend though on Boost.System which is built on a
per-platform basis as an external library.

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

The only requirement which I hope the networking library will ever
need would be Boost (because it's intended to be developed for
inclusion into Boost) and the standard C++ library of your platform.
In the case on Windows using MSVC, if you needed to build
network-aware applications you'd need the platform SDK for the
platform you want to develop on anyway. I don't see how much simpler
an externally built library would make life easier for users of the
library (which I presume are developers) if they needed to build an
extra library and ship it along with their software too when they can
have it all in the software built-in.

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

Shared libraries are only useful if you have multiple applications
using the same library during runtime. Fixing application bugs is not
the domain of the library -- though fixing library bugs is the domain
of the library.

Case in point: ACE. If my application was coded poorly and works with
ACE, is it ACE's responsibility to fix the application bugs I've
introduced? Now if the bug was something that ACE introduced, then
it's something that the authors/developers of ACE would have to deal
with. If there was a change in the ACE API, you'd then have to rebuild
the application anyway -- in which case you just lost the advantage
you just pointed out, where you can "pull the rug under the
application" without making too much of a fuss.

The main point of providing a header-only library is to "build-in" the
functionality that you need into the application. The external
dependency solution is never attractive especially when you can always
build stuff into the solution you're building.

OTOH, if we were talking about a widget toolkit library (like Qt or
MFC or .NET) then I would agree with you completely. But in the case
of providing a simple Boost.Asio based efficient, extensible, simple,
and comprehensive networking library I don't agree that an external
library would be an advantage over a header-only library especially in
the above regard.

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

I was making a point as to why I wouldn't want to have both RTTI and
external linking together. The reality of the situation is (and as how
I understand it), if you need any sort of runtime type information
checking, and when you have runtime-value-dependent implementations --
like in the program_options, serialization, regular expression, etc.
libraries -- then the only way you can achieve it is through the use
of an externally linked library with RTTI code. Otherwise, there's no
point in having your code compiled as a separate unit when it can stay
header-only (example: Spirit).

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

Reduced compile times is not a plus in my book, sorry.

Link dependencies? If the library was header-only, I don't see why
there would be link dependency issues.

I don't see as well how inclusion of system libraries would have a
negative side effect... I also do not see how you can make your C++
application work on the platform you want it to work on if you didn't
use the system libraries of that platform...

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

I agree with the decisions of Boost as well. And while I do agree that
there are some cases where an external library would be necessary, I
don't see this one (the C++ Networking Library) requiring an external
library built. Of course, it could be built that way but I don't see
it being a requirement.

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

Thank you for your comments as well. It allows me to think about the
earlier decisions and what my stance on the matter really is.

Have a great day! :)

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