Hi Masaharu, I'm rather suprised by this problem of CINT. In order to solve the problem of non-declared-const members of members which should be const, I often exactly define them twice. For example I want the Print member which I inherit from TObject to be const. So I have both: virtual void Print(Option_t *option = ""); virtual void Print(Option_t *option = "") const; Where the first simply calls the second. I didn't notice any problems with this. As you don't advice to do so, what kind of problems would you expect? Cheers, Rutger p.s. Now that I think of it, this might explain the problem I report in bug report 542. Is that indeed the cause? On Mon, 17 Jan 2000, Masaharu Goto wrote: > Hello Root users, > > I'd like to comment about constness from cint's concern. This message > does not answer the original question directly, but has some relationship. > > By default, cint does not distinguish const and non-const member function. > If you have both const and non-const version, you have to mask const > version for makecint. > > class A { > public: > A& f(); > #if (!defined(__MAKECINT__) || defined(G__CONSTNESSFLAG)) > const A& f() const; > #endif > }; > > In cint5.14.28 which will be exposed shortly, if you compile cint > with G__CONSTNESSFLAG macro in G__ci.h or platform dependency file, > const and non-const member function will be distinguished. > > However, it is not recommended to activate this feature at this moment > because of following problems. > - shared library binary compatibility will be lost > - problems in using/compiling STL container classes > > > For the time being, please have different function name for const and > non-const version. > > Thank you > Masaharu Goto > > > > >Hi, > > > >This reminds me of a long standing isue on const declarations of as well > >member functions as their arguments. As known and ppl reported before > >(see e.g. roottalk98/1491.html) a lot of classes miss const-declararions > >at several places where they should/could be placed. The reason for this > >is (probably) mainly historical. Begin last year (1999), or was it even > >1998 Rene and Fons did already some cleanup on this, however still a lot > >remains. Is there any plan to do a major cleanup on this? > > > >This has of course effect on existing (user) code, which might be broken. > >However if it is not corrected it also results in more 'incorrect' code > >being written (I e.g. quite often have to force a const_cast to be able to > >call a incorrectly non const member of a root class.) Therefore it is > >probably something which should happen in a major new release (V3.?). > > > >This whole thing is ofcourse not essential. So maybe I'm the only one > >bothered by this. If not, I would like to (re)start a discussion on how > >and when to improve the root classes on const-declarations. > > > >Cheers, Rutger > > > > >
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:17 MET