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@gmail.com> escreveu:

On Thu, 3 Dec 2020 at 23:15, Alexandre Torres Porres <porres@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@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev