Kent, Your initial statement seems to be an absolute ( similar to a never, or always ), these frequently are a bit short sighted.
A very good potential use for this allocation on the stack (not heap) method or similar object is for the VariableLengthVetctor temporaries. Performing an array allocation on a per-pixel basis in a multi-threaded environment is detrimental to the performance of an algorithm. Now, my particular case is not done on a per-pixel basis, but it may be used as part of the multi-threaded ImageFilter overhead and the methodology setup for this particular case will likely effect almost all filters. Now regarding the like-ness of C arrays to goto statements, I am fairly opposed to raw array being exposed in interfaces; they are just too error prone. However, there can be many benefits to using them locally or in protected methods. I very much like the way I was able to use them in the patch below. Those functions which take C arrays are non-templated and compilable. I would estimate that the methods contained in the derived classes were re-compiled thousands of time, and duplicated just as many across your hard drive for each ITK build. http://review.source.kitware.com/#/c/10059/6/Modules/Core/Common/include/itkImageRegionSplitterBase.h Now regarding efficiency. Many basic ITK filters are 10-100x slower then other standard implementations. While we do gain some benefits from our templated code, and compiler can do may thing to optimize it, your example and comment that it's "nearly as efficient" is incorrect. The operator[] method introduction a conditional and a exception element. When used in tight loop ( ie on a per-pixel basis), are not desirable, and prevent certain compiler optimizations such as auto-vectorization. While many have suggested using some type of class, I am now thinking that using a macro which either uses C99 VLA, or a heap allocation may be the easiest. Thanks, Brad On Mar 12, 2013, at 2:32 PM, "Williams, Norman K" <[email protected]> wrote: > I can't think of a single reason in ITK to use alloca. Pretty much every use > case for alloca can be implemented using C++ language features in a more > robust manner. > > Maybe it's unfair to say, but I think that the only reason it hasn't fallen > out of use entirely is the esteem in which it is held by certain programmers > associated with the GNU project. That's the one place it crept into VTK -- a > bison-generated parser they've been modifying for years. > > The following has been a workaround I've used since C++ hasn't supported > dynamically sized arrays in the past -- I believe it is a gnu extension > (that, by the way, uses alloca under the covers). Of course, in most cases, > it is preferable to use a STL container. I don't remember who said it first > but it's true: Arrays are to data what goto is to code. > > It is very nearly as efficient as raw array access, and the actual array is > on the heap: > > #include <cstddef> > > template <typename TElement> > class DynArray > { > public: > typedef std::size_t size_type; > DynArray(size_type numElements) : m_Size(numElements) > { > this->m_Array = new TElement[numElements]; > } > ~DynArray() > { > delete [] this->m_Array; > } > TElement &operator[](size_type idx) > { > if(idx > this->m_Size) > { > throw; > } > return this->m_Array[idx]; > } > const TElement &operator[](size_type idx) const > { > if(idx > this->m_Size) > { > throw; > } > return this->m_Array[idx]; > } > private: > TElement *m_Array; > size_type m_Size; > }; > > > -- > Kent Williams [email protected] > > > > > > On 3/12/13 7:54 AM, "Bradley Lowekamp" <[email protected]> wrote: > >> Hello, >> >> I am thinking about using the "alloca" function in some code I'm working on >> for ITK, and wonder what other people think of it or others experience... >> >> From the BSD Library Functions Manual: >> >> DESCRIPTION >> The alloca() macro allocates size bytes of space in the stack frame of >> the caller. This temporary space is automatically freed on return. >> >> I am planning on using it for some dimension sized array in compiled >> templateless code, in lieu of C99 dynamic stack based arrays. >> >> Best as I can tell Windows defines it as _alloca, so a little CMake try >> compile is going to be needed, not a big deal. >> >> Thanks, >> Brad >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Kitware offers ITK Training Courses, for more information visit: >> http://kitware.com/products/protraining.php >> >> Please keep messages on-topic and check the ITK FAQ at: >> http://www.itk.org/Wiki/ITK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.itk.org/mailman/listinfo/insight-developers >> > > > Notice: This UI Health Care e-mail (including attachments) is covered by the > Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential > and may be legally privileged. If you are not the intended recipient, you > are hereby notified that any retention, dissemination, distribution, or > copying of this communication is strictly prohibited. Please reply to the > sender that you have received the message in error, then delete it. Thank > you.
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
