Re: [boost] [Review][PQS] Concept names?

From: David Abrahams (dave_at_[hidden])
Date: 2006-06-18 15:45:05

"Andy Little" <andy_at_[hidden]> writes:

> "David Abrahams" wrote
>> "Andy Little" <andy_at_[hidden]> writes:
>
>>> Your criticism mainly concerned the C++ Concepts section of the
>>> documentation for PQS. What might help is some examples of what you
>>> consider good C++ Concept documentation.
>>
>> The C++ standard does a pretty decent job.  There's also the SGI STL
>> website.  There's also the Boost Graph library.  The "new iterator
>> concepts" document in the iterator library docs does pretty well.  And
>> you can always start at
>> http://www.boost.org/more/generic_programming.html#concept.
>
> I have had a look at these sources and I will look at them in more detail, 
> however they seem to represent only Concepts with runtime requirements.

I don't think so.

        X a(b);

that the syntax is valid is a compile-time requirement.  Any
associated semantics are runtime requirements.

        std::iterator_traits<T>::value_type

100% compile-time requirement.

> Many of the concepts used in PQS library have only compile time
> requirements.  The only example of documentation for this type of
> Concept that I know of is MPL.( I assume you see MPL as a good
> example of compile time only concept documentation). 

Yes, **in the context of the MPL**.  There is a background
assumption that nested members of templates are types and not
values, which you can't reasonably make in the PQS context.

> PQS uses both forms of Concept. Is there any means or language
> convention to distinguish the two forms? 

There are not really two different forms AFAICT.  

> My current intention is to put the compile-time requirement Concepts
> under a separate section from the runtime requirement Concepts.

Almost every concept you write that has runtime requirements also has
compile-time requirements, so I don't know if this division makes much
sense.  But I'm much more concerned with the contents of the concept
descriptions than the order in which they're presented.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com