[PD-dev] how to dinamically allocate t_atom & t_float size?

[Christof Ressi]

alloca() "allocates" memory on the stack. This is done by simply 
incrementing the stack pointer. So it's extremely fast and - more 
importantly - equally fast for all sizes.

malloc(), on the other hand, actually uses the system memory allocator 
which can take arbitrarily long and might even block!

Generally, you should avoid using any malloc() in real-time code paths. 
Instead, pre-allocate temporary buffers (e.g. in the "dsp" method) or 
allocate on the stack (but note the caveats mentioned in the other mails).

Christof

On 04.12.2020 03:28, Alexandre Torres Porres wrote:
> I'm using getbytes and freebytes for now, any disadvantages over alloca?
>
> thanks!
>
> Em qui., 3 de dez. de 2020 às 20:59, David Rush <kumoyuki at gmail.com 
> <mailto:kumoyuki at gmail.com>> escreveu:
>
>     On Thu, 3 Dec 2020 at 23:15, Alexandre Torres Porres
>     <porres at gmail.com <mailto:porres at gmail.com>> wrote:
>
>         Hi, when compiling ELSE for camomille in windows, me and
>         Esteban are getting some errors. Offending pieces of code are
>         when trying to do things like
>
>         t_atom at[ac];
>
>
>     If you want to maintain straight C compiler compatibility
>
>             t_atom* at = (t_atom*)malloc(ac * sizeof(t_atom));
>
>     but you have to remember to free(at), &cet. You can avoid the
>     free() if you HAVE_ALLOCA with
>
>             t_atom* at = (t_atom*)alloca(ac * sizeof(t_atom));
>
>     if you want to do it the C++ way without a std::vector<t_atom>
>
>             t_atom* at = new t_atom[ac];
>
>     but again you will have to
>
>             delete at;
>
>     For my own externals, I write them all in C++ and use STL. Making
>     the change from the C-world allocation of PD to the C++ world is
>     not so hard, but it does involve a tiny bit of trickery which I
>     only justify through expediency.
>
>     - d
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20201204/53fa1325/attachment-0001.html>