Use of const arg in KConfigGroup constructors doesn't work with language bindings
l.lunak at suse.cz
Wed Mar 5 12:36:27 GMT 2008
On Wednesday 05 of March 2008, Richard Dale wrote:
> Well are we designing the KDE api to be relatively language independent?
I guess that depends on what you mean with relatively. I don't think we
should intentionally break other languages, but then I don't think we should
intentionally break our libraries because of other languages either. To take
it to an extreme, since automatic invocation of destructors doesn't work with
any other language than C++, should we stop using that?
> If so there is no reason why we can't have extra method calls to cater for
> the languages without const overloading. The KConfig constructor takes a
> OpenFlags enum, and the KConfigBase takes an AccessType enum - so why isn't
> KConfigGroup consist with them. In fact what is the difference between the
> AccessType value in KConfigBase and bConst in KConfigGroup?
That's what Thiago suggests and that's different from what you wanted
originally. Thiago's proposal is fine, removing const is breaking it.
> I don't think it's the first time I come across it in KDE, but I'm pretty
> sure that the Qt lib doesn't do it anywhere (anyone know of any examples?).
Any operator, at least. But that probably doesn't map to other languages
> The method above is a constructor and 'master' is something like the parent
> of a QObject. When you construct a QObject I wouldn't expect it to be
> read-only or not according to whether the parent arg was const or not.
> Similarly the connection between whether or not master is const, and
> whether or not it follows that the child KConfigGroup is read-only is
> something that you would need implementation knowledge to know if it makes
> In the KConfigGroup a boolean bConst, is set in the constructor, and that
> is used afterwards to test whether the instance is read-only or not. It
> doesn't matter if you declare it 'const KConfigGroup * item' or
> 'KConfigGroup * item' - there is no use made of compile time checking.
You're mixing two things here. If KConfigGroup takes a const KConfigBase,
then that KConfigBase is not to be modified, simple as that. And it works two
ways, KConfigGroup taking const argument says that it won't be modified, and
somebody passing const KConfigBase says that it is not to be modified. The
compiler will do special handling to detect and enforce that and the fact
that KConfigGroup has a special flag for that is just an implementation
detail. KConfigGroup being read-only when it gets a const KConfigBase is just
a logical consequence of it not being possible to be read-write when the data
it operates on is const. I don't think anybody would expect QFile to be
read-only or read-write depending on whether the QString with the filename is
const or not.
SUSE LINUX, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http//www.suse.cz
More information about the kde-core-devel