[MOAB-dev] [Fathom] variable-length arrays

[Jason Kraftcheck]

James Porter wrote:
> On Tue, 2009-11-17 at 13:48 -0600, Jason Kraftcheck wrote:
>> It is possible to get the same functionality in c++ using std::vector
>> (except for arrays of bool, and assuming the time to zero the memory isn't
>> significant).  However, std::vector allocates storage on the heap while a
>> automatic array will (typically) be allocated on the stack.  For a few cases
>> involving tight loops where the performance with heap allocation is
>> unacceptable, it would be nice to be able to use var-len auto arrays.
> 
> Is alloca() unacceptable? 

I believe there are more portability issues with alloca, as it is a glibc
extension that is not part of any standard.

> That would explicitly require stack
> allocation, whereas VLAs generally only do so because it's easier in the
> context of a C compiler (no need to try to shoehorn in C++
> stack-unwinding semantics to call free()). For implementations that do
> put VLAs on the stack, alloca() is (in effect) what they'll use.
> 

The scope of the memory is also much more clear (less error prone) with VLAs
then with alloca().

> Both stack-allocated VLAs and alloca() obviously have the same concerns
> about stack overflows and all that, but for arrays whose size is known
> to be small, they should be safe.
> 
>> We have not this feature anywhere in MOAB or CGM so far because of possible
>> portability issues.  Does anyone have any experience with using
>> variable-length automatic arrays in C++ code that is built on diverse systems?
> 
> This would pretty much irrevocably break compilation in MSVC, which
> probably isn't a *major* problem, but it's something to consider.
> Microsoft has explicitly stated that they have no real interest in C99
> support.
> 

I just tried it in VC++ 2008 and the compiler seems to implement this feature.

- jason