home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c++
- Path: sparky!uunet!mcsun!sunic!lth.se!newsuser
- From: dag@control.lth.se (Dag Bruck)
- Subject: Re: Expanding enumerators in inheriting classes
- Message-ID: <1992Aug14.193046.6808@lth.se>
- Keywords: inheritance, enumerator
- Sender: newsuser@lth.se (LTH network news server)
- Organization: Department of Automatic Control, Lund, Sweden
- References: <1992Aug10.200814.12809@ntmtv> <1992Aug11.133926.28840@actrix.gen.nz> <1992Aug11.190816.8623@inmet.camb.inmet.com> <1992Aug12.192200.6873@ntmtv>
- Date: Fri, 14 Aug 1992 19:30:46 GMT
- Lines: 37
-
- In <comp.std.c++> hildum@ntmtv.UUCP (Eric Hildum) writes:
- >
- >... C++ already allows duplicate codes
-
- Yes, but the definitions are at least in one place, which makes the
- code easier to maintain. Never mind, I'm sure you are aware of the
- potential problems.
-
- I have implemented extensible enumerations with templates. I think
- the template sollution offers much of what you would like:
-
- - extensible set of enumerators
- - named enumerator symbols
- - type-safe, in the sense that an enumeration variable
- may only be assigned enumerators of the corresponding
- (possibly extended) enumeration
-
- However, there are problems:
-
- - the template version is MUCH less efficient, at least
- with current template implementations
- - these enumerators are not compile-time constants, so
- they cannot be used as case labels, for example
- - compiler must allocate storage for enumerators
- - the scope of the enumerator may not match the scope
- of the enumerated type, so garbage values may float
- around in the system
-
- It is possible to add additional logic to handle the last problem
- listed above, but it does cost a little in run-time performance.
-
- I did this excercise as part of the analysis of operator overloading
- of enumerations (a C++ standardization issue). I can post the actual
- code if there is enough interest; it's just two pages of code.
-
-
- -- Dag
-