«

Curt wrote:
> Ulrich Eckhardt <> wrote :
> [explicit 'typename' required]
>
> I wonder what ivory-tower insanely contrived "problem" it solves.
>

Hmmm, let's see if I can make up one (I just remember having been shown a
valid example).


struct foo
{
enum{ value = 1};
};

struct bar
{
typedef float value;
};

struct baz
{
long value();
};

template< class T> void foobarr()
{
typedef /*typename*/ T::value value_type;
};

As you see, there are three different things being referred to by T::value,
an integral, a type and a memberfunction.

Hmmm, I think I'm stuck, I don't remember the rest of it.
Anyway, I set a follow up to clc++, maybe the amassed brainpower there can
help.

cheers

Uli

--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !

On Fri, 12 Sep 2003 15:43:16 +0200, Ulrich Eckhardt
<> wrote:

>Curt wrote:
>> Ulrich Eckhardt <> wrote :
>> [explicit 'typename' required]
>>
>> I wonder what ivory-tower insanely contrived "problem" it solves.
>>
>Hmmm, I think I'm stuck, I don't remember the rest of it.
>Anyway, I set a follow up to clc++, maybe the amassed brainpower there can
>help.

There are a number of advantages that I can think of:

1. It is obvious by looking at source code that a particular dependent
name is supposed to be a type, rather than a static member or whatever
(this doesn't apply to the original example).

2. It allows syntax checking of template definitions that haven't been
instantiated. Experience has shown that whenever any significant
template source code base has been run through a compiler with
template syntax checking for the first time, a large number of errors
and typos have been found in templates that hasn't yet been
instantiated by the authors during testing.

3. It is enforced that a particular dependent name is be a type,
template or whatever, rather than depending upon a particular
instantiation context.

4. As for why typename is still required when it is "obvious" that a
typename is being named (e.g. in a typedef), consistency and ease of
parsing are the reasons.

There are enough pragmatic people in the C++ standards committee to
ensure that "ivory-tower insanely contrived "problem" solving"
features don't tend to make it into the standard.

Tom

> > I wonder what ivory-tower insanely contrived "problem" it solves.
[snip]
> Hmmm, let's see if I can make up one (I just remember having been shown a
> valid example).
[snip]
> template< class T> void foobarr()
> {
> typedef /*typename*/ T::value value_type;
> };

Names dependent on a template parameter is assumed not to name a type
unless the applicable name finds a type name or the name is qualified
by the keyword typename:

typedef typename T::value value_type;
value_type v1;
typename T::value v2
T::value v3 // Error - T::value is not a type name
// so in effect 'value v3' makes no sense

The "ivory-tower insanely contrived 'problem' it solves" is that you
can't declare types without a type.

-CJohnson

> T::value v3 // Error - T::value is not a type name
> // so in effect 'value v3' makes no sense
>
> The "ivory-tower insanely contrived 'problem' it solves" is that you
> can't declare types without a type.
>
> -CJohnson

Yes I did some research and found a similair example, I always look up
stuff in c++ that I've never seen before.

Since my personal belief is that non-trivial template use is an act of
evil. That there is a special place in hell for people who "get cute" with
complicated syntax, thus making code a maintenance nightmare. I can see why
it never came up before.

One of these days I'm going to write a book- "Problems you should never
have, and the solutions to them"

In any case I've filed it away for future use, thats why I love
programming- not a day goes by that I don't learn something new.

-Curt