readEntry and booleans

[Thomas Braxton]

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.

Thomas