[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :Re: Associated type as return type. |
From: Douglas Gregor (dgregor_at_[hidden])
Date: 2008-08-21 15:32:05
On Wed, 2008-08-20 at 07:26 +0900, hirohito none wrote:
> > Default implementations can only use operations
> > known to work on the type, e.g., other operations within the concept Foo.
>
> I find in the draft that "A default implementation of an associated
> function is a constrained template"
> But that means following code is ill-formed?
>
> auto concept Foo< typename T >
> {
> // I have to comment out bellow code?
> // void T::func() ;
> void func(T & x) { x.func() ; }
> }
>
> But ConceptGCC complains following code.
>
> auto concept has_func< typename T >
> {
> requires std::CopyConstructible< T > ;
> void T::func() ;// If I delete this line. ConceptGCC does not complains.
> void func(T & x) { x.func() ; }
> }
>
> template < typename T > requires has_func< T >
> void f( T x )
> { func(x) ; }
>
> struct Foo
> { void func(){ } } ;
>
> int main()
> { f( Foo() ) ; }
>
> It's just ConceptGCC does not implement draft correctly?
Exactly. ConceptGCC isn't checking this default implementations.
>
> > This cannot be done directly. You'll need to write an accessor function like
> > "function" above, and then provide an implementation for "function" within a
> > concept map.
>
> I'm disappointed about that. That's tedius.
Perhaps, but it's also more generic: you can add non-member functions
(and adapt them within a concept map), but you can't retroactively add
member variables to a class. (And you can never add member variables to
built-in types)
- Doug