Jean-Philippe Barette-LaPierre wrote: > Well, programmers have a tendency to use directly the examples that are > given to them (I am one of them). The problem with the cURLpp::Cleanup > class is that it's wrongly used by some programmer each time they need > to use cURLpp in a program. So, I've seen programs with multiple use of > that cleanup class, which is very problematic in multi-threaded code. > So, the thing is that this class is dangerous if misused (which is quite > easy to do), and doesn't give us any real advantage since the > initialization of the libcURL library is done anyway at the first call > to curl_easy_perform.
Jean I can't agree with this. Libcurl's developers write in http://curl.haxx.se/libcurl/c/libcurl-tutorial.html "libcurl has a default protection mechanism that detects if curl_global_init(3) hasn't been called by the time curl_easy_perform(3) is called and if that is the case, libcurl runs the function itself with a guessed bit pattern. Please note that depending solely on this _is not considered nice nor very good_." (emphasis mine) I agree with them :) Initialization is a must and we shouldn't "protect" users of the library from it because there is nothing better we can do. (Smarter is not always better :)) Hiding something important (need for initialization in this case) is never a solution. I looked at Cleanup class and to my surprise I see it doesn't even use Singleton pattern which is implemented in utilspp. In this case users don't even get an error when they misuse this class. That's not how it should be :) 1. Cleanup should be a singleton. 2. We should add a debug mode in which a. We should check if Cleanup is created after it was destructed. The exception being a subclass of logic_error should be thrown if this is a case. (Not remember if Loki's Singleton has this feature. If not we should add it by ourselves.) b. We should check in perform() and possibly in other methods if the Cleanup singleton exists. The exception being a subclass of logic_error should be thrown if it doesn't. I can try to make these changes. I could also try to add smart pointers to the lib's interface in place of raw ones. Regards Piotr Dobrogost _______________________________________________ cURLpp mailing list cURLpp@rrette.com http://www.rrette.com/mailman/listinfo/curlpp
