[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #48793] no need for OCTAVE_LOCAL_BUFFER anymor

From: Rik
Subject: [Octave-bug-tracker] [bug #48793] no need for OCTAVE_LOCAL_BUFFER anymore
Date: Wed, 19 Jul 2017 14:51:25 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Follow-up Comment #5, bug #48793 (project octave):

We came across the same problem in regexp.cc.  I fixed it on the stable branch
since it isn't right to have potentially segfaulting code there.  I also
switched to OCTAVE_LOCAL_BUFFER_INIT so I could get rid of the for loop.  See

For the other questions, there weren't advantages to the old system because
they were never being used (#if 0 was disabling them completely at
compile-time).  I was going to do performance benchmarking to see if anything
has changed.  I suspect the current implementation may be a bit slower because
the default constructor for object T is called N times.  The second
implementation that I wrote, which uses char as the default data type to
allocate bytes may be preferable.  In that case, there will still be
initialization, but for a POD data type that should just be filling with 0. 
There would be no calling of potentially long constructor chains.  Ideally,
there is a way to just allocate storage without initialization, but that
sounds like using malloc rather than new.  Maybe that is worth a question on
Stack Overflow?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]