Hi Kim!
On Sun, Aug 23, 2009 at 4:03 PM, Kim Gräsman<[email protected]> wrote:
> Hi Dean,
>
> On Fri, Aug 21, 2009 at 17:07, Dean Michael
> Berris<[email protected]> wrote:
>>
>> I understand -- I'm actually on the way to becoming a father myself
>> this November so I'm actually trying to get as much open source
>> programming time now before my first baby arrives. :D It would be
>> great to see you contributing to the testing and even the
>> implementation again. :)
>
> Congratulations!
>
Thanks. :)
>> Yes, I was actually struggling with this one -- if I go about it
>> through the overloading route, it would look something like this:
>>
>> template <class Range>
>> bool parse_specific(Range & range, tags::default_);
>>
>> template <class Range>
>> bool parse_specific(Range & range, tags::http);
>>
>> Which I think would work and would be worth a shot implementing. The
>> call to parse_specific then would look like:
>>
>> parse_specific(range, Tag());
>>
>> In parse_url.
>
> Looking more closely, I'm not sure that can be made to work, as
> parse_specific's second param is an url_parts<Tag>&, derived from the
> template arg.
>
Oh right. Should it then be:
template <class Range>
bool parse_specific(Range & range, url_parts<tag::default_> & parts);
template <class Range>
bool parse_specific(Range & range, url_parts<tag::http> & parts);
or
template <class Range>
bool parse_specific(Range & range, url_parts<tag::default_> & parts,
tag::default_);
template <class Range>
bool parse_specific(Range & range, url_pars<tag::http> & parts, tag::http);
?
> We could overload on the entire url_parts<tag> type, but then there
> would be no way of accessing other types derived from the tag (e.g.
> string_type) inside the implementation.
>
> I think maybe the easiest -- accepting the strangeness of tag
> dispatching for a second ;-) -- would be to turn parse_specific into a
> class template, e.g. scheme_specific_parser, like so:
>
> template< typename Range, typename Tag >
> struct scheme_specific_parser
> {
> bool parse(Range& range, url_parts<Tag>& parts)
> {
> return true;
> }
> };
>
> Then we'd get rid of the problems with overload resolution and partial
> specialization wrt function templates entirely.
>
Makes sense... However, my only concern here is that the simplicity of
using the free function parse_specific and relying on ADL to pick up
the correct implementation.
Although I guess it should be easy to make 'parse' a public static
function so we don't have to instantiate the scheme_specific_parser<>.
I like it! :D When do I expect a patch and passing tests? :D
--
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Cpp-netlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
