Boost logo

Boost :

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-10-13 21:38:05


On Sat, Oct 13, 2012 at 4:55 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> On Sat, Oct 13, 2012 at 5:52 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:
>
>>
>> http://contractpp.svn.sourceforge.net/viewvc/contractpp/trunk/doc/html/contract__/concepts.html#contract__.concepts.concept_definitions__not_implemented_
>>
>
> Another minor comment. For associated types and constrained parameters such
> as:
>
> template< ObjectType T>
>
> I see you are using the syntax
>
> template( typename(ObjectType) T )
>
> I am currently using the following syntax in Boost.Generic:
>
> template( ((ObjectType)) T )

My (Boost.Contract) syntax uses this for a value template parameter
named T and of type ObjectType (leaving the double parenthesis a
side). So I need the typename prefix in order to distinguish between
template template parameters and value template parameters.

On this topic, while reading N3351 I was thinking to not support this
syntax and use requires instead:

template( typename T )
        requires( ObjectType<T> )
    concept_map (RandomAccessIterator) ( T* )

Because I don't know how to support the following:

template( typename(ObjectType) T, typename(MapType<T>) U )
    concept_map (RandomAccessIterator) ( T* )

Where U is of constrained by MapType<U, T>. The only way I can think
to do this is typename(MapType<mpl::_, T>) U (then it'd be up to
Boost.Generic to deal with mpl::_ used this way). Does this use case
apply to associated types?

> This is for a couple of reasons. First, it's concise and closer to the
> standard syntax, but also because in the end that syntax should be able to
> be used for unary concepts whose parameter is not a type, in which case
> "typename" doesn't really make sense.

Thanks,
--Lorenzo


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