Hi Dean,
On 22 November 2010 11:31, Dean Michael Berris <[email protected]>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
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Cpp-netlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
