Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #69953 > unrolled thread

Can "enum" be forced to a certain "bitness"?

Back to article view | Back to comp.lang.c

Contents

  Can "enum" be forced to a certain "bitness"? Ken Brody <kenbrody@spamcop.net> - 2015-09-08 15:07 -0400
    Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-08 20:17 +0100
      Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 12:36 -0700
        Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-08 22:52 +0100
        Re: Can "enum" be forced to a certain "bitness"? Ken Brody <kenbrody@spamcop.net> - 2015-09-09 11:40 -0400
      Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 14:57 -0700
        Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-08 23:10 +0100
          Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 15:15 -0700
            Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-09 10:35 +1200
              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 11:07 +0200
                Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-09 12:36 +0100
                  Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:46 +0200
                    Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-11 11:32 +1200
                      Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-10 17:39 -0700
                        Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 09:03 +0200
                          Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-11 11:33 -0700
                        Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-11 21:24 +1200
                          Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 11:38 +0200
                            Re: Can "enum" be forced to a certain "bitness"? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-11 10:40 +0100
                              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 12:51 +0200
                                Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-11 12:21 -0500
                            Re: Can "enum" be forced to a certain "bitness"? supercat@casperkitty.com - 2015-09-11 15:03 -0700
                              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-12 15:01 +0200
                      Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-11 09:23 +0200
                  Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-10 10:06 +0200
                  Re: Can "enum" be forced to a certain "bitness"? David Kleinecke <dkleinecke@gmail.com> - 2015-09-15 17:55 -0700
          Re: Can "enum" be forced to a certain "bitness"? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-08 18:36 -0400
            Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 16:14 -0700
              Re: Can "enum" be forced to a certain "bitness"? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-08 19:49 -0400
                Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 17:20 -0700
          Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 15:48 -0700
            Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:03 -0700
              Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-09 11:16 +1200
                Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:18 -0700
                  Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:19 -0700
                    Re: Can "enum" be forced to a certain "bitness"? Ian Collins <ian-news@hotmail.com> - 2015-09-09 11:42 +1200
                      Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 00:52 +0100
                        Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:28 +0200
                          Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 10:56 -0700
                            Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 22:17 +0200
                      Re: Can "enum" be forced to a certain "bitness"? Philip Lantz <prl@canterey.us> - 2015-09-08 22:06 -0700
                        Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-08 23:14 -0700
          Re: Can "enum" be forced to a certain "bitness"? supercat@casperkitty.com - 2015-09-09 16:10 -0700
        Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 00:42 +0100
          Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 16:55 -0700
            Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 01:31 +0100
              Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 17:51 -0700
        Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-08 22:53 -0500
          Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-09 10:00 +0100
            Re: Can "enum" be forced to a certain "bitness"? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 11:27 +0100
              Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:31 +0200
              Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-09 18:32 -0500
                Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 17:15 -0700
            Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-09 18:29 -0500
              Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 17:10 -0700
                Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-09 22:27 -0500
                  Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-09 21:09 -0700
                    Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-10 01:54 -0500
                      Re: Can "enum" be forced to a certain "bitness"? Keith Thompson <kst-u@mib.org> - 2015-09-10 10:57 -0700
                  Re: Can "enum" be forced to a certain "bitness"? James Kuyper <jameskuyper@verizon.net> - 2015-09-10 00:21 -0400
                    Re: Can "enum" be forced to a certain "bitness"? Les Cargill <lcargill99@comcast.com> - 2015-09-10 02:00 -0500
                      Re: Can "enum" be forced to a certain "bitness"? James Kuyper <jameskuyper@verizon.net> - 2015-09-10 09:32 -0400
        Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-09 08:19 -0700
          Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-09 08:43 -0700
          Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 13:05 -0700
            Re: Can "enum" be forced to a certain "bitness"? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 13:10 -0700
              Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 00:47 -0700
                Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 01:05 -0700
                  Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 02:04 -0700
                  Re: Can "enum" be forced to a certain "bitness"? Bartc <bc@freeuk.com> - 2015-09-10 10:30 +0100
                    Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 06:33 -0700
                      Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 06:43 -0700
                        Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-15 15:22 -0700
                Re: Can "enum" be forced to a certain "bitness"? fir <profesor.fir@gmail.com> - 2015-09-10 01:35 -0700
    Re: Can "enum" be forced to a certain "bitness"? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-08 15:38 -0400
      Re: Can "enum" be forced to a certain "bitness"? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-09 10:52 -0700
        Re: Can "enum" be forced to a certain "bitness"? David Thompson <dave.thompson2@verizon.net> - 2015-09-20 18:35 -0400
          Re: Can "enum" be forced to a certain "bitness"? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:30 -0700
          Re: Can "enum" be forced to a certain "bitness"? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:51 -0700
    Re: Can "enum" be forced to a certain "bitness"? James Kuyper <jameskuyper@verizon.net> - 2015-09-08 15:50 -0400
    Re: Can "enum" be forced to a certain "bitness"? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-08 20:25 +0000
    Re: Can "enum" be forced to a certain "bitness"? David Brown <david.brown@hesbynett.no> - 2015-09-08 23:09 +0200

Page 1 of 5  [1] 2 3 4 5  Next page →

#69953 — Can "enum" be forced to a certain "bitness"?

Can an enum be forced to a certain "bitness"?

For example, can I force an enum to be "int16_t"?

In this case, I would like to use an enum, rather than an integer type, in a 
struct of data that gets written to disk.  (Please, let's not argue the pros 
and cons of such a thing.)

For example:

     enum blockType
         {
         blockType_NONE = 0,
         blockType_ONE = 1,
         blockType_TWO = 2
         };
     struct writtenToDisk
         {
         enum blockType type; /* Force this to be int16_t type */
         ...
         };

rather than:

     typedef int16_t blockType;
     #define blockType_NONE 0
     #define blockType_ONE  1
     #define blockType_TWO  2
     struct writtenToDisk
         {
         blockType type;
         ...
         };

-- 
Kenneth Brody

[toc] | [next] | [standalone]

#69955

Ken Brody <kenbrody@spamcop.net> writes:

> Can an enum be forced to a certain "bitness"?
>
> For example, can I force an enum to be "int16_t"?

No.

> In this case, I would like to use an enum, rather than an integer
> type, in a struct of data that gets written to disk.  (Please, let's
> not argue the pros and cons of such a thing.)
>
> For example:
>
>     enum blockType
>         {
>         blockType_NONE = 0,
>         blockType_ONE = 1,
>         blockType_TWO = 2
>         };
>     struct writtenToDisk
>         {
>         enum blockType type; /* Force this to be int16_t type */
>         ...
>         };
>
> rather than:
>
>     typedef int16_t blockType;
>     #define blockType_NONE 0
>     #define blockType_ONE  1
>     #define blockType_TWO  2
>     struct writtenToDisk
>         {
>         blockType type;
>         ...
>         };

You can combine these: use the size you want in the struct, but the enum
for the constants.  You don't lose much.  Unlike C++, C is so casual
about enums that using an object declared to have an enum type is almost
pointless.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#69961

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Ken Brody <kenbrody@spamcop.net> writes:
>> Can an enum be forced to a certain "bitness"?
>>
>> For example, can I force an enum to be "int16_t"?
>
> No.
>
>> In this case, I would like to use an enum, rather than an integer
>> type, in a struct of data that gets written to disk.  (Please, let's
>> not argue the pros and cons of such a thing.)
>>
>> For example:
[snip]
> You can combine these: use the size you want in the struct, but the enum
> for the constants.  You don't lose much.  Unlike C++, C is so casual
> about enums that using an object declared to have an enum type is almost
> pointless.

In fact enum constants are of type int, not of the enum type.

But I wouldn't go so far as to say that defining objects to have an enum
type is pointless.  It at least documents to any reader that it's
*intended* to hold one of the specified values, even though that's not
enforced.

C++ has different rules, and in recent versions has extended its enum
type facility to let you specify the underlying type.  I don't remember
the details, but if C-style enums don't meet your requirements you might
consider looking at what C++ offers.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#69980

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Ken Brody <kenbrody@spamcop.net> writes:
>>> Can an enum be forced to a certain "bitness"?
>>>
>>> For example, can I force an enum to be "int16_t"?
>>
>> No.
>>
>>> In this case, I would like to use an enum, rather than an integer
>>> type, in a struct of data that gets written to disk.  (Please, let's
>>> not argue the pros and cons of such a thing.)
>>>
>>> For example:
> [snip]
>> You can combine these: use the size you want in the struct, but the enum
>> for the constants.  You don't lose much.  Unlike C++, C is so casual
>> about enums that using an object declared to have an enum type is almost
>> pointless.
>
> In fact enum constants are of type int, not of the enum type.

Yes, that's largely why what I said it true.  Because they are ints C
does not help you avoid using a constant from one enum where another is
intended (or any of the other helping hands that some languages can give
you with enumerations).

> But I wouldn't go so far as to say that defining objects to have an enum
> type is pointless.  It at least documents to any reader that it's
> *intended* to hold one of the specified values, even though that's not
> enforced.

Yes.  That's the "almost" part!

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#70049

On 9/8/2015 3:36 PM, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Ken Brody <kenbrody@spamcop.net> writes:
>>> Can an enum be forced to a certain "bitness"?
>>>
>>> For example, can I force an enum to be "int16_t"?
>>
>> No.
>>
>>> In this case, I would like to use an enum, rather than an integer
>>> type, in a struct of data that gets written to disk.  (Please, let's
>>> not argue the pros and cons of such a thing.)
>>>
>>> For example:
> [snip]
>> You can combine these: use the size you want in the struct, but the enum
>> for the constants.  You don't lose much.  Unlike C++, C is so casual
>> about enums that using an object declared to have an enum type is almost
>> pointless.
>
> In fact enum constants are of type int, not of the enum type.
>
> But I wouldn't go so far as to say that defining objects to have an enum
> type is pointless.  It at least documents to any reader that it's
> *intended* to hold one of the specified values, even though that's not
> enforced.
[...]

Thanks.  I may just do that.

Note, that, in some debuggers, enums will show the symbolic value rather 
than the integer value, so "print foo" might show "myEnumTypeThree" rather 
than "3".

But, since what I was hoping to do can't be done (which explains why I 
couldn't come up with a solution), I'll just continue using the typedef'ed 
code, perhaps along with the enum.

So:

     myEnumType blockType = myStruct.type;

and I'm good to go.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#69981

On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
> Ken Brody <kenbrody@spamcop.net> writes:
> > Can an enum be forced to a certain "bitness"?
> > For example, can I force an enum to be "int16_t"?
> 
> No.

This is a fundamental flaw in the language.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#69983

On 08/09/2015 22:57, Rick C. Hodgin wrote:
> On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
>> Ken Brody <kenbrody@spamcop.net> writes:
>>> Can an enum be forced to a certain "bitness"?
>>> For example, can I force an enum to be "int16_t"?
>>
>> No.
>
> This is a fundamental flaw in the language.

I don't agree.

Take:

  enum (red,green,blue,yellow);

That's just a way of writing:

   #define red 0
   #define green 1
   etc

What type is 0 or 1? Isn't it 'int' just like the enum?

So an enum is just a bunch of named values; it's not really a 'storage' 
type where you need to specify a narrow int or char type or even a 2-bit 
field. That can be specified separately if it's important.

You might want extra type protection, but that would need a massive 
change to the language (and turn it into C++ or Ada).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#69985

On Tuesday, September 8, 2015 at 6:11:11 PM UTC-4, Bart wrote:
> On 08/09/2015 22:57, Rick C. Hodgin wrote:
> > On Tuesday, September 8, 2015 at 3:17:41 PM UTC-4, Ben Bacarisse wrote:
> >> Ken Brody <kenbrody@spamcop.net> writes:
> >>> Can an enum be forced to a certain "bitness"?
> >>> For example, can I force an enum to be "int16_t"?
> >>
> >> No.
> >
> > This is a fundamental flaw in the language.
> 
> I don't agree.
> 
> Take:
> 
>   enum (red,green,blue,yellow);
> 
> That's just a way of writing:
> 
>    #define red 0
>    #define green 1
>    etc
> 
> What type is 0 or 1? Isn't it 'int' just like the enum?

No.  It physically writes out source code to compile, making the
contextual use of each "red" or "green" converted for the compiler
into its define value, meaning if it's used where there's a char,
it will be char, and if it's used where there's a uint64_t, it
will be uint64_t, etc.

> So an enum is just a bunch of named values; it's not really a 'storage' 
> type where you need to specify a narrow int or char type or even a 2-bit 
> field. That can be specified separately if it's important.

Enums should be a bunch of named values.  They aren't.  They relate
back to an explicitly sized type in C, an int.  It shouldn't be like
that, which is why I say it's a fundamental flaw in the language.

> You might want extra type protection, but that would need a massive 
> change to the language (and turn it into C++ or Ada).

I think you could use enums to populate a field of type uint16_t and
it would populate properly, but I think internally (pre-code-generation)
the compiler would probably issue a cast, which is then removed by the
optimizer because it's realized that the enum value is really just a
constant after all.  I could be wrong about that, but it wouldn't
surprise me to learn it is that way.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#69987

Rick C. Hodgin wrote:
> On Tuesday, September 8, 2015 at 6:11:11 PM UTC-4, Bart wrote:
>
>> You might want extra type protection, but that would need a massive
>> change to the language (and turn it into C++ or Ada).
>
> I think you could use enums to populate a field of type uint16_t and
> it would populate properly, but I think internally (pre-code-generation)
> the compiler would probably issue a cast, which is then removed by the
> optimizer because it's realized that the enum value is really just a
> constant after all.  I could be wrong about that, but it wouldn't
> surprise me to learn it is that way.

Bart is correct.  If you want type safe and fixed size enums, use C++. 
C enums are something of a wasted opportunity.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#70029

On 09/09/15 00:35, Ian Collins wrote:
> Rick C. Hodgin wrote:
>> On Tuesday, September 8, 2015 at 6:11:11 PM UTC-4, Bart wrote:
>>
>>> You might want extra type protection, but that would need a massive
>>> change to the language (and turn it into C++ or Ada).
>>
>> I think you could use enums to populate a field of type uint16_t and
>> it would populate properly, but I think internally (pre-code-generation)
>> the compiler would probably issue a cast, which is then removed by the
>> optimizer because it's realized that the enum value is really just a
>> constant after all.  I could be wrong about that, but it wouldn't
>> surprise me to learn it is that way.
> 
> Bart is correct.  If you want type safe and fixed size enums, use C++. C
> enums are something of a wasted opportunity.
> 

As Bart says, C enums are not much different from a series of #define
statements.  But they have a few not insignificant advantages over using
#define's:

They let you write neater and more compact enumerations than a series of
defines.  You don't need to give each element a number manually.

They express your intent far better, and thus document the code when you
define the type and use it (even if the compiler can't help enforce this
intent).

As they are not pre-processor macros, they are a little safer in use.
And it is likely that an editor/IDE can help with them (syntax
highlighting, auto-completion, etc.), and debuggers can show values of
an enumerated type by name.

Tools such as documentation tools (doxygen), compilers with static
warning analysis (gcc -Wswitch), other static analysis tools (pclint,
etc.) can all make better use of enum types than #define'd constants.


So they are not a /completely/ wasted opportunity, even though the
compiler itself makes little use of them.

As you say, C++ gives you more type safety and control with "enum class"
types.  But that too is full of wasted opportunity - they should have
supported Ada-style attributes for first, last, successor, predecessor,
iterators, conversion to and from integer (but not implicit conversion),
and they should be usable as the index for arrays.  All things are
possible in C++ with enough templates, of course, but this should have
been part of the "enum class" language feature - or at the very least,
the templates to make it all work should have been standardised.

[toc] | [prev] | [next] | [standalone]

#70039

On 09/09/2015 10:07, David Brown wrote:
> On 09/09/15 00:35, Ian Collins wrote:

>> If you want type safe and fixed size enums, use C++. C
>> enums are something of a wasted opportunity.

> So they are not a /completely/ wasted opportunity, even though the
> compiler itself makes little use of them.
>
> As you say, C++ gives you more type safety and control with "enum class"
> types.  But that too is full of wasted opportunity - they should have
> supported Ada-style attributes for first, last, successor, predecessor,
> iterators, conversion to and from integer (but not implicit conversion),
> and they should be usable as the index for arrays.

You mean, having arrays that can only be indexed by a particular enum 
type? That would be very Ada-ish.

But in C (and in C++ AFAIK), enums are not necessarily sequential. In 
fact, a set of enums can have arbitrary values, or can all have the same 
value! That would give with problems with features such as successor and 
predecessor functions, or even just turn an enum instance value into the 
same of the value.

Although I suspect that more sophisticated uses of enums will come with 
restrictions.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#70040

On 09/09/15 13:36, Bartc wrote:
> On 09/09/2015 10:07, David Brown wrote:
>> On 09/09/15 00:35, Ian Collins wrote:
> 
>>> If you want type safe and fixed size enums, use C++. C
>>> enums are something of a wasted opportunity.
> 
>> So they are not a /completely/ wasted opportunity, even though the
>> compiler itself makes little use of them.
>>
>> As you say, C++ gives you more type safety and control with "enum class"
>> types.  But that too is full of wasted opportunity - they should have
>> supported Ada-style attributes for first, last, successor, predecessor,
>> iterators, conversion to and from integer (but not implicit conversion),
>> and they should be usable as the index for arrays.
> 
> You mean, having arrays that can only be indexed by a particular enum
> type? That would be very Ada-ish.
> 

Yes, like having:

typedef enum { black, red, green, blue, white } colours;
typedef struct { uint8_t R; uint8_t G; uint8_t B } rgb;
static const rgb rgbs[colours] = {
	{ 0, 0, 0 }, { 255, 0, 0 }, ...
}

void foo(colours c) {
	set_rgb(rgbs[c]);
}

I would also like to be able to write "last(colours)" rather than having
to put an artificial entry "last_colour" into the colours enum (or
making it as a separate declaration).

> But in C (and in C++ AFAIK), enums are not necessarily sequential. In
> fact, a set of enums can have arbitrary values, or can all have the same
> value! That would give with problems with features such as successor and
> predecessor functions, or even just turn an enum instance value into the
> same of the value.
> 
> Although I suspect that more sophisticated uses of enums will come with
> restrictions.
> 

Exactly.  It would be perfectly reasonable to limit such advanced enum
use to sequential enums.  Indeed, for many uses of non-sequential enums
(such as names for bitmasks), C++'s "enum class" would not be suitable
as you don't have direct access to the underlying number.  I don't think
it would have been a big loss if "enum class" had been defined as always
being sequential, starting from 0 - non-sequential enum uses could have
used old-style "enum".

[toc] | [prev] | [next] | [standalone]

#70199

David Brown wrote:
> On 09/09/15 13:36, Bartc wrote:
>>
>> You mean, having arrays that can only be indexed by a particular enum
>> type? That would be very Ada-ish.
>>
>
> Yes, like having:
>
> typedef enum { black, red, green, blue, white } colours;
> typedef struct { uint8_t R; uint8_t G; uint8_t B } rgb;
> static const rgb rgbs[colours] = {
> 	{ 0, 0, 0 }, { 255, 0, 0 }, ...
> }
>
> void foo(colours c) {
> 	set_rgb(rgbs[c]);
> }
>
> I would also like to be able to write "last(colours)" rather than having
> to put an artificial entry "last_colour" into the colours enum (or
> making it as a separate declaration).

The reflections proposals for C++ go a long way to implementing these, 
see N4428.

>> But in C (and in C++ AFAIK), enums are not necessarily sequential. In
>> fact, a set of enums can have arbitrary values, or can all have the same
>> value! That would give with problems with features such as successor and
>> predecessor functions, or even just turn an enum instance value into the
>> same of the value.
>>
>> Although I suspect that more sophisticated uses of enums will come with
>> restrictions.
>>
>
> Exactly.  It would be perfectly reasonable to limit such advanced enum
> use to sequential enums.  Indeed, for many uses of non-sequential enums
> (such as names for bitmasks), C++'s "enum class" would not be suitable
> as you don't have direct access to the underlying number.  I don't think
> it would have been a big loss if "enum class" had been defined as always
> being sequential, starting from 0 - non-sequential enum uses could have
> used old-style "enum".

There is a middle ground that I have already used in embedded C++, typed 
enums (not full blown enum class) such as

enum State : uint16_t { on = 0x001, off = 0x002 };

which allows conversion to the base type

   uint16_t u = State::on;

I don't see why this, being a new syntax, couldn't be adopted in C or 
included as an extension for embedded compilers.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#70202

Ian Collins <ian-news@hotmail.com> writes:
[...]
> There is a middle ground that I have already used in embedded C++, typed 
> enums (not full blown enum class) such as
>
> enum State : uint16_t { on = 0x001, off = 0x002 };
>
> which allows conversion to the base type
>
>    uint16_t u = State::on;
>
> I don't see why this, being a new syntax, couldn't be adopted in C or 
> included as an extension for embedded compilers.

That seems reasonable -- though I wouldn't expect C to adopt the "::"
syntax.

If I understand this correctly, enum State would be compatible with
uint16_t, and the constants on and off would be either of type enum
State or of type uint16_t (it probably doesn't matter which).

It would also let you define named constants of any integer type:

    enum : uint32_t { foo = 0xdeadbeef };

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#70212

On 11/09/15 02:39, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> [...]
>> There is a middle ground that I have already used in embedded C++, typed 
>> enums (not full blown enum class) such as
>>
>> enum State : uint16_t { on = 0x001, off = 0x002 };
>>
>> which allows conversion to the base type
>>
>>    uint16_t u = State::on;
>>
>> I don't see why this, being a new syntax, couldn't be adopted in C or 
>> included as an extension for embedded compilers.
> 
> That seems reasonable -- though I wouldn't expect C to adopt the "::"
> syntax.
> 
> If I understand this correctly, enum State would be compatible with
> uint16_t, and the constants on and off would be either of type enum
> State or of type uint16_t (it probably doesn't matter which).
> 
> It would also let you define named constants of any integer type:
> 
>     enum : uint32_t { foo = 0xdeadbeef };
> 

C++ has that already, to a fair extent - "const uint32_t foo =
0xdeadbeef" makes a named constant that is usable in more places than a
similar constant in C.  You can use it for an array size, for example,
unlike C.  I don't think you can use it as a switch label - but
typically enum constants are more natural for that anyway.

[toc] | [prev] | [next] | [standalone]

#70265

David Brown <david.brown@hesbynett.no> writes:
> On 11/09/15 02:39, Keith Thompson wrote:
[...]
>> It would also let you define named constants of any integer type:
>> 
>>     enum : uint32_t { foo = 0xdeadbeef };
>> 
>
> C++ has that already, to a fair extent - "const uint32_t foo =
> 0xdeadbeef" makes a named constant that is usable in more places than a
> similar constant in C.  You can use it for an array size, for example,
> unlike C.  I don't think you can use it as a switch label - but
> typically enum constants are more natural for that anyway.

Yes, you can use it for a switch label.  Given:

    const uint32_t foo = 0xdeadbeef;

in C++ foo is a constant expression usable anywhere the literal value
0xdeadbeef can be used (the difference being that it's of type
uint32_t).

You're right, if C adopted C++-style const rules, enhanced enum types
(that let you specify the underlying integer type) would not be needed
as a way to define constants of arbitrary integer types.  Or vice versa.

I wouldn't mind having both.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#70223

Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> [...]
>> There is a middle ground that I have already used in embedded C++, typed
>> enums (not full blown enum class) such as
>>
>> enum State : uint16_t { on = 0x001, off = 0x002 };
>>
>> which allows conversion to the base type
>>
>>     uint16_t u = State::on;
>>
>> I don't see why this, being a new syntax, couldn't be adopted in C or
>> included as an extension for embedded compilers.
>
> That seems reasonable -- though I wouldn't expect C to adopt the "::"
> syntax.

In this context, the scoping isn't required.  Just force of habit on my 
part.  It is required for an enum class.

> If I understand this correctly, enum State would be compatible with
> uint16_t, and the constants on and off would be either of type enum
> State or of type uint16_t (it probably doesn't matter which).
>
> It would also let you define named constants of any integer type:
>
>      enum : uint32_t { foo = 0xdeadbeef };
>

Yes, but as David pointed out this is unnecessary given the sensible 
const rules in C++!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#70227

On 11/09/15 11:24, Ian Collins wrote:

> 
> Yes, but as David pointed out this is unnecessary given the sensible
> const rules in C++!
> 

Let's call the const rules in C++ "less bad", rather than "sensible".

I gather that the original keyword was "readonly", which I think would
have been better.  But when we have "const" to mean something is
constant and doesn't change, then "mutable" to mean that it might change
after all, then "constexpr" to mean that this time we /really/ mean it
won't change - it's hard to summarise the situation as "sensible" !

Still, simple "const int" expressions are more useful in C++ than in C.
 In C, the rules say that changing the value of the const would be
undefined behaviour - yet the compiler can't use that fact to let you
use the value as a compile-time constant for array sizes.

[toc] | [prev] | [next] | [standalone]

#70228

On 11/09/2015 10:38, David Brown wrote:
> On 11/09/15 11:24, Ian Collins wrote:
>
>>
>>  Yes, but as David pointed out this is unnecessary given the sensible
>>  const rules in C++!
>>
>
> Let's call the const rules in C++ "less bad", rather than "sensible".
>
> I gather that the original keyword was "readonly", which I think would
> have been better.  But when we have "const" to mean something is
> constant and doesn't change, then "mutable" to mean that it might change
> after all, then "constexpr" to mean that this time we /really/ mean it
> won't change - it's hard to summarise the situation as "sensible" !

That's the trouble with programming languages - constants aren't, 
variables don't, and functions won't.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#70232

On 11/09/15 11:40, Richard Heathfield wrote:
> On 11/09/2015 10:38, David Brown wrote:
>> On 11/09/15 11:24, Ian Collins wrote:
>>
>>>
>>>  Yes, but as David pointed out this is unnecessary given the sensible
>>>  const rules in C++!
>>>
>>
>> Let's call the const rules in C++ "less bad", rather than "sensible".
>>
>> I gather that the original keyword was "readonly", which I think would
>> have been better.  But when we have "const" to mean something is
>> constant and doesn't change, then "mutable" to mean that it might change
>> after all, then "constexpr" to mean that this time we /really/ mean it
>> won't change - it's hard to summarise the situation as "sensible" !
> 
> That's the trouble with programming languages - constants aren't,
> variables don't, and functions won't.
> 

But objects do :-)

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web