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 <curlpp_at_2008.autoera.pl>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
> cURLpp_at_rrette.com
> http://www.rrette.com/mailman/listinfo/curlpp
>

_______________________________________________
cURLpp mailing list
cURLpp_at_rrette.com
http://www.rrette.com/mailman/listinfo/curlpp
Received on 2008-11-03