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