[cpp-netlib-devel] Staying Header-Only?

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

Hi Everyone,

A lot of people ask why cpp-netlib is header-only and whether there's
a way to move some of the library out to externally linked libraries.
It looks like the compile time is really a big hindrance to some
people, which is starting to make me question the wisdom of why I'm
actually fighting to keep cpp-netlib a header-only library.

With that in mind I'm thinking about user-selectable means of
installing the library. I'm thinking for some people having the
library only in headers might be an option -- say, if they wanted to
just distribute a single binary and they were only building a single
.cpp file and wanted the compiler to be able to optimize everything,
inline things worth inlining, etc.

So I'm starting with cpp-netlib 0.9 to move some of the
implementations out into .ipp files, and having struct declarations
left out in the .hpp files. Now, I'm also looking at making some of
the templates opaque types, so that some of the function
implementations can be moved in .cpp files.

The idea is, when cpp-netlib is used as a header-only library (which
is the default case), everything necessary is brought in just like it
is implemented now. However, if you use it with
BOOST_NETWORK_NO_DEFINITIONS, then the .ipp's aren't included by the
.hpp's and all the definitions should be compiled and linked in from
an external shared/static library.

The challenge now is breaking up all the template implementations and
making some of the types opaque.

Another technique that I would like to re-think is the tag-based
metafunction dispatch. I think it's clever, and I definitely think it
helps with hiding a lot of the complexity of the library. However, it
looks like having a straight-forward policy-based design might even
allow more people to develop more policies that can be made part of
the library.

The main push-back I'm getting with the library now is that it's
taking a lot of resources to build just a simple example. This is a
non-starter for a lot of people and I am willing to compromise on this
given that I'm starting to see the larger picture.

Basically, I'm going to move a lot of the static dispatch out from
metafunctions, and just rely on policies for the client, server, and
message implementations. The message type can be made opaque (a simple
struct) which can then just play nicely with the concepts. This would
remove a lot of the metafunctions that get instantiated all the time
causing the huge compile time requirements.

As much as I think the tag mechanism we're using is one of a kind and
is really scalable conceptually, the reality is no current compilers
can deal with the compile-time costs associated with the technique.

Anyway, I'm getting a hang of writing these long update reports so I
hope you bear with me as I go share more of my thoughts with everyone
on the list. Let me know if you have any objections, whether you
agree, and whether you know of a better way of doing things than what
I suggest above.

Thanks for reading and I definitely look forward to the feedback.

Have a good one everyone and I hope to hear from you soon!

-- 
Dean Michael Berris
deanberris.com