On Jan 21, 2008 8:08 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to
> discuss implementation of the compiler and library parts of the
> C++0x concepts proposals. This is to be a brainstorming session, where
> we discuss the best way to complete the work, what can be taken from
> existing branches, and how to smoothly transition between a
> concept-enabled standard library and the current libstdc++.
Some notes from the discussion in this call:
Organization:
- We'll start a fresh branch in the FSF repository dedicated to concepts
(it's branches/cxx0x-concepts-branch). Initially, Doug and Jason
will be maintainers of this branch
- We want to minimize the distance between this branch and mainline:
* All non-concepts C++0x features will still go into mainline
(unless they depend on concepts)
* Type-checking of constrained templates depends on improved
type-checking of C++98 templates (particularly, checking of
non-dependent expressions), so we'll try to do all of this work in
mainline
* Doug will merge from mainline to branch regularly
- Will salvage what we can from ConceptGCC: concept-checking,
archetype generation, and parsing bits will be useful; type-checking
of constrained templates needs to be reworked significantly.
- We're not going to commit to any schedule, but it'll be a multi-year effort
- We're going to delay any decisions about library issues for
now. They won't matter until the front end supports enough of concepts
to permit their use in the library
C++ front end:
- Concepts representation:
* Concepts, concept maps will be RECORD_TYPEs to reuse as much of
that logic as is possible
* Archetypes will probably need their own, new tree nodes
- Same-type constraints and mapping to archetypes caused a lot of
trouble in ConceptGCC: canonical types could simplify this
- Constrained templates will create many new nodes in the internal
representation that don't need to be around after a constrained
template is type-checked; we might need to consider a stricter memory
management scheme
- Performance of the generated code was a problem with ConceptGCC,
which Doug blames on the inliner. We should consider a limited form of
inlining in the instantiation of constrained templates to avoid
swamping the inliner with the forwarding functions in constrained
templates.
For more information about the concepts branch, see
http://gcc.gnu.org/projects/cxx0x.html#concepts
For more information about ConceptGCC, see
http://www.generic-programming.org/software/ConceptGCC/
- Doug
