Hello, I'm having a strange problem with D and hope someone out there smarter than me can help :)

I have this class that holds a struct array of data. I save it to a file, and then I load it, but before loading it, I set the data's length to zero like so...

data.length = 0; // is this the same as removing all data from data?

load(data); // loads the data, inside the function it tells me that data is a certain length, like say 4

writefln(data.length); // now it tells me data.length is 8. wtf?

I'm wondering, is there something besides data.length = 0; to ensure all data is removed from data?

This problem confuses me as it doesn't make any sense :(

It's hard to understand exactly what you are doing unless you post some of your code. If you do that we will try to help you.

Nick

In article <chv6v0$2uet$1@digitaldaemon.com>, clayasaurus says...
>
>Hello, I'm having a strange problem with D and hope someone out there smarter than me can help :)
>
>I have this class that holds a struct array of data. I save it to a file, and then I load it, but before loading it, I set the data's length to zero like so...
>
>data.length = 0; // is this the same as removing all data from data?
>
>load(data); // loads the data, inside the function it tells me that data is a certain length, like say 4
>
>writefln(data.length); // now it tells me data.length is 8. wtf?
>
>I'm wondering, is there something besides data.length = 0; to ensure all data is removed from data?
>
>This problem confuses me as it doesn't make any sense :(

Nick wrote:
> It's hard to understand exactly what you are doing unless you post some of your
> code. If you do that we will try to help you.
> 
> Nick

Here's some code. I could post more if that would be more helpful.

// EDITOR.d code (main program) /////////////////////////////////////
textureManager.textures.length = 0;
// load it up				
load(fileOpen.filename); // inside here it tells me textures length is 'x'
				
int length = textureManager.textures.length; // here it tells me textures length is 'x * 2'

// LOAD code ////////////////////////////////////////////
void load(char[] argFileName) // serialization works 8-18-04
{// NOTE: Files must be saved and loaded in the same order
  debug logf("engine: getting ready to load ", argFileName);
			
  File file = new File(argFileName, FileMode.In);

  debug logf("engine: ", argFileName, " opened for reading");
			
  rectangleManager.read(file);
  player.read(file);
  textureManager.read(file);
		
  int len = textureManager.textures.length; // dunno why this is needed *confused*, but if I don't, it continues forever
  for (int i = 0; i < len; i++)
  {

textureManager.add(textureManager.textures[i].name,textureManager.textures[i].colormode);
  }

  file.close();
  delete file;
		
  debug logf("engine: ", argFileName, "closed. loading done.");
  debug writefln("engine: ", argFileName, " loaded.");
}

In article <chvbr9$30oe$1@digitaldaemon.com>, clayasaurus says...

>   textureManager.read(file);

What does this do? Does it set textureManager.textures.length?

>
>   int len = textureManager.textures.length; // dunno why this is needed
>*confused*, but if I don't, it continues forever
>   for (int i = 0; i < len; i++)
>   {
> 
>textureManager.add(textureManager.textures[i].name,textureManager.textures[i].colormode);
>   }

What does this do? I'm just guessing, but does textureManager.add() add the textures to the end of textureManager.textures? If so, they you are simply adding the textures in textureManager.textures into textureManager.textures again, thereby doubling it's size. Since textureManager.textures.length keeps getting bigger each time you add() a texture, your loop never stops (until it runs out of memory.) Does this make any sense?

Nick

Nick wrote:
> In article <chvbr9$30oe$1@digitaldaemon.com>, clayasaurus says...
> What does this do? I'm just guessing, but does textureManager.add() add the
> textures to the end of textureManager.textures? If so, they you are simply
> adding the textures in textureManager.textures into textureManager.textures
> again, thereby doubling it's size. Since textureManager.textures.length keeps
> getting bigger each time you add() a texture, your loop never stops (until it
> runs out of memory.) Does this make any sense?
> 
> Nick
> 

Ah! Thank you! Yes that is exactly what is happening, I was trying to use add to generate the textures, but forget it adds one to the length *oops*

Well I got it fixed now. Thanks alot.

In article <chve8j$31jk$1@digitaldaemon.com>,
 Nick <Nick_member@pathlink.com> wrote:

> In article <chvbr9$30oe$1@digitaldaemon.com>, clayasaurus says...
> 
> >   textureManager.read(file);
> 
> What does this do? Does it set textureManager.textures.length?
> 
> >
> >   int len = textureManager.textures.length; // dunno why this is needed
> >*confused*, but if I don't, it continues forever
> >   for (int i = 0; i < len; i++)
> >   {
> > 
> >textureManager.add(textureManager.textures[i].name,textureManager.textures[i]
> >.colormode);
> >   }
> 
> What does this do? I'm just guessing, but does textureManager.add() add the textures to the end of textureManager.textures? If so, they you are simply adding the textures in textureManager.textures into textureManager.textures again, thereby doubling it's size. Since textureManager.textures.length keeps getting bigger each time you add() a texture, your loop never stops (until it runs out of memory.) Does this make any sense?
> 
> Nick

Why don't you use a foreach?

Sha Chancellor wrote:
> Why don't you use a foreach?

What distinct advantages does foreach have over for loops? Is it just syntatical sugar?

Also, in for loops it's easy to see what number (index) i'm on.

I looked at the dsource.org foreach tutorials and it seems you have to overload the opApply operator for classes?

I dunno the for loop just seems simpler and less confusing to me, and I don't see any clear advantages with using foreach. *enlighten me*

clayasaurus wrote:
> Sha Chancellor wrote:
> 
>> Why don't you use a foreach?
> 
> 
> What distinct advantages does foreach have over for loops? Is it just syntatical sugar?
> 
> Also, in for loops it's easy to see what number (index) i'm on.
> 
> I looked at the dsource.org foreach tutorials and it seems you have to overload the opApply operator for classes?
> 
> I dunno the for loop just seems simpler and less confusing to me, and I don't see any clear advantages with using foreach. *enlighten me*

opApply and foreach provide a means to abstract out the mechanism for iteration in a clean way, which makes for code that describes itself better:

    LinkedList!(int) list;
    int[] array;

    foreach (int i; list) { ... }
    foreach (int i; array) { ... }

The details of how the iteration is implemented aren't usually important to the actual algorithm, so it makes sense that they be omitted.

If memory serves, you can get the numeric index too:

    foreach (int index, int element; array) { ... }

 -- andy

Andy Friesen wrote:

> clayasaurus wrote:
> 
>> Sha Chancellor wrote:
>>
>>> Why don't you use a foreach?
>>
>>
>>
>> What distinct advantages does foreach have over for loops? Is it just syntatical sugar?
>>
>> Also, in for loops it's easy to see what number (index) i'm on.
>>
>> I looked at the dsource.org foreach tutorials and it seems you have to overload the opApply operator for classes?
>>
>> I dunno the for loop just seems simpler and less confusing to me, and I don't see any clear advantages with using foreach. *enlighten me*
> 
> 
> opApply and foreach provide a means to abstract out the mechanism for iteration in a clean way, which makes for code that describes itself better:
> 
>     LinkedList!(int) list;
>     int[] array;
> 
>     foreach (int i; list) { ... }
>     foreach (int i; array) { ... }
> 
> The details of how the iteration is implemented aren't usually important to the actual algorithm, so it makes sense that they be omitted.
> 
> If memory serves, you can get the numeric index too:
> 
>     foreach (int index, int element; array) { ... }
> 
>  -- andy

Memory does serve you correctly Andy, as a matter of fact I use this every time I need an iterator. Being a tyro and all, I am prone to mistakes and foreach helps me completely eliminate on of the most annoying of them (the "off-by-one" error). Not only that, it is far more intuitive than it's predecessor.

If I had my way, "for" loops would be removed from the language. And in order to make in more powerful, I'd change the foreach such things as:

  foreach(int i || double d; container) { ... }
  foreach(char c && int i; container) { ... }

in addition to its current functionality. Note: container refers to aggregate data types such as lists, arrays, structs, classes, and any variation thereof.

Andrew

In article <chvfet$nq$1@digitaldaemon.com>, clayasaurus says...
>
>Nick wrote:
>> In article <chvbr9$30oe$1@digitaldaemon.com>, clayasaurus says...
>> What does this do? I'm just guessing, but does textureManager.add() add the
>> textures to the end of textureManager.textures? If so, they you are simply
>> adding the textures in textureManager.textures into textureManager.textures
>> again, thereby doubling it's size. Since textureManager.textures.length keeps
>> getting bigger each time you add() a texture, your loop never stops (until it
>> runs out of memory.) Does this make any sense?
>> 
>> Nick
>> 
>
>Ah! Thank you! Yes that is exactly what is happening, I was trying to use add to generate the textures, but forget it adds one to the length *oops*
>
>Well I got it fixed now. Thanks alot.