Use of const arg in KConfigGroup constructors doesn't work with language bindings
rdale at foton.es
Wed Mar 5 21:56:54 GMT 2008
On Wednesday 05 March 2008 09:02:29 Thiago Macieira wrote:
> On Wednesday 05 March 2008 09:02:49 Lubos Lunak wrote:
> > 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'd say that we should have both things:
> KConfigGroup(KConfigBase *master, const QString &group, AccessType mode =
> KConfigGroup(const KConfigBase *master, const QString &group);
> i.e., the second form is enforced read-only, whereas the first can be
> selected. For instance, I could have a read-write KConfigBase * that I
> wanted to create a read-only form from. Casting it into const seems bizarre
> to me.
> In order to maintain binary compatibility, we can't have the first form,
> but we have to introduce a third with a non-default argument. And add a ###
> KDE 5 marker.
The attached patch add two extra constructors with a bool 'isConst' argument:
* This variant of the constructor is useful for non-c++ languages
* without const argument overloading.
* ### KDE 5 make isConst default to true
KConfigGroup(KConfigBase *master, const QString &group, bool isConst);
KConfigGroup(KConfigBase *master, const char *group, bool isConst);
Is it ok to commit this to the trunk?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1782 bytes
Desc: not available
More information about the kde-core-devel