| Comments:
| If the optional cleanup flag is non-zero, the memory will be automatically released once it is no longer required, otherwise the application should invoke free?() manually.
Note that when cleanup is true, ie the default automatic memory management is in force, you should avoid invoking free?() or delete?() on pMem explicitly: doing so is guaranteed to leave an invalid pointer to memory lying around. In preference you should either let things happen naturally, or explicitly set the last/only copy of pMem to NULL, and in that way ensure the raw memory is not actually freed until it is guaranteed safe to do so, and accidental references to it will not cause unpredictable memory corruption.
|
| Technicalia
| Euphoria allows say allocate(107.5) and provisions 107 or 108 bytes as it sees fit, whereas in Phix the programmer is forced to explicitly round non-integers in the required direction before invoking allocate(). Technically the first parameter is an atom, to allow values above #3FFFFFFF (on 32-bit, though a hard limit of #5FFFFFF8 applies, whereas 63-bit integers will exceed available hardware for decades yet), but it is explicitly checked to be an exact and non-negative integer (see builtins\pAlloc.e for details).
Certain algorithms are simplified by permitting allocate(0). However the application had better not try and use that memory, and unless the flag for automatically doing so has been used it still has to remember to free() it. In practice, allocate(0) will yield 12 or 20 bytes of useable memory on 32/64 bit systems respectively, not that I recommend relying on that.
A minor point is that technically allocate() on 32-bit yields an unsigned address whereas on 64-bit it is treated as signed, though that is only likely to have any effect should there be some strange OS-level address mapping going on.
As explained in builtins\VM\pHeap.e, 32-bit Phix deliberately limits allocations to 1,610,612,728 bytes (8 bytes shy of #60000000) whereas in tests 32-bit Euphoria managed 1,873,463,796 (#6FAAC9F4) bytes; it is assumed this will not be an issue for any sensibly-written application. In any case, the ability of 32-bit Phix to construct (hll) strings up to 1,610,612,711 characters compared to the 32-bit Euphoria (hll) sequence limit of a mere 468,365,949 elements(/characters) is considered to be completely exhonorating here. Similar limits are theoretically present in 64-bit versions but significantly in excess of any machine that could physically be constructed.
The division between pAlloc.e and pHeap.e exists mainly so that delete_routine?() can be used in the former.
|
