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 ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
