First, I would thank Peteris Krumins for his curl_get_info patch. It's always
a pleasure to receive some contributions from other people. This patch was
needed. However, I'm not quite sure that we should handle it as it is
suggested by Peteris. I know it's stupid to say that, but it's too simple ;P

        What I mean is that there's no type check, and there's no way to change the
behavior. Why is it so important? Well, cURLpp's design is built on the
assumption that I'm lazy. Those who knows how cURLpp is made (and I'm
probably the only one), they know that it's very easy to fix the problems we
got lately. I'll take the latest bug I got from Peteris for an example.

         cURLpp::Options::PostFieldSize option was specified to be a char *. Well, it
was wrong, 'cause CURL_POSTFIELDSIZE need a long. This problem could have
been resolved without causing any repersussion on any program depending on
cURLpp (even if there's not a lot of them). The simple way of bypassing it
would have been to declare something like this:

typedef cURLpp::OptionTrait< long, cURL::CURLOPT_POSTFIELDSIZE >
MyPostFieldSize;

and then use this MyPostFieldSize option instead of cURLpp::PostFieldSize.
This is true for new options too. The user could add some new options of
libcURL, without any need of recompilation of cURLpp. So, I want to enable
the same behavior with curl_get_info. I'm suggesting the following usage:

char *myvalue;
exEasy.getInfo(cURLpp::info::EffectiveUrl(myvaluee));

EffectiveUrl would be, as options are, a typedef. We could specialize it to
handle std::string or other types. What do you think folks? If you think I
smoked too much pot, mention it, and I'll try to get sober :P

-- 
Jean-Philippe Barrette-LaPierre
Maintener of cURLpp (http://rrette.com/curlpp.html)
_______________________________________________
cURLpp mailing list
cURLpp_at_rrette.com
http://www.rrette.com/mailman/listinfo/curlpp