Use of const arg in KConfigGroup constructors doesn't work with language bindings

Richard Dale rdale at foton.es
Wed Mar 5 08:22:43 GMT 2008


On Wednesday 05 March 2008 08:02:49 Lubos Lunak wrote:
> On Tuesday 04 of March 2008, Richard Dale wrote:
> > I've had a problem with these two pairs of constructors in
> > kconfiggroup.h:
> >
> >     KConfigGroup(KConfigBase *master, const QString &group);
> >     KConfigGroup(KConfigBase *master, const char *group);
> >
> >      KConfigGroup(const KConfigBase *master, const QString &group);
> >     KConfigGroup(const KConfigBase *master, const char *group);
> >
> > They only differ by the const-ness of the first argument, and this is
> > impossible to get working with any other language than c++. I would
> > prefer an enum to be passed, like KConfigBase::AccessType to specify
> > whether or not the KConfigGroup can be written too. I've worked round the
> > problem by just ignoring the read-only const method calls, and so
> > bindings will always get a writable KConfigGroup.
>
>  If that's the only way to get it working with the bindings, then that's
> probably the way you need to go.
Well are we designing the KDE api to be relatively language independent? 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? 

Maybe there can be more than two possible states and const/non-const doesn't 
map onto them.

> > I think something like this is clearer and less error prone:
> >
> >     KConfigGroup(KConfigBase *master, const QString &group, AccessType
> > mode = ReadOnly);
> >     KConfigGroup(KConfigBase *master, const char *group, AccessType mode
> > = ReadOnly);
>
>  No. In fact it is less clear and more error prone. Using 'const' is a
> normal C++ way and it lets the language to handle constness automatically.
> The code you posted will not work (compile) if the KConfigBase is already
> const and it forces the developer to do manually what the compiler can do
> on its own (and the compiler is not human, so unlike the developer it
> should not do mistakes :) ). It is rather common to overload methods in C++
> based on constness and I'm surprised this is the first time you've run into
> 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?). 

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 sense.

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.

-- Richard





More information about the kde-core-devel mailing list