Boost logo

Boost :

Subject: Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
From: Dave Abrahams (dave_at_[hidden])
Date: 2010-12-15 18:58:28


At Wed, 15 Dec 2010 15:48:31 -0500,
Matt Calabrese wrote:
>
> For what it's worth, I do plan on eventually supporting pseudosignatures,
> though the macro will internally translate the pseudosignature to their
> corresponding "expression validity check" anyway (but with the added benefit
> of more likely being able to be translated directly to what may be C++1x
> concept pseudosignatures, though this is not really my concern for
> now).

That's fine; the key thing is including the forced type conversions at
the function boundaries.

> The
> reason I didn't take this approach from the start is it is much more
> complicated to preprocess a pseudosignature parameter -- in particular, I'd
> need special handling of operators (I.E. users would have to spell
> operator++ as operator pre_inc and the macro internally would have to handle
> each operator explicitly, which will be a fairly tedious
> undertaking).

Meh. I guess that wouldn't bother me much.

> If you can explain what exactly you feel is problematic with the
> current approach in more detail I have no problem with eventually
> scrapping the current interface and only supporting pseudosignatures
> instead.

Eventually, that's where you should end up, IMO. But that shouldn't
impair your progress now if you have momentum. See links in my
previous reply for rationale.

> Can you create archetypes from these concept definitions
> > and do compile-time checking of algorithm bodies? Have you tried to
> > (re-)write any interesting algorithms using these concepts?
>
>
> As for archetypes do you mean automatically create archetypes?

Yep.

> If so, then no. Is this the problem you see with the "valid
> expression" approach over pseudosignatures?

That's not what I was thinking of, but now that you mention it, yes. I
think archetypes are easier to create from pseudosignatures.

> I'd imagine that with pseudosignatures it may be possible for me to
> automatically generate archetypes, though I'd have to give it
> further thought. That alone is certainly a convincing argument for
> pseudosignatures, however, I can see the macro getting fairly
> complicated if such functionality is to be fully-featured. If I do
> eventually follow that idea, it will likely take quite some time to
> implement.

No doubt!

> As for writing algorithms with the concepts, no, I haven't done so yet other
> than an Auto_Function "advance" that uses concept-based overloading.
> Unfortunately, things end up being verbose and loaded with parentheses.
> Manual tag dispatching ends up being cleaner in practice, so the benefits
> are questionable.

Oh, that's a shame.

You know, with C++0x you also have variadic macros, which could
potentially clean up the syntax... or are you already using those?

> The main advantage here is that such "category" types that are used
> for tag dispatching don't have to be created to begin with since the
> concepts themselves can be used directly. Here's the "advance"
> implementation I use for testing. It is actually much more
> complicated than std::advance because I'm using the return type to
> determine which overload is picked. Try to look past that complexity
> since it wouldn't be there in an actual implementation.
>
> http://codepaste.net/qcz4cq
>
> Anyway, at the moment such rewrites aren't very interesting except for being
> able to do concept-based overloads, since currently the only concept maps
> that are supported are empty concept maps. With regards to the iterator
> concepts, associated types are still accessed via iterator_traits as opposed
> to via a concept_map directly because I have yet to fully implement
> associated types with concept maps. So, at this point, Generic is really
> only worthwhile for "pretty" asserts and concept-based overloading, though
> that should hopefully change in the near future.

That's still a significant achievement. Great going!

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk