[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :Refining concepts and concept_map management |
From: Tom Honermann (tom.honermann_at_[hidden])
Date: 2007-06-22 05:52:39
Playing with conceptgcc-boostcon on Linux/x86 and looking at
considerations managing concept_maps throughout code evolution...
Assume we start with code like the following and for various reasons
this code cannot be modified (ie, third party or system/compiler code)
#include <concepts>
concept C<typename T> {
typename type;
void foo(T);
}
struct S {
typedef int type;
void foo() const;
void bar() const;
};
concept_map C<S> {
typedef S::type type;
void foo(S) { s.foo(); }
}
Now I come along and want to refine concept C to include a function bar():
concept CWithBar<typename T> : C<T> {
void bar(T);
}
I now need a concept_map for CWithBar<S>. The problem is that writing
this concept map requires re-implementing the associated types and
functions already present for the C<S> concept_map. Ideally, I'd like
to be able to do something like:
concept_map CWithBar<S> : C<S> {
void bar(T) { s.bar(); }
}
or perhaps:
concept_map CWithBar<S> {
using C<S>;
void bar(T) { s.bar(); }
}
or even:
concept_map CWithBar<S> {
using C<S>::type; // typedef C<S>::type type; does work for
associated types...
using C<S>::foo;
voif bar(T) { s.bar(); }
}
Looking through n2193, I haven't been able to find a way for one
concept_map to inherit from another one. I know that implementing all
of the concept requirements in _only_ CWithBar<S> would implicitly
satisfy the concept map requirements for C<S> and allow me to have the
concept map definitions for each concept requirement in exactly one
place (which is my goal), however taking this approach requires
modifying code that might affect the scope/risk/cost/compatibility of
making the change.
Tom.