Where to start?

jice wrote:

> On 12 fév, 09:22, "Ulf Åström" <ulf.ast....RemoveThis@gmail.com> wrote:
>>
>> You should *always* check for null pointers, out-of-bounds array
>> indices and division (and modulo! - e.g. rand()) by zero. Never trust
>> your code to be doing what it should. It *will* save time - you'll be
>> able to tell *where* it breaks instead of tracing a bad pointer
>> through 7 levels of function calls.
>
> I personally never check for null pointers or out-of-bounds array
> indices for several reasons :

It's up to you of course. But I find C to be quite treacherous
if you don't watch it every minute.

Checking with "assert" is quick and painless, most of the time, and I
recommend it.

Bear
 >> Stay informed about: Where to start? 

In article <bc29874e-db48-48b9-8691-
f0482744036a.RemoveThis@j20g2000hsi.googlegroups.com>, ulf.astrom.RemoveThis@gmail.com says...
> On 11 Feb, 22:46, poorch....RemoveThis@gmail.com wrote:
> > I myself begun with thinking of some general mechanics of the game,
>
> <snip>
>
> Please quote some context. USENET is not a web forum; some users might
> get the messages in another order than they appear on Google Groups.
>
> > -use definitions extensively. it is easier to use values like
> > TERRAIN_TYPE_GRASS, than to remember that 1 is grass, 2 is dirt and so
> > on. As your project grows in size u will find defines priceless ;]
>
> Use enums if possible; they are often better than #defines as the
> compiler can help you detect problems with them (example: gcc can
> report when you switch() an enum and not all values are covered in the
> switch).
>
> I'm not sure if it's a good idea to use them as array indices though;
> I do it, but it's probably bad practice.

It's a question of coding style IMO.

I certainly wouldn't do it in general, but I would have no qualms about
writing:

PotionType pot = (Potiontype)( ITEM_POTMIN
+ rand() % (ITEM_POTMAX - ITEM_POTMIN) );

> > -be sure to make your code immune to most regular exceptions, like for
> > example index out of array of division by 0. This will help you,
> > because it lessens the amount of thing u have to check if something
> > doesn't work as you expect it to (believe me, it will happen ;] )

Indeed, an assertion that ITEM_POTMAX > ITEM_POTMIN would have its
merits in the above. But...

> You should *always* check for null pointers, out-of-bounds array
> indices and division (and modulo! - e.g. rand()) by zero. Never trust
> your code to be doing what it should. It *will* save time - you'll be
> able to tell *where* it breaks instead of tracing a bad pointer
> through 7 levels of function calls.

....on the other hand, a good debugger can already check for these. And
maybe adding a default potion might be quicker than writing the
assert...

- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
 >> Stay informed about: Where to start? 

In article <d1d76c92-ccd9-49fc-bd27-8eefe60e7b94
@u10g2000prn.googlegroups.com>, ulf.astrom.TakeThisOut@gmail.com says...
> On 12 Feb, 11:29, jice <jice.nos....TakeThisOut@gmail.com> wrote:
> > If the crash can be reproduced, this is not an issue. A crash occuring
>
> I think the fundamental difference is that I'm trying to prevent
> crashes from occuring at all. As player, I'd rather see feature X not
> working than losing a promising character because of a crash. As
> developer, it's much more useful to get a "feature X doesn't work" bug
> report than "my game crashes randomly".

I agree with defensive programmming as a policy in roguelikes.

- Gerry Quinn
 >> Stay informed about: Where to start? 

In article <58bad05b-0848-45bb-8f46-
b1821e04841c DeleteThis @h11g2000prf.googlegroups.com>, jice.nospam DeleteThis @gmail.com
says...
> On 12 fév, 11:55, "Ulf Åström" <ulf.ast... DeleteThis @gmail.com> wrote:
> > On 12 Feb, 11:29, jice <jice.nos... DeleteThis @gmail.com> wrote:
> >
> > > If the crash can be reproduced, this is not an issue. A crash occuring
> >
> > I think the fundamental difference is that I'm trying to prevent
> > crashes from occuring at all. As player, I'd rather see feature X not
> > working than losing a promising character because of a crash. As
> > developer, it's much more useful to get a "feature X doesn't work" bug
> > report than "my game crashes randomly".
> >
>
> Ok, I'm kind of intentionally playing devil's advocate here. I'm not
> saying that I'm right and you're wrong. I think both approachs are
> viable. Of course, the less crashes you have, the better it is and if
> you can avoid some of them by pre-conditions, it's ok. But avoiding
> blindly the crashes everywhere will make it very difficult to find the
> nasty bugs. I'm speaking about this kind of error handling code :
>
> void my_func (params) {
> if (crash condition meet) return; // do nothing
> ... // do something
> }
>
> This will take you to the hell of debugging because you may never
> notice that there was something wrong during this function call and
> the first visible impact may lead you to the wrong track. IMHO, the
> proper handling of an unexpected crash condition would be :
>
> void my_func (params) {
> if (crash condition meet) {
> // log error and everything needed to track its cause
> exit(1);
> }
> ... // do something
> }

I would write:

void my_func (params)
{
if (crash condition meet)
{
ASSERT( false );
return;
}
// do something
}

If it happens in debug, I try to find out what caused it. If it
happened in the wild, too late. Report the bug by all means and I'll
think about it before the next version, but I don't want a log file.

Most serious bugs are easily fixed. The first version of Lair crashed
when you tried to move with the map screen open. When someone pointed
it out, it was trivial to fix, but I had never found it in testing
(naturally, being used to my own interface).

- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
 >> Stay informed about: Where to start? 

On 13 Feb, 00:54, "Jürgen Lerch" <jyn....DeleteThis@gmx.de> wrote:
> On Tue, 12 Feb 2008 00:22:24 -0800 (PST), "Ulf_Åström" wrote:
> > I'm not sure if it's a good idea to use them as array indices though;
> > I do it, but it's probably bad practice.
>
> Well, in Pascal/Modula I do it all the time. Why not in C?

Metadata addiction, meaning it would probably be bad practice in many
other languages, but C doesn't really care; it just wants to get stuff
done (just like myself).

C implements enums like integers and permits normal arithmetic on
them, so technically it's correct. What bothers me is that they
shouldn't really be numbers, just *values*.

E.g. when reading a book you can't simply turn to page "blargh". You
could *call* some page "blargh" and have a lookup table stating how
many pages to flip to get there. So C is in fact doing me a favor by
providing this table directly.

It works, so I'll keep doing it. The alternative - manually numbering
hundreds of #defines - doesn't seem too exciting. The only problem I
have is that I can't declare the size of a static array with an enum.

-the ru
 >> Stay informed about: Where to start? 

Saluton!

On Tue, 12 Feb 2008 00:22:24 -0800 (PST), "Ulf_Åström" wrote:
> On 11 Feb, 22:46, poorch... DeleteThis @gmail.com wrote:
> Please quote some context. USENET is not a web forum; some users might
> get the messages in another order than they appear on Google Groups.

ACK.

[enums]
> I'm not sure if it's a good idea to use them as array indices though;
> I do it, but it's probably bad practice.

Well, in Pascal/Modula I do it all the time. Why not in C?

Ad Astra!
JuL

--
jynwyn DeleteThis @gmx.de / Work like you don't need the money
Jürgen ,,JuL'' Lerch / Dance like no one was watching
/ Love like you've never been hurt
/ - ?
 >> Stay informed about: Where to start? 

On 13 fév, 09:26, "Ulf Åström" <ulf.ast....DeleteThis@gmail.com> wrote:
> The only problem I
> have is that I can't declare the size of a static array with an enum.
>

What do you mean ? This works (mingw32/gcc):

enum { ELT1, ETL2, NB_ELT };

int array[NB_ELT];

--
jice
 >> Stay informed about: Where to start? 

On 13 Feb, 10:10, jice <jice.nos....TakeThisOut@gmail.com> wrote:
> On 13 fév, 09:26, "Ulf Åström" <ulf.ast....TakeThisOut@gmail.com> wrote:
>
> > The only problem I
> > have is that I can't declare the size of a static array with an enum.
>
> What do you mean ? This works (mingw32/gcc):
>
> enum { ELT1, ETL2, NB_ELT };
>
> int array[NB_ELT];

Strange - my experience is that it was troublesome. I might give it
another try.

-the ru
 >> Stay informed about: Where to start? 

On 12 fév, 18:46, Ray Dillinger <b... RemoveThis @sonic.net> wrote:
> jice wrote:
>
> > I personally never check for null pointers or out-of-bounds array
> > indices for several reasons :
>
> It's up to you of course.  But I find C to be quite treacherous
> if you don't watch it every minute.  
>
> Checking with "assert" is quick and painless, most of the time, and I
> recommend it.
>

What bothers me with assert is that it only exit the program and tell
you :
Assertion failed: XXX, file YYY, line ZZZ

Then, you have to 1/ restart the program, 2/ put breakpoints, 3/
reproduce the issue, 4/ watch variable to find its cause...

With a good old unchecked segmentation violation, you're immediately
at step 3.

--
jice
 >> Stay informed about: Where to start? 

On Feb 13, 10:10 am, jice <jice.nos....RemoveThis@gmail.com> wrote:
> On 13 fév, 09:26, "Ulf Åström" <ulf.ast....RemoveThis@gmail.com> wrote:
> > The only problem I
> > have is that I can't declare the size of a static array with an enum.
> What do you mean ? This works (mingw32/gcc):
>
> enum { ELT1, ETL2, NB_ELT };
>
> int array[NB_ELT];

Is it possible that's either a gnu extension or c99?

-Ido.
 >> Stay informed about: Where to start? 

On 13 fév, 11:59, Ido Yehieli <Ido.Yehi... DeleteThis @gmail.com> wrote:
> On Feb 13, 10:10 am, jice <jice.nos... DeleteThis @gmail.com> wrote:
>
> > On 13 fév, 09:26, "Ulf Åström" <ulf.ast... DeleteThis @gmail.com> wrote:
> > > The only problem I
> > > have is that I can't declare the size of a static array with an enum.
> > What do you mean ? This works (mingw32/gcc):
>
> > enum { ELT1, ETL2, NB_ELT };
>
> > int array[NB_ELT];
>
> Is it possible that's either a gnu extension or c99?
>

I don't know but I'm using this in a TCOD class :

enum ConditionTypeId {
UNKNOWN,
DAZED, // creature staggers
STUNNED, // cannot move/attack
BLEEDING, // losing health over time
POISONED, // losing health over time
HEALING, // gaining health over time
IMMUNE, // cannot be poisoned
CRIPPLED, // move 50% slower
REVIVED, // stamina gain x2
FRENZY, // move amount% faster, stamina gain x2. When condition
ends, lose all stamina
AGILE, // dodge 75% of melee attacks, gain 5 stamina for each
dodged attack.
NB_CONDITIONS
};
static char *names[NB_CONDITIONS];

and it compiles on following platforms :
- Visual Studio 2005
- mingw32/g++
- linux/g++

--
jice
 >> Stay informed about: Where to start? 

On 13 Feb, 13:41, jice <jice.nos....RemoveThis@gmail.com> wrote:

<snip code>

> and it compiles on following platforms :
> - Visual Studio 2005
> - mingw32/g++
> - linux/g++

So then it is C++?

-the ru
 >> Stay informed about: Where to start? 

On 13 fév, 15:32, "Ulf Åström" <ulf.ast... RemoveThis @gmail.com> wrote:
> On 13 Feb, 13:41, jice <jice.nos... RemoveThis @gmail.com> wrote:
>
> <snip code>
>
> > and it compiles on following platforms :
> > - Visual Studio 2005
> > - mingw32/g++
> > - linux/g++
>
> So then it is C++?
>

Right, and the previous example was C. So you can declare the size of
a static array with an enum on those 3 platforms for C++ and with gcc
in C. I didn't try the C example in VS, but I can't see why it would
fail (at least with a cast ) :

enum { ELT1, ETL2, NB_ELT };
int array[(int)(NB_ELT)];

--
jice
 >> Stay informed about: Where to start?