This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ template parameter constraints
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: martin at xemacs dot org
- Cc: gcc at gcc dot gnu dot org, Nathan Sidwell <nathan at codesourcery dot com>
- Date: 30 Jan 2003 01:38:27 -0200
- Subject: Re: C++ template parameter constraints
- Organization: GCC Team, Red Hat
- References: <15928.36654.134741.187229@gargle.gargle.HOWL>
On Jan 30, 2003, Martin Buchholz <martin@xemacs.org> wrote:
> http://m17n.org/martin/writings/template-parameter-constraints.html
> (feedback desired)
/me thinks the syntax for satisfying might be something like Modula3's
`T1 < T2' constraint, used to indicate that type T1 must be the same
or derived from T2. We could use something like:
template <class T : predicate<T>::satisfied> declaration;
and then define the predicate template in such a way that satisfied is
typedefed to T if T satisfies the predicate, and not defined at all
otherwise.
Another addition that I'd find useful for template meta-programming is
an operator such as :?:, similar to :: but with the following
additional properties:
- its left-hand operand must be a template-dependent type name
- if the address of an expression containing :?: is taken and it turns
out that, for a particular instantiation of the template, the member
does not exist, the result is NULL
- a typename expression containing :?: that refers to a type member
that does not exist in a given template name resolves to a new C++
type that, in the absence of a better name, will be called
nosuchtype.
- sizeof applied to nosuchtype is zero
- Any typename expression referencing members of nosuchtype resolve
to nosuchtype
- Any expression involving data members of nosuchtype has type
nosuchtype, and translates to a call of terminate()
- Any expression involving function members of nosuchtype (operator
functions included) succeed overload resolution, but performing the
actual function call evaluates the arguments and calls terminate().
The idea is that such constructs be guarded by NULL- or zero-size
tests and be optimized away, but still parse correctly.
Comments?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer