TIP: Click on subject to list as thread! ANSI
echo: c_echo
to: Darin McBride
from: Robin Sheppard
date: 1999-01-22 03:23:28
subject: Array Problem

I snipped a bunch out of your message there.  I didn't mean to 
   imply that arrays would always be initialized (though that's what I 
   did actually say), but rather that a partially initialized array 
   would always be completely inititialized.

 RS>    As for pointers, I never rely on them having _any_ particular value
 RS>    (NULL included!) unless I've explicitly set that value myself.  Are
 RS>    you saying that if I have a line like char *whee[10]; that all ten
 RS>    pointers will be NULL pointers before a call to malloc() or some
 RS>    such?

 DM> Nope - you didn't make ANY initialization effort.  Changing it to:

 DM> char *whee[10] = {NULL};

 DM> will initialize ALL of them to NULL (the first because of explicit
 DM> initialization, the rest because of implicit NULL initialization).
 
   Slick.  I take it this works with structs as well?  Some image 
   routines I'm working at will probably end up using a struct that 
   contains the dimensions of an image, and a pointer to the image 
   data.  I'd like to be able to set the dimensions to 0, and the 
   pointer to NULL, without having to explicitly initialize each 
   element of a struct array.
   
   For example:
   
     struct image
     {
        short xsize;
        short ysize;
        char _far *data;
     }
     
     struct image sprites[16] = {0,0,NULL};
     
   This would do what I'm hoping?

 RS>    Hmm.  I bet my compiler issues a warning.  
 
 DM> Have you tried it?
 RS>
 RS>    Tried my compiler?  Yes, I use it frequently.  Tried to see if it
 RS>    issues a warning in this context?  Not yet.  I was merely surmising

 DM> I was asking the latter.  :-)
 
   Heh, I know.  I was just being facetious- my compiler isn't all 
   _that_ bad.
 
 RS>    In case you're wondering why I bother to keep using it, it's
 RS>    because a) it was free for me, b) I have all the manuals and
 RS>    original disks, and c) I'm too lazy/cheap to acquire another.  :/

 DM> Fair enough.  :-)  However, I'd also suggest getting GCC (DJGPP if
 DM> you're on DOS).  Before you protest about being forced to make your
 DM> software freely available rather than charging (i.e., shareware), you
 DM> only have to if you link in GPL'd code (as opposed to LGPL, which the
 DM> standard C library is). Generally, this only applies to the stdcpp
 DM> library, or to the regexp library - you are free to write even
 DM> commercial software if you don't use these libraries (possibly writing
 DM> clean versions yourself if you need them).
 
   Unfortunately, I have no internet access (well, I've got an email 
   address, but no realtime access), so grabbing it from a web or ftp 
   site is out of the question, unless I do it at a friend's place.
   
   What kind of system requirements does it have?  I've got a 386/40 
   here with 8 megs of RAM, one 100-meg HD, and two 50-meg HDs.  Only 
   two of the three drives can be hooked up at a time, though, and my 
   100-megger is chronically hovering near the full point.

... RAM = Rarely Adequate Memory

--- EzyBlueWave V1.48g0 01fd0192
* Origin: Milky Way, Langley, BC [604] 532-4367 (1:153/307)
SEEN-BY: 396/1 632/0 371 633/260 262 267 270 371 634/397 635/506 728 639/252
SEEN-BY: 670/218
@PATH: 153/307 8086 800 140/1 396/1 633/260 635/506 728 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.