PlanetSquires Forums

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Enum behavior  (Read 175 times)

philbar

  • Little Newbie
  • *
  • Posts: 18
Enum behavior
« on: August 18, 2020, 08:52:09 PM »

Talking about Enums in the last thread made me fool around with them for a minute.

Should I be surprised that this doesn't cause an error or at least a warning?

Code: [Select]
enum mything
   thinga
   thingb
   thingc
end enum

dim as mything x

x = 17
print x

sleep

Or does everybody expect that "mything" is just an ordinary integer with a few names attached to it?
Logged

Johan Klassen

  • Junior Member
  • **
  • Posts: 107
  • FF3 User
Re: Enum behavior
« Reply #1 on: August 18, 2020, 09:33:08 PM »

that is strange, I added #print typeof(x) and the preprocessor prints MYTHING, I expected it to give me the numeric type
Logged

philbar

  • Little Newbie
  • *
  • Posts: 18
Re: Enum behavior
« Reply #2 on: August 19, 2020, 03:39:52 AM »

Yes, it just seems to me that if I declare something to be a "mything", then I ought to be able to trust it to be 0, 1, or 2. Otherwise, why declare it? The discussion of ENUM in the documentation has an example kind of like this, but it doesn't consider the possibility that the trust is broken:

Code: [Select]
enum mything
   thinga
   thingb
   thingc
end enum

sub q(byref z as mything)
   select case z
      case thinga
         print "Thinga"
      case thingb
         print "Thingb"
      case thingc
         print "Thingc"
      case else
         print "What the heck is "; z
   end select
end sub

dim as mything x
dim as single p=1.8

x = 17

q(1)
q(x)
q(9)
q(3.7)   'This gets an "implicit conversion" warning
'q(p)    'This would get a warning and an error

sleep


Are other languages that use enumerations (C, for example) that casual about what you assign to them?
Logged

Johan Klassen

  • Junior Member
  • **
  • Posts: 107
  • FF3 User
Re: Enum behavior
« Reply #3 on: August 19, 2020, 08:49:33 AM »

C behaves just like FB in this case but FreePascal won't tolerate assigning values other than what's in the enum
Code: [Select]
#include<stdio.h>
 
enum week{Mon, Tue, Wed, Thur, Fri, Sat, Sun};
 
int main()
{
    enum week day;
    day = 17;
    printf("%d",day);
    return 0;
}
FreePascal
Code: [Select]
program months;

type
TMonthType = (January=1, February, March, April,May, June, July, August, September, October, November, December);

var Month : TMonthType;
begin
Month:=February;
writeln(Month);
end.
Logged

philbar

  • Little Newbie
  • *
  • Posts: 18
Re: Enum behavior
« Reply #4 on: August 19, 2020, 11:00:24 AM »

Interesting.

Not surprising that Pascal would be the one to complain. It was invented as a teaching language, and I expect it to be unforgiving about coloring outside the lines.

As of 2003, Fortran has an enum statement, but it's just a way of of naming integer constants. You can't give the enum a name, and you can't define a variable to be the enum, so the question doesn't arise.
Logged