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 <[email protected]
<mailto:[email protected]>> escreveu:
On Thu, 3 Dec 2020 at 23:15, Alexandre Torres Porres
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
