enum's & KConfigBase

Thomas Braxton brax108 at cox.net
Mon Jan 16 23:58:34 GMT 2006

On Monday 16 January 2006 17:40, Stefan Teleman wrote:
> On Monday 16 January 2006 17:41, Dirk Mueller wrote:
> > I'm not so sure if its a good idea to convert enums to integers and back.
> > enum's tend to be reordered within applications, which break binary
> > compatibility (not a problem usually for inner-apps usage) but then also
> > breaks configuration reading. This is a major problem. KDE applications
> > break already way too often their own configuration (I cannot remember
> > how often already I had to redo the very same settings in e.g.
> > konversation because the way the configuration key was stored was changed
> > *yet another* time). We shouldn't make it too easy to keep that nasty
> > habit.
> Not to mention the fact that in C++ the sign-ness and the underlying type
> used to represent an enum type are implementation-defined, therefore the
> conversion to a signed integer creates a big portability problem right from
> the start. It is common to have enums implemented as bitfields.
> ISO/IEC:14882:2003.7.2.5
> The underlying type of an enumeration is an integral type that can
> represent all the enumerator values defined in the enumeration. It is
> implementation-defined which integral type is used as the underlying type
> for an enumeration except that the underlying type shall not be larger than
> [int] unless the value of an enumerator cannot fit in an [int] or [unsigned
> int]. [ ... ] The value of sizeof() applied to an enumeration type, an
> object of enumeration type, or an enumerator, is the value of sizeof()
> applied to the underlying type.
> ISO/IEC:14882:2003.7.2.6
> For an enumeration when E<min> is the smallest enumerator and E<max> is the
> largest, the values of the enumeration are the values of the underlying
> type in the range B<min> to B<max>, where B<min> and B<max> are,
> respectively, the smallest and largest values of the smallest bit-field
> that can store E<min> and E<max>.
> --Stefan
True, but how many enums that are used in KDE would this really matter for? If 
you had an enum that needed special handling you would just have to write 
your own implementation of readEntry/writeEntry for that enum. most enums in 
KDE that I've seen so far are more than compensated for with an int, besides 
we aren't talking about the binary representation of an enum, it's about the 
way it is saved as text in a config file.


More information about the kde-core-devel mailing list