Topic: String value of enum


Author: "W. Dicks" <wd@isis.co.za>
Date: 1996/03/13
Raw View
The system that I'm working often needs to know the string
value of an enum. e.g. enum week{MON=1, ..., SUN} it; it =
TUE;
Then when this enum is passed as a parameter the function
should return the string based on the enum. For instance,
weekImage(it) will return "TUE". Is it not possible that such
a functionality can be built into enums?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1996/03/14
Raw View
mtm4@rsvl.unisys.com (Michael McCormick) writes:

>"W. Dicks" <wd@isis.co.za> shared the following on 13 Mar 96 07:31:13 GMT:

>>The system that I'm working often needs to know the string
>>value of an enum. e.g. enum week{MON=1, ..., SUN} it; it =
>>TUE;
>>Then when this enum is passed as a parameter the function
>>should return the string based on the enum. For instance,
>>weekImage(it) will return "TUE". Is it not possible that such
>>a functionality can be built into enums?

>What you are essentially asking for is language support for converting
>a label into a string respresentation of its name.  That is a very
>unusual feature to find in any language, since it would require the
>compiler to place the symbolic dictionary in the executable file.

It would not in fact be difficult to do, since only a table of
strings per enum type would be needed. The information is normally
put into debug info if you compile in debug mode anyway so the
debugger can display the labels instead of the values. A language
mechanism to make that data always available is probably too
expensive a price for every program to pay in order to support
this requirement which isn't very common and which can be solved
easily in source code.


>Since enum is by definition an integral type, why not assign values to your
>enumerators that can be used as indexes into a string?:

> enum week {MON=0,TUE=4,WED=8,THU=12,FRI=16,SAT=20,SUN=24};
> const char * days = "MON\0TUE\0WED\0THU\0FRI\0SAT\0SUN";

> char const * weekImage(week day) = days[day];

I would suggest instead this approach, which does not require you
to count characters:
const char* days[] = {"MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN"};
It "wastes" 7 extra pointers, but is easier to write and maintain.

The more general case of non-contiguous enum values could be handled
by a table of value/string pairs and a lookup function. The standard
"map" class will do it all for you.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Max Welton <maxw@ix.netcom.com>
Date: 1996/03/14
Raw View
mtm4@rsvl.unisys.com (Michael McCormick) wrote:
>"W. Dicks" <wd@isis.co.za> shared the following on 13 Mar 96 07:31:13 GMT:
>
>>The system that I'm working often needs to know the string
>>value of an enum. e.g. enum week{MON=1, ..., SUN} it; it =
>>TUE;
>>Then when this enum is passed as a parameter the function
>>should return the string based on the enum. For instance,
>>weekImage(it) will return "TUE". Is it not possible that such
>>a functionality can be built into enums?
>
>What you are essentially asking for is language support for converting
>a label into a string respresentation of its name.  That is a very
>unusual feature to find in any language, since it would require the
>compiler to place the symbolic dictionary in the executable file.  I
>don't think there's a snowball's chance of this getting into C++.

It's not _that_ unusual. Ada has had this feature starting with
Ada-83 (the 'image attribute).

Actually, I've done the above in C++ by wrapping the enum of
interest in a class, placing a static array of const strings
in the implementation-file and providing an accessor member
function that simply indexes into the array and returns the
appropriate string (or a const char* to it, anyhow).
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Date: 1996/03/14
Raw View
mtm4@rsvl.unisys.com (Michael McCormick) writes:

>"W. Dicks" <wd@isis.co.za> shared the following on 13 Mar 96 07:31:13 GMT:
>
>>The system that I'm working often needs to know the string
>>value of an enum. [...] Is it not possible that such
>>a functionality can be built into enums?
>
>What you are essentially asking for is language support for converting
>a label into a string respresentation of its name.  That is a very
>unusual feature to find in any language, since it would require the
>compiler to place the symbolic dictionary in the executable file.
>I don't think there's a snowball's chance of this getting into C++.

I wouldn't call it "very unusual" -- there are many existing languages
which have similar features, including Haskell, Prolog, and Java -- not
to mention C++ itself!  If `x' is a polymorphic class variable, then
the C++ expression `typeid(x).name()' returns a string representation
of the class name.

>Since enum is by definition an integral type, why not assign values to your
>enumerators that can be used as indexes into a string?:
>
> enum week {MON=0,TUE=4,WED=8,THU=12,FRI=16,SAT=20,SUN=24};
> const char * days = "MON\0TUE\0WED\0THU\0FRI\0SAT\0SUN";
>
> char const * weekImage(week day) = days[day];

I think a much cleaner workaround would be to use an array of strings:

enum week {MON, TUE, WED, THU, FRI, SAT, SUN};
const char * days[] = { "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN" };
char const * weekImage(week day) { return days[day]; }

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: bill@amber.ssd.hcsc.com (Bill Leonard)
Date: 1996/03/14
Raw View
In article <4i8a38$2qq@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM
(Steve Clamage) writes:
> It would not in fact be difficult to do, since only a table of
> strings per enum type would be needed. The information is normally
> put into debug info if you compile in debug mode anyway so the
> debugger can display the labels instead of the values. A language
> mechanism to make that data always available is probably too
> expensive a price for every program to pay in order to support
> this requirement which isn't very common and which can be solved
> easily in source code.

Well, it is not that hard for the compiler to put out the tables only if
you use the feature, so there is no need for every program to pay a penalty
for this feature.

As for "solved easily in source code", it's not nearly as easy as just
saying something like "enumvar.String()". :-)

> The more general case of non-contiguous enum values could be handled
> by a table of value/string pairs and a lookup function. The standard
> "map" class will do it all for you.

But using the map class would require initialization at runtime, wouldn't
it?  That increases the startup cost of the program.  Using a sorted array
of value/string pairs (statically initialized) and a binary search would
probably be more efficient.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
There's something wrong with an industry in which amazement is a common
reaction to things going right.

"Hard work never scared me.  Oh, sure, it has startled me from a distance."
                                                       -- Professor Fishhawk
------------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1996/03/14
Raw View
In article <Do81tp.H9u@rsvl.unisys.com> mtm4@rsvl.unisys.com (Michael
McCormick) writes:

|> "W. Dicks" <wd@isis.co.za> shared the following on 13 Mar 96 07:31:13 GMT:

|> >The system that I'm working often needs to know the string
|> >value of an enum. e.g. enum week{MON=1, ..., SUN} it; it =
|> >TUE;
|> >Then when this enum is passed as a parameter the function
|> >should return the string based on the enum. For instance,
|> >weekImage(it) will return "TUE". Is it not possible that such
|> >a functionality can be built into enums?

|> What you are essentially asking for is language support for converting
|> a label into a string respresentation of its name.  That is a very
|> unusual feature to find in any language, since it would require the
|> compiler to place the symbolic dictionary in the executable file.  I
|> don't think there's a snowball's chance of this getting into C++.

Well, it is supported in other languages.  But I agree that it will not
be in C++, and should not be there, for an entirely different reason.
What happens to such strings when you change locale?  (In practice, they
are only good for debugging because of this.  And any decent debugger
will be able to display the information without the table in the
compiler.)

|> Since enum is by definition an integral type, why not assign values to your
|> enumerators that can be used as indexes into a string?:

|>  enum week {MON=0,TUE=4,WED=8,THU=12,FRI=16,SAT=20,SUN=24};
|>  const char * days = "MON\0TUE\0WED\0THU\0FRI\0SAT\0SUN";

|>  char const * weekImage(week day) = days[day];

Now this is going to be really fun to maintain.  What happens when the
program is prepared for internationalization, and the translater
modifies the strings?

Using:

 char const *const weekdayNames[] = { "Monday" , ... } ;

and indexing with the original enum is considerably better.  In fact, in
this one particular case, it is probably acceptable.  I cannot imagine
any conceivable change in specification which would cause the number of
days in a week to change.  This is a special case, however.

For the general case, I wrote a template class which manages a map, and
a small parser (just intelligent to extract the names from an enum, and
ignore everything else) to generate the initialization data for the map.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1996/03/15
Raw View
In article <4i9cn4$7cf@ns.hcsc.com> bill@amber.ssd.hcsc.com (Bill
Leonard) writes:

|> In article <4i8a38$2qq@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM
|> (Steve Clamage) writes:

|> > The more general case of non-contiguous enum values could be handled
|> > by a table of value/string pairs and a lookup function. The standard
|> > "map" class will do it all for you.

|> But using the map class would require initialization at runtime, wouldn't
|> it?  That increases the startup cost of the program.  Using a sorted array
|> of value/string pairs (statically initialized) and a binary search would
|> probably be more efficient.

At start-up, yes.  If the map is large enough for this to make a
difference, however, it's likely that the difference between the O(ln n)
binary search and a O(k) hash table look-up is also significant.

Given that the enum labels are all in the source code, and programmers
being on the whole a lazy group of people, the resulting tables are
typically so small that it really doesn't make a difference, especially
since anytime that the conversion is necessary, output will follow.
(I'm still using a linear search in my implementation, and it has yet to
cause a performance bottleneck.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Russell Gold <goldr@inet.bis.adp.com>
Date: 1996/03/16
Raw View
Max Welton wrote:
>
> mtm4@rsvl.unisys.com (Michael McCormick) wrote:
> >"W. Dicks" <wd@isis.co.za> shared the following on 13 Mar 96 07:31:13 GMT:
> >
> >>The system that I'm working often needs to know the string
> >>value of an enum. e.g. enum week{MON=1, ..., SUN} it; it =
> >>TUE;
> >>Then when this enum is passed as a parameter the function
> >>should return the string based on the enum. For instance,
> >>weekImage(it) will return "TUE". Is it not possible that such
> >>a functionality can be built into enums?
> >
> >What you are essentially asking for is language support for converting
> >a label into a string respresentation of its name.  That is a very
> >unusual feature to find in any language, since it would require the
> >compiler to place the symbolic dictionary in the executable file.  I
> >don't think there's a snowball's chance of this getting into C++.
>
> It's not _that_ unusual. Ada has had this feature starting with
> Ada-83 (the 'image attribute).

Very true; however, Ada also gurantees some things about scalar
values that do not apply to C++ enums:
1. You can determine the order of a scalar value in its sequence
2. AFAIK, no two members of the same scalar type can have the same
   underlying representation.

As a result, Ada lets you use a scalar type as an array index,
and compute the successor / predecessor from a given value. In
C++, you cannot do this.  For example:

  enum Code { ready=0, idle = 0, run, halt };

  const char *image( Code value );

how would you handle:
   cout << image( (Code) 0 );


Now if we wanted to guarantee the properties of uniqueness in value
and sequence in C++, we could do all of these other things, as well.
--
Russell Gold         | (609) 727-2219
ADP, Inc.            | goldr@bis.adp.com
201 E. Park Dr.      | russgold@ACM.org
Mt. Laurel, NJ 08054 | russgold@aol.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: bill@amber.ssd.hcsc.com (Bill Leonard)
Date: 1996/03/16
Raw View
In article <KANZE.96Mar15151356@gabi.gabi-soft.fr>, kanze@gabi-soft.fr
(J. Kanze) writes:

> At start-up, yes.  If the map is large enough for this to make a
> difference, however, it's likely that the difference between the O(ln n)
> binary search and a O(k) hash table look-up is also significant.

I wasn't thinking of a large table, I was thinking of lots of small ones.

> Given that the enum labels are all in the source code, and programmers
> being on the whole a lazy group of people, the resulting tables are
> typically so small that it really doesn't make a difference, especially
> since anytime that the conversion is necessary, output will follow.

I agree that the performance of the conversion itself is not an issue.
However, startup cost might be if you have lots of these tables in an
application whose execution is normally of very short duration.  Adding 100
milliseconds, say, to an application that only executes for a few hundred
milliseconds anyway is a big penalty.

My point is simply that static initialization is better, I think.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
There's something wrong with an industry in which amazement is a common
reaction to things going right.

"Hard work never scared me.  Oh, sure, it has startled me from a distance."
                                                       -- Professor Fishhawk
------------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]