Help with file I/O

Help with file I/O

gary_ramsgate

Member #8,619

May 2007

I'm really struggling in loading a high score table.
I can create a blank hi-score table and save it to disk with no problems. When I try to load the data, the program runs ok and the name is displayed ok, but the score is loaded as some high number. I'm getting confused so any help would be gratefully received.

int blank_hiscores(void)
{
// Save a new blank hi-score table
//
ofstream myfile ("hiscores.txt");
for (int n=10; n>0;n--)
{
myfile << "xxxxxx"; //name
myfile << "\n";
myfile << n; //score
myfile << "\n";
}
myfile.close();
textprintf_ex(screen, font, 10, 50, makecol(255, 255, 255),-1, "New Hi-score table created");
rest(1000);
clear_bitmap(screen);
}

int load_hiscores(void)
{
string dummy;
int dummy1;

// Load Hi-score table
//
ifstream myfile ("hiscores.txt");
for (int n=0; n<10;n++)
{
getline (myfile,dummy);
hi_scores[n].name=dummy;
textprintf_ex(screen, font, 60, 30+(n*10), makecol(255, 255, 255),-1, "%s", hi_scores[n].name.c_str());

getline (myfile,dummy);
hi_scores[n].score=dummy1;
textprintf_ex(screen, font, 200, 30+(n*10), makecol(255, 255, 255),-1, "%i", hi_scores[n].score);
}
myfile.close();
textprintf_ex(screen, font, 10, 300, makecol(255, 255, 255),-1, "Hi-Score table loaded");
rest(2000);
clear_bitmap(screen);
}

X-G

Member #856

December 2000

You do realize you never actually set dummy1 to anything, right?

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散！悪霊退散！怨霊、物の怪、困った時は　ドーマン！セーマン！ドーマン！セーマン！　直ぐに呼びましょう陰陽師レッツゴー！

bamccaig

Member #7,536

July 2006

X-G said:

You do realize you never actually set dummy1 to anything, right?

Since he's asking us why he's outputting garbage he probably doesn't. ::) :-[ It's an honest mistake with identifiers dummy and dummy1.

gary_ramsgate said:

getline (myfile,dummy);
hi_scores[n].score=dummy1;

In other words, you mistakenly loaded the score into the string object instead of the integer.

I haven't done C/C++, file I/O, nor Allegro programming in a while so I couldn't say if that's the only problem...

Also, use [code]mycodehere[/code] tags and use descriptive variable identifiers. dummy and dummy1 are worse than a and b.

For other BBCode syntax on Allegro.cc, check out the Help section (the Help button on the Post Reply toolbar).

--
I mean the best with what I say. It doesn't always sound that way.

Timorg

Member #2,028

March 2002

I use this code for my games that need a high score table, it can load and save and sort names, its doesn't deal with getting names from user, and showing the high-score table, it just manages the table itself. Even if the code isn't much use, it will stick you on the right track.

http://www.timorg.net/high_score.zip

If you need an example of use, I will whack something together.

-Tim

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard ... :D

spellcaster

Member #1,493

September 2001

I wrote a small "game template" for allegro games some time ago. It also contains high score routines. You might want to take a look at it to get some ideas.

Please note that the main() routine is basically a showcase of the functions.

#SelectExpand
   1#include <allegro.h>
   2#include <stdio.h>
   3#include <stdlib.h>
   4
   5
   6enum {
  HI_COLOR   = -3,
  TRUE_COLOR,
  INDEXED_COLOR
  10};
  11
  12enum {
  MODE_FAILED,
  WINDOWED,
  FULLSCREEN,
  WINDOWED_OR_FULLSCREEN,
  FULLSCREEN_OR_WINDOWED
  18};
  19
  20typedef struct {
  int w, h, bpp;
  int windowed;
  int preferred_bpp;
  
  BITMAP* buffer;
  26} ScreenInfo;
  27
  28enum { HISCORE_COUNT = 10 };
  29enum { HISCORE_NAME_LENGTH = 16 };
  30
  31
  32typedef struct {
  int   score;
  char  name[HISCORE_NAME_LENGTH];
  char  new_entry;
  36} HiscoreEntry;
  37
  38/* We need one element more than actually used by the game */
  39HiscoreEntry hiscores[HISCORE_COUNT +1];
  40ScreenInfo   screen_info = { 0, 0, 0, 0, 0, NULL };
  41
  42
  43/*
* Sets all hiscore table entries to a given name and value.
*     name  - the name to use. If longer than HISCORE_NAME_LENGTH, the name will be truncated.
*     score - the score 
*/
  48void hiscore_init(char *name, int score) {
  int a;
  for (a = 0; a < HISCORE_COUNT; ++a) {
      snprintf(hiscores[a].name, HISCORE_NAME_LENGTH, name);
      hiscores[a].score = score;
      hiscores[a].new_entry = 0;
  }
  55}
  56
  57/*
* Compares two hiscore entries. Used by quicksort in the hiscore_add() method
*/
  60int hiscore_compare(const void *lhs, const void *rhs) {
  return ((HiscoreEntry*) rhs)->score - ((HiscoreEntry*) lhs)->score;
  62}
  63
  64
  65/*
* Adds a new score to the table. After the call to this function
* you can recognize the new element in the table by the state of the
* new_entry flag - so if you want to display the latest entry to the table
* differently, just check the newly added flag.
*/
  71void hiscore_add(char *name, int score) {
  int a;
  for (a=0; a < HISCORE_COUNT; ++a) {
      hiscores[a].new_entry = 0;
  }
  
  /* the table contains one element more than HISCORE_COUNT,
   * allowing us to add new scores easily
   */
  snprintf(hiscores[HISCORE_COUNT].name, HISCORE_NAME_LENGTH, name);
  hiscores[HISCORE_COUNT].score = score;
  hiscores[a].new_entry = 1;
  
  qsort(hiscores, HISCORE_COUNT+1, sizeof(HiscoreEntry), hiscore_compare);
  85}
  86
  87int hiscore_save(const char* filename) {
  int a;
  PACKFILE *f = pack_fopen(filename, "w");
  
  if (f != NULL) {
      for (a = 0; a < HISCORE_COUNT; ++a) {
          pack_fwrite(hiscores[a].name, HISCORE_NAME_LENGTH, f);
          pack_iputw(hiscores[a].score, f);
      }
      pack_fclose(f);
      
      return TRUE;
  }
  return FALSE;
 101}
 102
 103int hiscore_load(const char* filename) {
  int a;
  PACKFILE *f = pack_fopen(filename, "r");
  
  if (f != NULL) {
      for (a = 0; a < HISCORE_COUNT; ++a) {
          pack_fread(hiscores[a].name, HISCORE_NAME_LENGTH, f);
          hiscores[a].score = pack_igetw(f);
      }
      pack_fclose(f);
      
      return TRUE;
  }
  return FALSE;
 117}
 118
 119
 120/*
* Sets a gfx mode.
* If you pass a literal value for the colordepth (say 16) this
* routine will try to set the colordepth and return a failure if
* this depth could not be set. If you pass a mode constant the
* routine will try several fitting color depths if the preferred
* one could not be set.
* If you want to force a windowed mode, pass WINDOWED as windowed parameter
* If you want to force a fullscreen mode, pass FULLSCREEN as windowed.
* If you prefer windowed, but can live with fullscreen use WINDOWE_OR_FULLSCREEN.
* If you prefer fullscreen, but windowed is ok as well, pass FULLSCREEN_OR_WINDOWED
*
*   width      - screen width
*   height     - screen height
*   colordepth - either HI_COLOR, TRUE_COLOR, INDEXED_COLOR or the bpp
*                value you want to use (8, 16, etc..)
*   windowed   - either WINDOWED, FULLSCREEN, WINDOWED_OR_FULLSCREEN or
*                FULLSCREEN_OR_WINDOWED
*
*   returns TRUE if the mode was set, FALSE otherwise
*/
 141int init_graphics(int width, int height, int colordepth, int windowed) {
  
  /*
   * Not all cards support 16 bit color, some require 15
   * even if they are listed as "HiColor".
   * In order to set a fitting graphics mode, some
   * alternatives are defined.
   * The 24 bit color mode is always tried last, since
   * the 3 byte alignement makes it a terribly slow mode to
   * use.
   */
  static int hicolor[]  =  { 16, 15, 32, 24, 0 };
  static int truecolor[] = { 32, 16, 15, 24,  0 };
  int *depths = NULL;
  int  bpp   = 0;
  int a;
  int mode = 0;
  int result = -1;
  
  /*
   * depths is the array containing the bpp values.
   * We'll iterate over that array (if it is != NULL)
   * below and set the corresponding mode. If the
   * array is NULL we'll try to set the colordepth
   * stored in bpp (if bpp != 0)
   */
  switch (colordepth) {
      case HI_COLOR:
          depths = hicolor;
          break;
      case TRUE_COLOR:
          depths = truecolor;
          break;
      case INDEXED_COLOR:
          bpp = 8;
          break;
      default:            
          bpp = colordepth;
  }
  
  /* Set the first mode (windows or fullscreen) to try */
  if (windowed == WINDOWED || windowed == WINDOWED_OR_FULLSCREEN) {
      mode = GFX_AUTODETECT_WINDOWED;
  } else {
      mode = GFX_AUTODETECT_FULLSCREEN;
  }    
  
  if (depths) {  
      /* While no mode is set and we have alternative modes */
      while (result < 0 && windowed != MODE_FAILED) {
          a = 0;
          while (depths[a] != 0 && result < 0) {
              set_color_depth(depths[a]);            
              result = set_gfx_mode(mode, width, height, 0, 0);
              if (result >= 0) {
                  bpp = depths[a];
              }
              ++a;
          }        
          
          if (result < 0) {
              if (windowed == WINDOWED_OR_FULLSCREEN && mode == GFX_AUTODETECT_WINDOWED) {
                  mode = GFX_AUTODETECT_FULLSCREEN;
              } else if (windowed == FULLSCREEN_OR_WINDOWED && mode == GFX_AUTODETECT_FULLSCREEN) {
                  mode = GFX_AUTODETECT_WINDOWED;
              } else {
                  windowed = MODE_FAILED;
              }
          }
      }
  } else if (bpp != 0) {
      /* User has requested a very specific color depth */
      set_color_depth(bpp);
      result = set_gfx_mode(mode, width, height, 0, 0);
      
      if (result < 0) {            
          if (windowed == WINDOWED_OR_FULLSCREEN && mode == GFX_AUTODETECT_WINDOWED) {
              mode = GFX_AUTODETECT_FULLSCREEN;
          } else if (windowed == FULLSCREEN_OR_WINDOWED && mode == GFX_AUTODETECT_FULLSCREEN) {
              mode = GFX_AUTODETECT_WINDOWED;
          } else {
              windowed = MODE_FAILED;
          }
          
          /* if there is a 2nd mode we can try, try it: */
          if (windowed !=MODE_FAILED) {
              result = set_gfx_mode(mode, width, height, 0, 0);
          }
      }
  }
  
  /* If a mode was set, result is equal to (or greater than) 0.
   */
  if (result >= 0) {
      
      /* If this method was called to change the graphics mode,
       * we'll try to maintain the contents of the screen
       */
      if (screen_info.w == width && screen_info.h == height) {
          /* screensize was not changed, blit doublebuffer to screen */
          blit(screen_info.buffer, screen, 0, 0, 0, 0, width, height);
          
          if (screen_info.bpp != bpp) {
              /* colordepth has changed, we need a new buffer.
               * If we destroy the buffer here and set it to NULL,
               * a new bufer will be created below
               */
              destroy_bitmap(screen_info.buffer);
              screen_info.buffer = NULL;
          }
      }
      screen_info.w              = width;
      screen_info.h              = height;
      screen_info.bpp            = bpp;
      screen_info.preferred_bpp  = colordepth;
      screen_info.windowed       = (mode == GFX_AUTODETECT_WINDOWED);        
      
      /* create a doublebuffer if needed */
      if (screen_info.buffer == NULL) {
          screen_info.buffer         = create_bitmap(width, height);
      }
      
      return TRUE;
  } else {        
      return FALSE;
  }         
 267}
 268
 269/*
* Allows you to toggle the fullscreen / windowed aspect of your game.
*    windowed - set to TRUE if you want to switch to windowed mode, 
*               set to FALSE if you want to switch to fullscreen mode.
*
*   returns TRUE if the switch worked, FALSE otherwise
*/
 276int set_window_mode(int windowed) {
  if (screen_info.windowed != windowed) {
      /* if your game uses video BITMAPs make sure to release them here,
       * and recreate them after the call to init_graphics, kinda like this:
       *
       * int result = 0;
       * unload_all_video_bitmaps();
       * result = init_graphics(screen_info.w, screen_info.h, screen_info.preferred_bpp, windowed ? WINDOWED : FULLSCREEN);
       * load_all_video_bitmaps();
       * return result;
       */
      return init_graphics(screen_info.w, screen_info.h, screen_info.preferred_bpp, windowed ? WINDOWED : FULLSCREEN);
  }
  return TRUE;
 290}
 291
 292
 293void update_screen() {
  blit(screen_info.buffer, screen, 0, 0, 0, 0, screen_info.w, screen_info.h);
 295}
 296
 297
 298int main(int argc, char* argv) {        
  int lastkey = 0;
  int a;
  
  FONT *colorFont;
  
  allegro_init();
  if (init_graphics(800, 600, HI_COLOR, WINDOWED_OR_FULLSCREEN)) {
      install_keyboard();
      
      text_mode(-1);
     
      clear_keybuf();
      clear(screen_info.buffer);
      textprintf(screen_info.buffer, font, 10, 10, makecol(255,255,255), "%ix%ix%i", screen_info.w, screen_info.h, screen_info.bpp);
      
      update_screen();
      
      while (!key[KEY_ESC])  {
                      
          if (key[KEY_W] && lastkey != KEY_W) {
              lastkey = KEY_W;
              set_window_mode(TRUE);
          } else if (key[KEY_F] && lastkey != KEY_F) {
              lastkey = KEY_F;
              set_window_mode(FALSE);
          } else {
              lastkey = 0;
          }
          
          rest(1);
      }
  }
  
  hiscore_init("This string is way too long. Way too long", 10);
  hiscore_add("foo", 20);
  hiscore_add("bar", 30);
  hiscore_add("baz", 15);
  for (a=0; a < HISCORE_COUNT; ++a) {
      printf("%2i %16s    %i\n", (a+1), hiscores[a].name, hiscores[a].score);
  }
  hiscore_save("hiscores.bin");
  hiscore_load("hiscores.bin");
  for (a=0; a < HISCORE_COUNT; ++a) {
      printf("%2i %16s    %i\n", (a+1), hiscores[a].name, hiscores[a].score);
  }
 344} 
 345END_OF_MAIN()

--
There are no stupid questions, but there are a lot of inquisitive idiots.

gary_ramsgate

Member #8,619

May 2007

Many thanks for the code.

ImLeftFooted

Member #3,935

October 2003

Thats a clever trick of using enums for named constants.

How is my posting?

X-G

Member #856

December 2000

Quote:

Since he's asking us why he's outputting garbage he probably doesn't.

It's a rhetorical device, you dimwit.

CGamesPlay

Member #2,559

July 2002

Quote:

Thats a clever trick of using enums for named constants.

It's pretty standard for C++. It allows you to put constants in a namespace.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

spellcaster

Member #1,493

September 2001

Quote:

> Thats a clever trick of using enums for named constants.
It's pretty standard for C++. It allows you to put constants in a namespace.

It's also pretty standard for C

--
There are no stupid questions, but there are a lot of inquisitive idiots.

GullRaDriel

Member #3,861

September 2003

It was / is pretty standard for C before even C++ exists

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

CGamesPlay

Member #2,559

July 2002

Hmm, interesting. Why doesn't the grabber emit that sort of header then?

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

GullRaDriel

Member #3,861

September 2003

Heh, because grabber is a secret build from allegro big 5 ;-)

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

spellcaster

Member #1,493

September 2001

Sometimes using the preprocessor can be the better option. Esp. if you use some of the more powerful features of the pp.

Another point is that using the PP is IMO the better solution for the grabber headers. You're not working with actual constants. You are actually accessing an index. You just prefer to give that index a speaking name. So the mapping is value -> name.

In the case above the mapping is vice versa. I have name and map it to a value.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

bamccaig

Member #7,536

July 2006

spellcaster said:

enum {
    HI_COLOR   = -3,
    TRUE_COLOR,
    INDEXED_COLOR
};

I'm not sure I understand the point of using enums instead of the preprocessor. It would help if I understood namespaces... :-/ And if you're not defining a namespace, spellcaster, wouldn't it be better to use the preprocessor? :-/

X-G said:

It's a rhetorical device, you dimwit.

X_G.PostCount+=2;

--
I mean the best with what I say. It doesn't always sound that way.

CGamesPlay

Member #2,559

July 2002

Quote:

And if you're not defining a namespace, spellcaster, wouldn't it be better to use the preprocessor? :-/

It's never better to use the preprocessor.

enum { NamedConstant = 2 };

void foo() {
    int NamedConstant = 3;
    NamedConstant = 4;
}

Obviously, this is an obvious example, since no one would create a variable named NamedConstant. However, this is totally valid code that compiles. But, had you used the preprocessor, you get this error message:

test.cpp: In function 'void foo()':
test.cpp:4: error: expected unqualified-id before numeric constant
test.cpp:5: error: invalid lvalue in assignment

Quite cryptic.

For a more likely example, try this on for size:

typedef struct BITMAP {
    int w, h;
} BITMAP;

#define BITMAP 3

BITMAP* buffer;

This sort of thing happens all the time.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

bamccaig

Member #7,536

July 2006

Name collision is just a fact of programming though. I don't think that's a valid flaw in #define'ing constants. I was told that by #define'ing your global constants you save memory (even though it wouldn't be much).

Besides, considering how quickly the problem was detected in those threads returned by the search I would say that it's relatively easy to track down. You also probably don't want a local variable named the same as your constant to avoid logical errors (perhaps breaking somebody else's code) so I would still lean towards the preprocessor when possible.

It's also easy to come up with a naming convention to separate preprocessor definitions from other entities.

/*
 *  For example, and this is not to be taken as real code...
 */

#define NAMED_CONSTANT 4

class NamedConstant
{
private:
    int mintNamedConstant;
};

Anybody else have an opinion?

--
I mean the best with what I say. It doesn't always sound that way.

CGamesPlay

Member #2,559

July 2002

Quote:

Name collision is just a fact of programming though.

Sure, if you code like that. Using constants inside specific scopes completely eliminates the collision. You can select either constant:

#include <iostream>

using namespace std;

enum { Bitmap = 3 };

int main(int argc, char* argv[])
{
        int Bitmap;
        Bitmap = ::Bitmap;

        cout << "Bitmap constant is " << ::Bitmap << endl;
        cout << "Bitmap variable is " << Bitmap << endl;

        return 0;
}

Quote:

I was told that by #define'ing your global constants you save memory (even though it wouldn't be much).

Well, that's wrong, as the compiler will inline the constants anyways.

[append]
In addition, even if creating an enumeration caused any extra space to be allocated in the executable (which it doesn't), it would have to be enough data to cause the program to spill over into the next allocation chunk, otherwise it's insignificant. Allocation chunks are typically (or always, on a Pentium, IIRC) 4kb.
[/append]

The problem is that you're using the preprocessor to do things the compiler should be doing. It's like running a sed script on your code before you compile it. The sed script doesn't know whether or not you mean the variable or the constant, it just does string replacement. The compiler can accomplish the same task, but more intelligently.

Libraries that use the preprocessor have to prefix all of their symbols to avoid collision. Instead of doing that, use namespaces. Compare:

// GfxLib.h
#define MODE_SOLID 0x01

That uses the preprocessor to represent a flag passed to a function that draws shapes in a graphics library.

// ColDetek.h
#define MODE_SOLID 0x03

That uses the preprocessor to represent a flag passed to a function in a physics library. Now one can't use both libraries in the same file. To fix the problem, both libraries need to be made compliant.

// GfxLib.h
#define GFXLIB_MODE_SOLID 0x01

// ColDetek.h
#define COLDETEK_MODE_SOLID 0x03

Now to use them we have to use GFXLIB_MODE_SOLID or COLDETEK_MODE_SOLID. How annoying. Instead, use enumerations and namespaces:

// GfxLib.h
namespace GfxLib
{

enum { MODE_SOLID = 1 };

}

// ColDetek.h
namespace ColDetek
{

enum { MODE_SOLID = 3 };

}

Now, when you want to use ColDetek's constants, use ColDetek::MODE_SOLID. How does that help? using statements!

void foo() {
    using namespace ColDetek;

    ColDetekFunction(data, MODE_SOLID);

    // Lots of other calls to ColDetek's functions

    // But we can still use GfxLib in this function
    GfxLib::DrawPoly(points, GfxLib::MODE_SOLID);
}

Namespace collisions are not a product of programming, they are a product of poor programming.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

bamccaig

Member #7,536

July 2006

Thanks. That's all very interesting.

CGamesPlay said:

Well, that's wrong, as the compiler will inline the constants anyways.

What do you mean by inline the constants? And if there's no difference in memory usage between using the preprocessor instruction (#define) versus an enum or const definition then why do large commercial games #define constants? :-/

CGamesPlay said:

// But we can still use GfxLib in this function

However, wouldn't using the prefix make it more clear which namespace each constant belongs to?

void foo()
{
    ColDetekFunction(data, ColDetek::MODE_SOLID);

    // Lots of other calls to ColDetek's functions

    GfxLib::DrawPoly(points, GfxLib::MODE_SOLID);
}

--
I mean the best with what I say. It doesn't always sound that way.

CGamesPlay

Member #2,559

July 2002

Quote:

I'm curious how the std namespace is defined if it contains entities from different header files... :-/ Or am I misunderstanding the structure of the std namespace? Does anybody know where it's defined? :-/

Namespaces don't have to be declared all at once. This code is valid:

namespace foo {

enum { constant };

}

namespace foo {

void func();

}

Quote:

Also, is there a way to switch between namespaces in the same scope (for example, use one, stop using it, use another one)?

No, because you can't "stop" using a namespace.

Quote:

However, wouldn't using the prefix make it more clear which namespace each constant belongs to?

Well, yeah, but it can also make it more convoluted. It gets to a point where you know you are passing ColDetek::MODE_SOLID to ColDetek::ColDetekFunction.

[edit]
Changed example to be clearer.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

bamccaig

Member #7,536

July 2006

CGamesPlay said:

Namespaces don't have to be declared all at once.

CGamesPlay said:

No, because you can't "stop" using a namespace.

Good to know. Thanks!

_{I deleted the question in his quote convinced that it was a stupid qustion... Apparently it wasn't... :-/}

CGamesPlay said:

Well, yeah, but it can also make it more convoluted. It gets to a point where you know you are passing ColDetek::MODE_SOLID to ColDetek::ColDetekFunction.

True...

--
I mean the best with what I say. It doesn't always sound that way.

spellcaster

Member #1,493

September 2001

Quote:

Define "better". Main reason I use enums is that the enum is known to the compiler, so it'll appear in compile errors, during debug sessions, etc.

Besides that, it's mainly a question of style and lazyness. If I have a couple of constants with increasing numbers, using an enum is simply less typing.

And adding a new constant in the middle is way less work.
I also think that the enum version is slightly more readable.

You can also do something like this:

enum {
   MODE_1 = 0
   MODE_2,
   MODE_3,
   MODE_GUARD        
};
int countModes = MODE_GUARD - MODE_1;
// or
for (int a=MODE_1; a < MODE_GUARD; ++a) {
}

That's nothing fancy. It's just practical and provides a bit of comfort. Oh, have I mentioned that it saves a couple of keystrokes as well? This will not make a big difference, but if you start using it, and you need to insert that extra constant in the middle, you'll just smile, do it and smile even broader.

Guess that's why I'm using it. I like that warm feeling

--
There are no stupid questions, but there are a lot of inquisitive idiots.

CGamesPlay

Member #2,559

July 2002

Quote:

What do you mean by inline the constants?

const int NamedConstant = 3;
enum { NamedConstant = 3 };

Both of those create constant values. When you compile the program, the compiler doesn't actually add that value to the code as a variable. Instead, wherever you use the variable, the compiler places the literal value there directly.

Quote:

And if there's no difference in memory usage between using the preprocessor instruction (#define) versus an enum or const definition then why do large commercial games #define constants? :-/

In C there isn't much advantage to using the enums since you can't select the scoping you want anyways (in other words the function scope will always override the named constant and you can't change that behavior), and #defines are easier to type, I suppose (there might be an argument for "easier to read" also). The tradition probably carried over into C++, before people popularly realized the concrete benefits of enumerations.

--
Tomasu: Every time you read this: hugging!

Ryan Patterson - <http://cgamesplay.com/>

Jonatan Hedborg

Member #4,886

July 2004

In C++, this is also quite nice:

enum WHATEVER {
ENUM1,
ENUM2,
ENUM3
}

void doSomething(WHATEVER w) {
...
}

Kitty Cat

Member #2,815

October 2002

typedef enum WHATEVER {
ENUM1,
ENUM2,
ENUM3
} WHATEVER;

void doSomething(WHATEVER w) {
...
}

Works in C, too.

Another thing I like about enums:

1enum eFoo {
2   VAL1,
3   VAL2,
4   VAL3
5};
6 
7void someFunc(eFoo foo)
8{
9   switch(foo)
10   {
11      case VAL1:
12         ...
13         break;
14      case VAL2:
15         ...
16         break;
17   }
18}

will generate a warning in GCC that 'VAL3' isn't handled in the switch statement.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham