Boost logo

Boost :

From: Chad Parry (spam_at_[hidden])
Date: 2006-08-22 13:46:39


"Douglas Gregor" <doug.gregor_at_[hidden]> wrote in message
news:ECF14E7B-BC49-4021-9828-A1EF57C862E9_at_cs.indiana.edu...
>
> On Aug 20, 2006, at 11:48 PM, David Abrahams wrote:
[snip]
>> Well, it looks really interesting (really!), but I think you should
>> review the ConceptC++ publications, in particular N1849, before
>> investing more time in it. Also, IMO, you should try to model the
>> standard concepts and see how it works out in practice.
>
> I strongly suggest that we focus on the latest concept proposal,
> N2042. N2042 is the result of countless hours of discussions among
> the authors of the two different concepts proposals, and it is the
> only concepts proposal that will be moving forward.
>
> You can find up-to-date information on the concepts proposals,
> compiler, etc. on the ConceptC++ home page:
>
> http://www.generic-programming.org/languages/conceptcpp/
>

That's exactly the kind of feedback I was hoping for. I'll focus more of my
attention on these items you brought up:
1) Try to mimic the declarative syntax rather than the use pattern syntax.
(There's probably no reason why both can't be supported simultaneously in a
library solution like this.)
2) Require authors to declare that their types model a concept; don't assume
matches based on syntax. Allow for concepts to be declared with the
opposite default behavior if they wish.
3) Try to make the errors user-friendly.
4) Add support for associated types. (I've already thought a lot about this
and it won't be too hard.)
5) Improve the user experience for signatures that are known to be
undetectable by library code. This includes the DefaultConstructible<T>
concept, for example. I've already thought a little about this. I know how
to elegantly encode requirements like Swappable<T, U> but I'll save that for
another post. :)

Thanks for the encouragement! I'll report again when I have made some
progress. In the meantime, anyone who replies to me privately is welcome to
have access to the sources.

-- chad


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