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

[Dean M. B. <mik...@gm...>]

Hi Kim!

On Sun, Aug 23, 2009 at 4:03 PM, Kim Gräsman<kim...@gm...> wrote:
> 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!
>

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