sysmem_newptr() vs malloc()

Jan 26, 2009 at 9:34pm

sysmem_newptr() vs malloc()

Hi list:

Is there a reason to opt for sysmem_newptr() over malloc() for memory management?

Thanks,

-R

#41949
Jan 26, 2009 at 9:35pm

Thread safety perhaps?

#149825
Jan 26, 2009 at 9:49pm

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.

#149826
Feb 4, 2009 at 3:33pm

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.

Rob

#149827
Feb 4, 2009 at 6:20pm

Quote: rjo218@gmail.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.

#149828

You must be logged in to reply to this topic.