readEntry and booleans
brax108 at cox.net
Fri Jan 6 19:07:44 GMT 2006
On Friday 06 January 2006 04:39, David Faure wrote:
> Hmm; this is getting complex. I like the idea of compile-time checks of
> course, but I wonder if it's a good idea to duplicate the list of types
> that QVariant supports, since this is bound to become outdated. E.g. with
> Qt::GlobalColor in Qt-4.2 :)
The only types we would need to duplicate would be the sub-set of types that
we support reading/writing of, I guess the name is a little misleading. If
you look at readEntry there are plenty of types that QVariant supports that
we just default to not handling, so maybe a comment in readEntry/writeEntry
that if you add handling for a type you need to add it to the list of
supported types in conversion_check.hpp.
> Personally I was fine with the previous patch, given that as I said the app
> code will most probably pass the same type always, so developers will catch
> that anyway... What does QSettings do with unsupported QVariant types btw?
I'll have to look at QSettings, I don't know.
> > #define _IsUnused __attribute__ ((__unused__))
> This looks like it won't be portable to other compilers than gcc.
I was planning on changing this, I just copied this from libstdc++, I will
probably use Q_UNUSED which should be more portable.
> Whether the whole template thing compiles on with other compilers
> is an open question, but with an easy solution of course: we could
> set USE_CONCEPT_CHECK (strange name? why not, hmm, KCONFIG_QVARIANT_CHECK?)
> only with gcc.
It was late and I needed a name, KCONFIG_QVARIANT_CHECK works for me.
More information about the kde-core-devel