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?


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at