Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)

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