http://blog.gmane.org/gmane.comp.web.curl.curlpp.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/333 _______________________________________________ cURLpp mailing list cURLpp-V5R0HI2H36zQT0dZR+AlfA< at >public.gmane.org http://www.rrette.com/mailman/listinfo/curlpp Jean-Philippe Barette-LaPierre 2008-11-27T15:54:01 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/332 Jean Jean-Philippe Barette-LaPierre wrote: I know. The question is: Why do we need the second overload of option method with two template parameters? Regards Piotr Piotr Dobrogost 2008-11-27T15:15:40 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/331 _______________________________________________ cURLpp mailing list cURLpp-V5R0HI2H36zQT0dZR+AlfA< at >public.gmane.org http://www.rrette.com/mailman/listinfo/curlpp Jean-Philippe Barette-LaPierre 2008-11-27T13:51:38 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/330 Jean Jean-Philippe Barette-LaPierre wrote: Why do we need the second overload of option method above? Giving CURLoption as a template argument in the second overload creats as many option methods as there are many CURLoption values. In the body of the second option method optionType argument of template is only forwared as the first argument of the first overload of option method. Why do we need option<bool, CURL_some_option>(bool) and option<bool, CURL_some_other_option>(bool) etc. ? Regards Piotr Dobrogost Piotr Dobrogost 2008-11-26T23:31:11 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/329 _______________________________________________ cURLpp mailing list cURLpp-V5R0HI2H36zQT0dZR+AlfA< at >public.gmane.org http://www.rrette.com/mailman/listinfo/curlpp Josh Dye 2008-11-26T04:13:58 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/328 _______________________________________________ cURLpp mailing list cURLpp-V5R0HI2H36zQT0dZR+AlfA< at >public.gmane.org http://www.rrette.com/mailman/listinfo/curlpp Jean-Philippe Barette-LaPierre 2008-11-25T13:49:27 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/327 _______________________________________________ cURLpp mailing list cURLpp-V5R0HI2H36zQT0dZR+AlfA< at >public.gmane.org http://www.rrette.com/mailman/listinfo/curlpp Brad Hubbard 2008-11-25T01:33:13 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/326 This should of course be applied to CurlHandle.cpp Brad Hubbard wrote: Brad Hubbard 2008-11-25T02:06:01 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/325 Jean-Philippe Barette-LaPierre wrote: JP, What about a compiler warning to say that one or the other will be deprecated in future (if that is the plan)? Kind regards, Brad Brad Hubbard 2008-11-25T01:28:13 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/324 Piotr Dobrogost wrote: Maybe leave this for the time being Piotr otherwise we might do the same work twice? I'll get back to you in the next few hours. Cheers, Brad Brad Hubbard 2008-11-25T00:38:25 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/323 Brad Brad Hubbard wrote: I'm not sure I understand your question. If you are asking why most of boost is delivered as source code only then the answer is - they don't have a choice. Boost libraries are written in such a way as to be able to operate on user defined types. That's the real power of templates. They can't compile their libraries because it can be done only if the library knows user's types. So only user of the library can compile it _together_ with his code. In case of curlpp situation is different. Curlpp doesn't operate on user defined types and uses templates only "internally". As such it can be compiled into library object file. Regards Piotr Dobrogost Piotr Dobrogost 2008-11-25T01:28:18 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/322 Piotr Dobrogost wrote: 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 Brad Hubbard 2008-11-25T01:14:01 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/321 Piotr, The following patch allows everything except the examples to compile under 4.3.0; 24d23 < #include <cstring> 48c47 < std::memset(mErrorBuffer,0,CURL_ERROR_SIZE + 1); --- > memset(mErrorBuffer,0,CURL_ERROR_SIZE + 1); 61c60 < std::memset(mErrorBuffer,0,CURL_ERROR_SIZE + 1); --- > memset(mErrorBuffer,0,CURL_ERROR_SIZE + 1); 70c69 < std::memset(mErrorBuffer,0,CURL_ERROR_SIZE + 1); --- > memset(mErrorBuffer,0,CURL_ERROR_SIZE + 1); I can do the same for the examples if you wish, but it will have to wait a while as I am busy with another project currently. Alternatively, if you want to modify the examples along those lines and let me know I will download and test the modified source. Kind regards, Brad Brad Hubbard 2008-11-25T00:54:23 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/320 Brad Brad Hubbard wrote: Good question :) As to memset there are only 3 of it, all in CurlHandle.cpp. As this is only implementation file so there's no fear about polluting namespaces. I think the same is with the rest but someone should check it. By the way there's other problem, however. As we now include c headers in c++style <cxxx> we should either qualify memset and others from c library with std:: or write using directive on top of source files... I'll try to fix it. Great. You can grab it here http://www.bitbucket.org/jpbarrette/curlpp/overview/ Click download in the top right corner of the page. Regards Piotr Dobrogost Piotr Dobrogost 2008-11-25T00:10:46 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/319 Piotr Dobrogost wrote: Hi Piotr, I have no concerns with how this is handled in the examples. There are some of these calls within the curlpp code itself though aren't there (memset, etc.)? Where can I download the latest version incorporating Bob's changes and I will attempt to compile it under 4.3.0 and report back? Kind regards, Brad Brad Hubbard 2008-11-24T22:08:04 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/318 Brad Brad Hubbard wrote: It's hard to say we pollute global namespace as our examples are such a short and self-contained. We could use several using-declarations instead of one using-directive but I think we shouldn't as this makes examples longer and adds no value in case of our short, self-contained examples. Have you spotted other places in addition to these corrected by Bob? Regards Piotr Dobrogost Piotr Dobrogost 2008-11-24T11:29:10 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/317 Piotr Dobrogost wrote: I personally would lean the other way, the std:: qualifier makes it far more clear what you are doing and does not pollute the global namespace. You could also consider "using std::memcpy;" etc. to keep the global namespace cleaner. The headers need to be tidied up for g++ 4.3.0 anyway, it is far stricter on where headers are included and requires the programmer be more specific, From memory the headers in question were cstdlib and cstring and they had to be included in multiple places where they currently are available as a side-effect of another include. Kind regards, Brad Hubbard Brad Hubbard 2008-11-24T05:52:08 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/316 My opinion is that: 1. Whatever symbol (tab or space) is selected for indenting, it should be used consistently across the whole project without mixing. 1. I prefer spaces because they play 'fair' as opposed to tabs Please use andrei at korostelev dot net to send me personal emails. I normally do not use this address for maillists and use some free (aka mail.ru) instead Regards, Andrei Andrei 2008-11-23T14:59:32 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/313 Thanks. Yep. Regards Piotr Dobrogost Piotr Dobrogost 2008-11-23T10:43:51 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/312 Done. I see there are still some things to be fixed aka duplicate files under include/curlpp/ and in include/utilpp/, but I hope you are aware of that. Andrei Andrei 2008-11-23T08:33:28 http://permalink.gmane.org/gmane.comp.web.curl.curlpp.general/311 Jean jpbarrette-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 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. Regards Piotr Dobrogost Piotr Dobrogost 2008-11-22T22:25:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.curl.curlpp.general