|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am creating an array in one macro, and using it in another. The macro
which creates the array surrounds it with a conditional, which results an an
array of variable size, so when I try top loop against it (expectedly)
subscript out of range errors occur.
This would not even be an issue were there an array.length() function.
So what I have tried to do is increment a variable within the conditional
which populates the array which is then used within an if block just before
the i=i+1 like this: [which forces random tests to be performed beyond your
estimate, until your desired array length is reached]
// Check if required array length has been reached, if not, increment
counter until it has
#if (checkLength = requestedLength-1)
#debug "Required Array Length Reached, now exiting... \n"
#else
#if (ctr > 5000)
#debug "Ceiling has been reached; Preventing infinite loop, now
exiting... \n"
#else
#set ctr=ctr+1;
#end
#end
Is this the best I can hope for? Is there some other way to detect the
populated length of an array? dimension_size is *useless*. Might it be that
I am forced to form the array within the loop which uses it? That would
suck...not very OO...but then SDL isn't very OO to start with, ironically..
ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[GDS|Entropy] wrote:
> Is this the best I can hope for? Is there some other way to detect the
> populated length of an array? dimension_size is *useless*.
Why do you think so?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Because the array is declared outside of the macro which populates it, to
facilitate its passing to other macros as a variable, so always returns
whatever you defined its length to be, regardless if it has been populated
with that many values.
Pov doesn't support redimensioning, does it?
ian
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:49a3a996$1@news.povray.org...
> [GDS|Entropy] wrote:
>> Is this the best I can hope for? Is there some other way to detect the
>> populated length of an array? dimension_size is *useless*.
>
> Why do you think so?
>
> Thorsten
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Because the array is declared outside of the macro which populates it, to
> facilitate its passing to other macros as a variable, so always returns
> whatever you defined its length to be, regardless if it has been populated
> with that many values.
>
> Pov doesn't support redimensioning, does it?
Yeah, it does support redimensioning, you just redeclare it;
there's a bit of memory overhead is all.
// oversized array sample
#declare MyArray = array [1000];
#declare MyArray[0] = 1;
#declare MyArray[1] = 2;
// resize the array to fit the data
#macro resize_array(ar)
#local c = 0;
#while (defined(ar[c]))
#local c=c+1;
#end
#local new_ar = array[c];
#local c2=0;
#while (c2<c)
#local new_ar[c2]=ar[c2];
#local c2=c2+1;
#end
#declare ar = new_ar;
#end
// some output
#debug concat("Dimension Size = ", str(dimension_size(MyArray,1),0,0),"\n")
resize_array(MyArray)
#debug concat("Dimension Size = ", str(dimension_size(MyArray,1),0,0),"\n")
#error "Stop"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Is this the best I can hope for? Is there some other way to detect the
> populated length of an array? dimension_size is *useless*. Might it be that
> I am forced to form the array within the loop which uses it? That would
> suck...not very OO...but then SDL isn't very OO to start with, ironically..
Prepared to give yourself a big slap on the head?
Try this (*ta-daaah*):
-------------------------
#ifdef (myArray[i]) ...
-------------------------
So a fail-safe code to loop through an array would look something like this:
#declare i=0;
#while (i < dimension_size(myArray,1))
#ifdef (myArray[i])
#debug concat("[", str(i,0,0), "]=", str(myArray[i],0,0), "\n")
#declare i=i+1;
#else
#debug concat("[", str(i,0,0), "] undefined\n")
#declare i=dimension_size(myArray,1); // force exiting of the loop
#end
#end
(unfortunately, POV doesn't have a break statement for loops (its #break
statement is only of use in #switch statements), nor does it "short-circuit"
its & operator so #while (i < dimension_size(myArray,1) & defined(myArray[i]))
will not work properly, hence the comparatively ugly way of terminating the
loop)
Or, if your list may contain "holes":
#declare i=0;
#while (i < dimension_size(myArray,1))
#ifdef (myArray[i])
#debug concat("[", str(i,0,0), "]=", str(myArray[i],0,0), "\n")
#else
#debug concat("[", str(i,0,0), "] undefined\n")
#end
#declare i=i+1;
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote in message
news:49a3abc7@news.povray.org...
> Because the array is declared outside of the macro which populates it, to
> facilitate its passing to other macros as a variable, so always returns
> whatever you defined its length to be, regardless if it has been populated
> with that many values.
>
> Pov doesn't support redimensioning, does it?
>
Just to make sure I understand you correctly: You define an array that is,
say 5000 elements long. You then call a macro to populate some elements of
that array, but there are gaps. You then need a second macro to loop through
the array, ignoring any unassigned elements?
If that's right, you just need to use #ifdef to see if an element of the
array has been assigned before you use it.
If by 'redimensioning' you mean just scrunching up the gaps, then you can do
that very simply in a loop using #ifdef on an array element. If it exists
move it to the current 'write' point in the array. Plus you can count the
actual number of elements uses as you go.
#local I = 0;
#declare NewSize = 0;
#while (I<dimension_size(MyArray,1))
#ifdef(MyArray[I])
#declare MyArray[NewSize] = MyArray[I];
#declare NewSize = NewSize+1;
#end
#local I=I+1;
#end
Untested code Warning! I didn't run this, so it may contain syntax errors
etc.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks guys!
That #ifdef took care of the issue. I should have remembered that, its part
of C lol! :-D
Tim: I wasn't able to get your macro to work (though looking at it while I'm
typing, it looks like the c=c+1 should come after the c2=c2+1? Am I right?).
I'll play with it a bit later, but that is pretty close to the redim I was
referring to.
I hadn't even considered an array with holes, which is something I should
look out for, but I think in the context of this specific problem that
wasn't happening.
At least I have the solution for that too now. :-D
I appreciate everyones help!
ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Thanks guys!
> That #ifdef took care of the issue. I should have remembered that, its part
> of C lol! :-D
Just an extra thought - couldn't you globally #declare your array size when you
populate it, then use this value in the second macro? Unless I've misunderstood
your first post...
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood wrote:
> #macro resize_array(ar)
> ...
> #declare ar = new_ar;
> #end
>
> resize_array(MyArray)
Interesting. I didn't know macro parameters got by-reference
semantics when an identifier was passed instead of an RVALUE.
I think I'd prefer to assign the value using #local, though,
to make it clear no global variable "ar" is involved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I had a version which did this, but I could only summon it once, as any
subsequent incarnations redefined the contents upon each call.
ian
"Bill Pragnell" <bil### [at] hotmailcom> wrote in message
news:web.49a3d5fe78dc09ae6dd25f0b0@news.povray.org...
> "[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
>> Thanks guys!
>> That #ifdef took care of the issue. I should have remembered that, its
>> part
>> of C lol! :-D
>
> Just an extra thought - couldn't you globally #declare your array size
> when you
> populate it, then use this value in the second macro? Unless I've
> misunderstood
> your first post...
>
> Bill
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|