Piotr Dobrogost wrote:
> 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.
>
>

What about boost that is pretty much all headers with relatively little
in the library files. Why did they make that design decision do you propose?

Just a question.

Kind regards,
Brad Hubbard
_______________________________________________
cURLpp mailing list
cURLpp_at_rrette.com
http://www.rrette.com/mailman/listinfo/curlpp
Received on 2008-11-25