gcc 3.4
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
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
0
Comments
Cheers,
Bernard
We've been having arguments about this here too. From the spec:
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:
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.
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/wg21/docs/cwg_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.
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?
Cheers,
Michi.