Is there a reason to opt for sysmem_newptr() over malloc() for memory management?
Thread safety perhaps?
Hmm, I see…so in theory, if I am writing a simple string parser, and out of convention have used malloc() before stumbling onto symem_newptr(), it shouldn’t wreak any havoc in my routine. I was worried I may have missed something major.
@johnpitcairn, thanks for the insight.
The biggest argument I see for using sysmem_newptr / sysmem_freeptr is to prevent bugs. For example, it would be bad to call free() on an argv returned by object_attr_getvalueof(). So, it is not a bad habit to use the sysmem_* memory routines when programming for a max environment.
It is also possible that sysmem_newptr() could be faster than malloc() for many repeated small memory allocations.
Quote: email@example.com wrote on Mon, 26 January 2009 22:34
> Is there a reason to opt for sysmem_newptr() over malloc() for memory management?
sysmem_newptr() will link on systems that don’t support malloc().
If you think that can’t happen to you, then go ahead and use malloc().
Whatever you do, stick consistently to one memory allocation API. Allocating with one API and freeing with a different one is a sure way to burn in hell. For your code, I mean.
One big reason for sysmem_newptr() is the legacy that there was a time that malloc() was *not* a given on all platforms for Max/MSP development.
C74 RSS Feed | © Copyright Cycling '74