|
|
On 6/11/20 3:49 AM, jr wrote:
> hi,
>
> Alain Martel <kua### [at] videotronca> wrote:
>> Le 2020-06-09 à 06:07, jr a écrit :
>>> I have a macro which expands to an array, eg
>>>
>>> #macro mkArr(...)
>>> .....
>>> array [2] {...}
>>> #end
>>>
>>> which gets assigned, repeatedly, to the same '#declare'd variable. is this ok
>>> wrt memory management, or is it better to '#undef' the elements, and or the
>>> array, before replacing it wholesale? is there a difference? do 'mixed' arrays
>>> behave same as "normal" arrays?
>>>
>> Whenever you assign a new value to any variable, the new value simply
>> replace the old one in the same memory space.
>> The only issue that may arise for memory management, is when you assign
>> a string that don't always have the same length.
>>
>> So, you don't need to #undef.
>
> no strings in this project. still not quite clear what happens when "...simply
> replace the old one in the same memory space". does POV-Ray do "garbage
> collection" at this point, or is the previous value orphaned?
>
> (I ask because the example is a simplification. the array returned is dynamic
> and may contain hundreds of results/elements. my main "problem" is that the
> documentation does not give me any clues.)
>
>> I don't know for mixed arrays.
>>
>> You may need to #undef if you want to assign a new value of a different
>> type like float to vector or string.
>
> currently I simply "#declare Arr = array {};", ie overwrite (?) the previous
> content, hence want/need to know what happens to the old values.
>
I'm not familiar with the new-ish array / dictionary functionality or
code, but I think POV-Ray will let you know if an undef is required. You
cannot redefine functions for example, without first an undef(2).
It should be the previous memory gets freed(1) on the new declare if
POV-Ray allows it. Perhaps proceed as if all OK, and worry about undefs
if you see memory growth? In such a case, I'd consider the lack of a
parser error message (or not freeing memory automatically) a bug.
(1) - IIRC memory use is higher with the newer features. Both because
mixed array elements are all of a size which accommodates the largest.
And on growth the increments are in some sort of multiple of the
existing size. Again, not familiar with the code and I have not myself
used it. All Christoph's work.
(2) - Undefs are are not going to help with memory fragmentation over
time in any case supposing you are allocating and freeing a large number
of varying arrays.
Aside: Anyone else find the #declare, #undef (un-define) pairing
inconsistent. ;-)
Bill P.
Post a reply to this message
|
|