Apache OpenOffice (AOO) Bugzilla – Issue 15951
irritating warning patch ...
Last modified: 2003-07-24 10:56:30 UTC
This (apparently) bins a set of annoying compile-time warnings; the code compiles fine, it looks an obvious change; but it's not tested: Index: inc/st_list.hxx =================================================================== RCS file: /cvs/tools/soltools/inc/st_list.hxx,v retrieving revision 1.1 diff -u -p -u -r1.1 st_list.hxx --- inc/st_list.hxx 11 Jun 2001 16:05:17 -0000 1.1 +++ inc/st_list.hxx 23 Jun 2003 13:41:19 -0000 @@ -305,7 +305,7 @@ template <class XY> DynamicList<XY>::DynamicList( const DynamicList<XY> & i_rList ) : ST_List< XY* >(i_rList) { - for ( iterator it = begin(); + for ( typename DynamicList<XY>::iterator it = begin(); it != end(); ++it ) { @@ -324,7 +324,7 @@ template <class XY> DynamicList<XY> & DynamicList<XY>::operator=( const DynamicList<XY> & i_rList ) { - for ( const_iterator it = i_rList.begin(); + for ( typename DynamicList<XY>::const_iterator it = i_rList.begin(); it != i_rList.end(); ++it ) {
mh->np: please have a look.
There is no reason, I can see so far, for a compiler warning. The patch looks fine, but IMHO should be unnecessary. np->mmeeks Michael, it would be helpful, if you could add the exact wording of the warning to the comment, as well as the compiler used.
The warning spew is from recent gcc >= 3.X - on all the platforms gcc runs on. In file included from ../inc/gi_list.hxx:66, from /opt/OpenOffice/openoffice/build/HEAD_030620/soltools/giparser/gen_info.cxx:63: ../inc/st_list.hxx: In copy constructor `DynamicList<XY>::DynamicList(const DynamicList<XY>&)': ../inc/st_list.hxx:308: warning: `typename DynamicList<XY>::iterator' is implicitly a typename ../inc/st_list.hxx:308: warning: implicit typename is deprecated, please see the documentation for details ../inc/st_list.hxx: In member function `DynamicList<XY>& DynamicList<XY>::operator=(const DynamicList<XY>&)': ../inc/st_list.hxx:327: warning: `typename DynamicList<XY>::const_iterator' is implicitly a typename ../inc/st_list.hxx:327: warning: implicit typename is deprecated, please see the documentation for details if ( -e ../unxlngi4.pro/obj/gen_info.o) touch ../unxlngi4.pro/obj/gen_info.obj gcc is pretty keen on tracking the spec. so I'm guessing that this feature is indeed deprecated, and it'd be nice to update the code - aside from the fact that the fewer warnings gcc produces, the shorter / smaller the tinderbox logs - and the easier it is to spot real bugs :-) Thanks.
cmc->np: I believe Michael's patch is right. Append C Section 13.5 (Page 857) of Bjarne's C++ Programming Language goes into the details for needing it. Indeed the example there is exactly the same as the code in question here. "the typename keyword is required whenever a type name depends on a template parameter", here the type name DynamicList<XY>::iterator depends on the template parameter XY so needs a typename before it.
I still do not understand the need for it. The example in Bjarnes book (which cmc mentioned) is not the same as here. The difference: "iterator" is a member of the _current_ class (to be precise: of its base class). The question, if "iterator" is a type or something else, does not depend on a template parameter. Instead we are within the definition of the class, which in itself has the type "iterator" as a member. "iterator" is a local name in this class and as such should be known. On the other side, it might be possible, that there would be a specialisation of ST_List< XY* > for XY*, where "iterator" is no locally defined type. However, I am not sure, if the compiler is allowed to assume such a specialisation, if it is not there. But what would be the consequence: That would be, that in no template ever you could use locally defined types without "typename", even if you are just within the class, which defined the type, itself. For instance a signature like that of Foo() in template <class T> class Any { typedef int my_type; my_type Foo() const; }; had to be forbidden as well. Because the compiler does not warn about that, to me that looks inconsequent. However, to avoid the warning, we could apply the patch, which is absolutely correct. Regards, Nikolai
np->mmeeks: I put this to OOo 2.0 as this seems to be to me no showstopper for the 1.1 and the ooo11rc branch is just being finished.
My feeling is that this is really most valuable in the stable branch - particularly since it's a small (and obviously correct) change - since then the other warnings (some of which conceal serious bugs) are far more visible - and so we can catch bugs in the stable branch far more quickly. Oh - and then there is the aesthetic angle too :-) But as you like - I look forward to seeing it included. Thanks.
Ok, I fixed it on ooo11rc2.
verified.
closed.