[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: readEntry and booleans
From:       Olivier Goffart <ogoffart () kde ! org>
Date:       2006-01-04 10:54:30
Message-ID: 200601041154.38236.ogoffart () kde ! org
[Download RAW message or body]


Le Mercredi 4 Janvier 2006 12:04, André Wöbbeking a écrit :
> On Wednesday 04 January 2006 02:24, Thomas Braxton wrote:
> > On Tuesday 03 January 2006 16:59, David Faure wrote:
> > > On Tuesday 03 January 2006 23:00, Cornelius Schumacher wrote:
> > > > compare
> > > >   readEntry( "key", QVariant( false ) ).toBool()
> > > > to
> > > >   readBoolEntry( "key", false )
> > >
> > > Since booleans convert so badly to QVariant, maybe we should keep
> > > readBoolEntry or add a readEntry( key, bool ) overload?
> >
> > The problem wasn't with booleans, it was with zeroes. (i.e.
> > false/int(0)/uint(0))
> >
> > As far as I can tell this member template fixes everything
> > template <typename T> T readEntry(key, const T&) const
>
> What happens for readEntry("bla", 0) now? In this case we've to use
> int(0), double(0), and so on, right?

Or maybe  readEntry<double>("bla" , 0)

Note:  it seems that it mean that we will not be compatible with MSVC6 
(according to http://doc.trolltech.com/4.0/qvariant.html#value )
(Personally, I don't care)

> And two other things:
>
> 1) can we check if the QVariant is convertable (see
> qVariantCanConvert()) at least for debug code?


> 2) can we also get rid off readEntry(key, QString)?

This is AFAIK the base function



And can't we get ride of all theses double functions  QString/char* ?
Why don't we use simply QString ?
Or self class KConfigKey that has a constructor with char* and QString


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]