template argument to enum

[wogston]

A)

template <typename scalar, int size>
struct basevector
{
enum { size = size };
scalar v[size];
};

B)

template <typename scalar, int size>
struct vector : basevector<scalar,size>
{
// ... impl.
};

template <typename scalar>
struct vector<scalar,3> : basevector<scalar,3>
{
// ... specialization related enhancements to impl.
};


OK, the code snips out of the way, the A) segment above declares/defines
base type, from which various different vector types are inherited (vector,
point, quaternion...). The B) segment declares the specific example of
scalar vector type. Why there is enum for size in the basevector, is, that
it makes the size visible to specialized types, which don't have access (as
far as I know of) to the template size argument.

Question: is it legal to write enum { size = size }; .. as far as I
undertand, the scope for left side of assignment is the enumeration, and
right side is the outer scope, in this case template argument. Is this
defined well enough in the standard, so that I can expect compilers not to
give compilation time diagnostic warnings about unsolved resolution and such
(I know these are implementation defined details, but does standard guaratee
the above code snip should compile (assuming there aren't typoes above, I
didn't quite copy-paste from complete code, tried to isolate the code
relevant to the question only).

This is a moot point in practise, I gave the outer template argument name
"vsize", but I am asking for curiosity (it compiled with few compilers I
tested on with the above variation).

If someone is wondering why I want the size visible, it is for recursive
template meta-program which requires the size of the vector as one of the
arguments, to know the number of recursions required to handle all
components of the vector. I'm using same "sourcecode path" to generate all
the specializations, and that requires the "size" enumeration, so that I
don't have to repeat the code 9 times (at this time for: vector<scalar,2>,
vector<scalar,3>, vector<scalar,4>, same for quaternion and point, total: 9
times same code, so it's handy to have the enumeration visible, no?

I'm assuming that the enum { size = size }; is correct and valid c++, but
somehow it looks amazingly stupid, so I renamed the argument so that the
code wouldn't be so bloody obfuscated to the casual observer. What would you
have done in similiar situation?

p.s. namespace collision are easily avoided, since I use these templates
through typedefs, which also have a scope themselves, so in practise it
turns into:

using coremath::float3;
....
float3 v(x,y,z);
float3 u = v * 1.2f + coremath::dot(a,b) * c; // ... etc.

(so apologies, a lot of text for a very short question, is that stupid or
not, if it's stupid, why?

 

[Michael Kochetkov]

A)

template <typename scalar, int size>
struct basevector
{
enum { size = size };

This is ill-formed. You may not redeclare template parameter.

scalar v[size];
};

B)

template <typename scalar, int size>
struct vector : basevector<scalar,size>
{
// ... impl.
};

template <typename scalar>
struct vector<scalar,3> : basevector<scalar,3>
{
// ... specialization related enhancements to impl.
}; [...]

If someone is wondering why I want the size visible, it is for recursive

I am not, but I see another problem. The base class scope is not considered
during the name lookup until the point of instantiation of the class. So,
provided you have change the enumerator name to vsize you will have to
qualify vsize explicitly.

[...]

I'm assuming that the enum { size = size }; is correct and valid c++, but

It looks like to be the wrong assumption.

 

[wogston]

I'm assuming that the enum { size = size }; is correct and valid c++,
but

It looks like to be the wrong assumption.

It looks to me that your not helping much with that. Why is is wrong
assumption, I already explained why I think it was correct, simply saying:
"no, it's wrong" doesn't help much. Tell me what's wrong with the
hypothesis:

template <int x>
struct foo
{
enum { x_ = x };
};

x_ is "deeper" in the scope hierarchy, the x is visible until (and after) x_
is declared. If they have the same name, the scoping rules certainly still
apply? If not, why?

My guess is that you mean, that compiler cannot resolve which x is meant,
but in this case I thought the hierarchically "closer" one overrides
automatically, if not, then say so and I can be sure. I asked this question
in my original post.

I tested with Comeau online compiler, Intel C++ 7.1, Visual C++ .NET 2003
and G++ 3.3 and they all according to you are not standard conformant.
Doesn't look very good for C++ programming in general if the most common
tools are broken. Why is it, that it's always the C++ where tools are broken
and other languages have perfectly working tools, is C++ too complex for
it's own good, to be correctly implemented? Afterall, C++ been around for
years and years and years now, still no good compilers. I'm still waiting.
Someday.

So what's the rationale behind your response? I already gave mine, twice.
Thank you.

 

[Michael Kochetkov]

It looks to me that your not helping much with that. Why is is wrong
assumption, I already explained why I think it was correct, simply saying:

I have explained "why" in the lines you have carefully skipped.

 

[Rolf Magnus]

I tested with Comeau online compiler, Intel C++ 7.1, Visual C++ .NET
2003 and G++ 3.3 and they all according to you are not standard
conformant.

Does that mean that they accepted it? That's strange. Both g++ 3.3 and
comeau online (I can't test the others) reject it here. When I try to
compile the following code:

template <int x>
struct foo
{
enum { x = x };
};

g++ 3.3 gives me the following errors:

wogston.cpp:4: error: declaration of `int x'
wogston.cpp:1: error: shadows template parm `int x'
wogston.cpp:4: error: declaration of `int x'
wogston.cpp:1: error: changes meaning of `x' from `int x'

and comeau online:

"ComeauTest.c", line 4: error: template parameter "x" may not be
redeclared in this scope
enum { x = x };
^

How did you test it?

 

[wogston]

I have explained "why" in the lines you have carefully skipped.

Ah, sorry, I need a pair of new glasses: I didn't notice with quick glance
that you don't leave blank lines. I saw it as fuzz of black with a quick
*glance*, totally my bad.

 

[wogston]

How did you test it?

Not with that trivial example, it fails here, too. I changed the code to:

template <int x>
struct foo { ... };

template <>
struct foo<4> { enum { x = 4 }; };

... I used that style already very quickly after the initial post, I didn't
like the vsize/size syntax either, this is 'nicer' for my purposes, eg for
specialized types I 'supply' the size, or in this case, x.

That should be ok?

 

[Rolf Magnus]

Not with that trivial example, it fails here, too. I changed the code
to:

template <int x>
struct foo { ... };

template <>
struct foo<4> { enum { x = 4 }; };

.. I used that style already very quickly after the initial post, I
didn't like the vsize/size syntax either, this is 'nicer' for my
purposes, eg for specialized types I 'supply' the size, or in this
case, x.

That should be ok?

I'd say yes. In the specialization, there is no template parameter x
anymore, so there is no conflict about that name.