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

[Glyn M. <gly...@gm...>]

Hi Dean,

On 22 November 2010 11:31, Dean Michael Berris <mik...@gm...>wrote:

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

I think this is a worthwhile task.  I agree that we were being optimistic
when we thought that build times / build size wouldn't matter.


>
> 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.
>
>
Get this wrong and it could be a maintenance nightmare.  Did you look into
using precompiled headers?  What was your conclusion?


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

A policy-based design would suit the XMPP client much more naturally, IMO.
 Also, I think tag-based dispatch is overkill for the URI, since the only
parameter it uses is a string.


> 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.
>
>
I agree.  Tag-based dispatching is very powerful but we run up against a
physical limit which will prevent adoption for anyone but the most
enthusiastic generic programmer.

G