Jean

jpbarrette_at_gmail.com wrote:
> Then, I just wonder what you are trying to solve. I really don't
> understand what is your real problem?
> Sorry but I really don't understand what is the issue here. I know there
> is very few of curlpp that is
> library code, must of it will be included in user space. But again, I
> don't see why that would be an
> issue.

The thing is what for are we building curlpp as a library if only a very small percentage of code goes into the library object file? Maybe we should abandon building curlpp as a library and just tell users to take a source code and compile it with their projects. If not, and if we're going to still support building curlpp as a library we should at least give users a chance to make it a real library with all code inside and not just a few functions that happened to be non templated.

I can summarize this problem in this question
"What are the benefits of building a library file out of curlpp if most part of functionality used by library's users would end up being generated from source and put in users' executable?
The whole idea of building libraries is to allow many programs which need the same functions to use ones placed in a library's file. In case of curlpp any program that uses it generates its own versions of functions and makes almost no use of the library's file. That's against the idea of libraries. It's like someone would write smart pointer template library with extra bonus let's say function giving current system time. And the author would say "Here you have a library. You have to build it and then you can use it." In fact what would be built would be only funny bonus function and nothing from the real functionality. So for all users that would be easier not to bother with building it at all.

Regards
Piotr Dobrogost
_______________________________________________
cURLpp mailing list
cURLpp_at_rrette.com
http://www.rrette.com/mailman/listinfo/curlpp
Received on 2008-11-22