<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Kent,<div><br></div><div>Your initial statement seems to be an absolute ( similar to a never, or always ), these frequently are a bit short sighted.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><a href="http://review.source.kitware.com/#/c/10059/6/Modules/Core/Common/include/itkImageRegionSplitterBase.h">http://review.source.kitware.com/#/c/10059/6/Modules/Core/Common/include/itkImageRegionSplitterBase.h</a></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Brad</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Mar 12, 2013, at 2:32 PM, "Williams, Norman K" <<a href="mailto:norman-k-williams@uiowa.edu">norman-k-williams@uiowa.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<div style="word-wrap:break-word">
<div>
<div><font class="Apple-style-span" face="Consolas,monospace">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.</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace"><br>
</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace">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.</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace"><br>
</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace">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.</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace"><br>
</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace">It is very nearly as efficient as raw array access, and the actual array is on the heap:</font></div>
<div><font class="Apple-style-span" face="Consolas,monospace">
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><br>
</div>
<div>
<div>#include <cstddef></div>
<div><br>
</div>
<div>template <typename TElement></div>
<div>class DynArray</div>
<div>{</div>
<div>public:</div>
<div> typedef std::size_t size_type;</div>
<div> DynArray(size_type numElements) : m_Size(numElements)</div>
<div> {</div>
<div> this->m_Array = new TElement[numElements];</div>
<div> }</div>
<div> ~DynArray()</div>
<div> {</div>
<div> delete [] this->m_Array;</div>
<div> }</div>
<div> TElement &operator[](size_type idx)</div>
<div> {</div>
<div> if(idx > this->m_Size)</div>
<div> {</div>
<div> throw;</div>
<div> }</div>
<div> return this->m_Array[idx];</div>
<div> }</div>
<div> const TElement &operator[](size_type idx) const</div>
<div> {</div>
<div> if(idx > this->m_Size)</div>
<div> {</div>
<div> throw;</div>
<div> }</div>
<div> return this->m_Array[idx];</div>
<div> }</div>
<div>private:</div>
<div> TElement *m_Array;</div>
<div> size_type m_Size;</div>
<div>};</div>
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><br>
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><br>
</div>
</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace">-- </font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace">Kent Williams <a href="mailto:norman-k-williams@uiowa.edu">norman-k-williams@uiowa.edu</a></font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace"><br>
</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace"><br>
</font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px; "><font class="Apple-style-span" face="Consolas,monospace"><br>
</font></div>
<div style="font-family: Consolas, monospace; font-size: 12px; "><br>
</div>
</div>
<div style="font-family: Consolas, monospace; font-size: 12px; "><br>
</div>
<div style="font-family: Consolas, monospace; font-size: 12px; ">On 3/12/13 7:54 AM, "Bradley Lowekamp" <<a href="mailto:blowekamp@mail.nih.gov">blowekamp@mail.nih.gov</a>> wrote:</div>
<div style="font-family: Consolas, monospace; font-size: 12px; "><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="font-family: Consolas, monospace; font-size: 12px; border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding: 0px 0px 0px 5px; margin: 0px 0px 0px 5px; " type="cite">
<div>Hello,</div>
<div><br>
</div>
<div>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...</div>
<div><br>
</div>
<div>From the BSD Library Functions Manual:</div>
<div><br>
</div>
<div>DESCRIPTION</div>
<div> The alloca() macro allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed on return.</div>
<div><br>
</div>
<div>I am planning on using it for some dimension sized array in compiled templateless code, in lieu of C99 dynamic stack based arrays.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Brad </div>
<div>_______________________________________________</div>
<div>Powered by <a href="http://www.kitware.com">www.kitware.com</a></div>
<div><br>
</div>
<div>Visit other Kitware open-source projects at</div>
<div><a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a></div>
<div><br>
</div>
<div>Kitware offers ITK Training Courses, for more information visit:</div>
<div><a href="http://kitware.com/products/protraining.php">http://kitware.com/products/protraining.php</a></div>
<div><br>
</div>
<div>Please keep messages on-topic and check the ITK FAQ at:</div>
<div><a href="http://www.itk.org/Wiki/ITK_FAQ">http://www.itk.org/Wiki/ITK_FAQ</a></div>
<div><br>
</div>
<div>Follow this link to subscribe/unsubscribe:</div>
<div><a href="http://www.itk.org/mailman/listinfo/insight-developers">http://www.itk.org/mailman/listinfo/insight-developers</a></div>
<div><br>
</div>
</blockquote>
<br>
<br>
<hr>
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.
<hr>
</div>
</blockquote></div><br></div></body></html>