Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?

[John W. Eaton]

On 07/20/2017 12:26 PM, Rik wrote:

> I tested several different initialization strategies including default,
> aggregate, and value initialization and there was not much difference.  I
> used default initialization in the end (what is represented by the code
> above) because there didn't seem to be a need to zero-initialize POD types
> in a temporary buffer.

Yes, I'm pretty sure that for POD types, the assumption is that this 
memory is not initialized unless the OCTAVE_LOCAL_BUFFER_INIT macro is used.

> Also, while looking through the code I found instances where
> OCTAVE_LOCAL_BUFFER was being used with constants that are small and fixed
> at compile time.  Given that OCTAVE_LOCAL_BUFFER is designed for dynamic,
> and possibly large, buffers which are stored on the heap, I believe it
> makes sense to replace these instances with local variables which would be
> stored on the stack.  As an example,
>
> corefcn/load-save.cc:225:  OCTAVE_LOCAL_BUFFER (unsigned char, magic, 2);
>
> A 2-byte scratchpad just isn't worth the new/delete overhead.

Yes, definitely not worth it and should be replaced with just

  "unsigned char magic[2];"

But this change should only be made in cases where the size really is a 
constant.

jwe