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@rrette.com http://www.rrette.com/mailman/listinfo/curlpp
