Re: [Boost-users] [netlib] throwing exceptions with http_client.cpp

Subject: Re: [Boost-users] [netlib] throwing exceptions with http_client.cpp
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-19 02:25:16

On Fri, Nov 19, 2010 at 3:11 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 11/19/2010 12:10 PM, Dean Michael Berris wrote:
>>
>> On Fri, Nov 19, 2010 at 3:22 AM, Christian Henning<chhenning_at_[hidden]>
>>>
>>> I'm sure this idea already came up but why not let the user have the
>>> option of making parts of netlib compile into a lib?
>>>
>>
>> Yes, it's already come up. ;) The real reason is because I don't see
>> which parts of cpp-netlib can be moved into a compiled lib. Most -- I
>> should say "all" -- of the algorithms I implement is generic. Maybe
>> later on I can do that, but only once I see which parts can be moved
>> to a compiled lib. :D
>>
>> Also, I aimed to do it header-only, which I think I've largely
>> succeeded in doing now. Going the other way looks really hard from
>> where I'm sitting. :D
>
> A good way to start is by separating the implementation files from
> interface files such that the user can include the interface files
> from headers and the implementation files from cpp plus template
> instantiations with the client's actual template types.
>

Interesting. This sound like a lot of work though.

My problem is that a lot of the types are determined through template
metafunctions. I don't have many opaque types lying around that I can
move the implementations of to compilable files. I also have a ton of
template functions that are marked 'inline' to avoid ORD violations
when compiling/linking.

Also, providing the template specializations myself sound like a
really bad nightmare. If I didn't aim to support for example a means
of supporting std::string, std::wstring, std::vector<char>, CString,
QString, and <insert-string-implementation-here> in the messages, I
might be able to move implementations over and just support
std::string all throughout the library.

> I'm sure this will be asked time and time again. It's better to
> deal with this sooner rather than later.
>

Yeah, I'm going to have to talk this over with those with more
experience with this sort of thing to see how I can even begin to
unravel this moving from header-only to compiled-lib thing. :D

> Regards,

Thanks Joel for the hints, I'll look again once 0.8 is out to see if
this can be made an option! :)

-- 
Dean Michael Berris
deanberris.com