It's always refreshing to have people interested enough in a project to invest time to discuss issues!
On Mon, Nov 3, 2008 at 9:58 AM, Piotr Dobrogost <[EMAIL PROTECTED]>wrote: > 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. I agree completely. > > 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.) Yes there is that sort of checks. Each lifetime policy (for singleton) must implement the behavior of onDeadReference. > > 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 would agree on this only if we would (by using singleton) add more thead safety than libcURL's original behavior. However, I dont know if libcURL initialize function is thread safe or not. That point need to be clarified. Maybe there would be other advantages than thread safety, but I don't see any others currently. > > 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. As I said, it's nice to have people getting their hands dirty! > > > Regards > Piotr Dobrogost > _______________________________________________ > cURLpp mailing list > [email protected] > http://www.rrette.com/mailman/listinfo/curlpp >
_______________________________________________ cURLpp mailing list [email protected] http://www.rrette.com/mailman/listinfo/curlpp
