OpenEuphoria

1. Ver 4.0 allocate() question

• Posted by bernie Sep 14, 2008
• 817 views

Is there any good reason that the interpreter returns non-initialize memory
from the allocate function?

Most of the code that I have seen using the allocate function in Euphoria
is closely followed by a mem_set() zero or poke() zero function.

Would'nt it be a good idea to zero out memory internally during the allocate()
This would prevent some user errors and remove the mem_set() over-head.
It would still allow a user to initialize to some other value with mem_set()
or poke() functions

3. Re: Ver 4.0 allocate() question

• Posted by SDPringle Sep 14, 2008
• 851 views
• Last edited Sep 15, 2008

most of the time when you allocate memory you are about to poke something interesting into it anyway. I would hate to have to add a 0 parameter to allocate to avoid this extra C call in the interpreter. Why not have a seperate function called callocate() that allocates and bzeros memory?

Shawn

5. Re: Ver 4.0 allocate() question

• Posted by CChris Sep 15, 2008
• 836 views

I remember reading, long ago, that the rationale for this was that there is no point initialising a memory block if you are going to initialise it yourself. Waste of time.

From my own experience, the first instruction that follow an allocate() is a poke/2/4(), so I'm glad there is no implicit mem_set() I cannot disable. In other cases, I hand the block to some routine for it to fill the structure in, which again makes initialisation wasteful. The counterpart being that, if you want to do a mem_set(), then you do it yourself, but only whe needed.

CChris

7. Re: Ver 4.0 allocate() question

• Posted by bernie Sep 15, 2008
• 756 views

atom m1, m2 
m1 = allocate(80)          -- Eighty bytes of uncleared RAM allocated. 
m2 = allocate(80, CLEARED) -- Eighty bytes of cleared RAM allocated. 

function allocate_set(integer size,object filler=0,integer filler_size=1) 
-- allocates ##size## bytes of memory, and fills the block with ##filler##. 
-- ##filler## is a value that will be stored as a ##filler_size##-byte bvalue with little endian encoding. 
-- ##filler## is chopped off to fit into ##filler_size## bytes, and the copy of ##filler# at the highest address may be truncated if ##size## is not a multiple of ##size_filler##. 
-- If ##filler## is a sequence, then it will be repeatedly poked in memory, ##filler_soze## being ignored and set to be the length of the sequence. This can be handy for filling up with floating point nnumbers. 

What I was suggesting was initializing allocated memory to zero in internally
in the "C" memory allocation.
You are just adding more include file functions which adds something that I
can do in my own code.
No thanks thats just extra complication and more over-head.