Re: [cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

[Kim G. <kim...@gm...>]

Hi Dean,

On Fri, Aug 21, 2009 at 17:07, Dean Michael
Berris<mik...@gm...> 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!

> 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.

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.

- Kim