gcc 3.4

[Shivoc]

are there any plans to support gcc 3.4 yet?
currently your headers won't work with gcc 3.4 due to the changes in function lookups for template instantiations (from gcc changes page: In templates, all non-dependent names are now looked up and bound at definition time (while parsing the code), instead of later when the template is instantiated.)

this is mainly a problem with the template for Ice::ProxyHandle which tries to use the ::IceInternal::checkedCast functions for casts to the Proxy class.
The problem here is, you would have to deklare the checkedCast functions for each class which could possibly be used (which include classes defined by the idl of user programs)

is there any work done to solve this problem yet?
i would really like to try the new gcc with Ice based projects, wich is pretty impossible (especially since not even the headers compile cleanly)

Sven

[bernard]

The next Ice release will support GCC 3.4. I fixed all these compilation problems yesterday .

Cheers,
Bernard

[michi]

Originally posted by Shivoc
are there any plans to support gcc 3.4 yet?
currently your headers won't work with gcc 3.4 due to the changes in function lookups for template instantiations (from gcc changes page: In templates, all non-dependent names are now looked up and bound at definition time (while parsing the code), instead of later when the template is instantiated.)

We've been having arguments about this here too. From the spec:

In an expression of the form:

postfix-expression ( expression-list-opt )

where the postfix-expression is an identifier, the identifier denotes a dependent name if and only if any of the expressions in the expression-list is a type-dependent expression (14.6.2.2).

In the checkedCast that causes the problem, the parameter is type-dependent and, according to this definition, checkedCast is also type-dependent. But the spec then goes on to say:

If an operand of an operator is a type-dependent expression, the operator also denotes a dependent name. Such names are unbound and are looked up at the point of the template instantiation (14.6.4.1) in both the context of the template definition and the context of the point of instantiation.

So, I'm not sure that gcc 3.4 is right.

As Bernard mentioned, he has already changed the way checkedCast is implemented so it works with both old and new gcc versions (and he also reduced the size of the generated code in the bargain), so the question is somewhat academic. But I'd still like to know whether what gcc 3.4 is doing here is actually correct. On reading the spec, it doesn't look that way.

Cheers,

Michi.

[michi]

Ah, Bernard found a newsgroup discussion about this: http://groups.google.com/groups?hl=e...ing.google.com. Section 14.6.2.2 does not apply because ::IceInternal::checkedCast is a qualified name, not an identifier. Hence, only the context at the point of template definition is considered, not the context at the point of instantiation, and GCC 3.4 indeed implements the standard to the letter.

There appears to be consensus though that the standard is broken in that respect. (Looking at the defect list for ISO C++, issue 448 deals with this -- see http://anubis.dkuug.dk/jtc1/sc22/wg2...wg_active.html. My expectation is that the eventual resolution will include qualified names as well as other type-dependent expressions that are not caught by the current defintion, because that is clearly the intent. But, until this becomes official, GCC 3.4 is right.

Cheers,

Michi.

[Shivoc]

thanks for the infos... i also wondered why it would be non-dependant...

so, that just leaves the question of when we will see the changes made to fix this? Any idea of when the next release will happen? or any chances you make the patch available soon?

[michi]

We'll be doing another release week after next.

Cheers,

Michi.