New adopted paper: N3639, Runtime-Sized Arrays with Automatic Storage Duration (Rev5) -- Jens Maurer

Save to:
Instapaper Pocket Readability

Note: This paper was adopted into draft C++14 on Saturday at the Bristol UK ISO C++ meeting.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3639

Date: 2013-04-16

Runtime-sized arrays with automatic storage duration (revision 5)

by Jens Maurer

See also related paper N3662, "C++ Dynamic Arrays (dynarray)"

Excerpt:

Sometimes, a user wishes to allocate a local array whose size is not known at compile-time, but at runtime only. Nonetheless, the array's size will remain unchanged during the lifetime of the array.

Examples are

  • interfacing with the readv/writev POSIX system calls
  • small runtime-sized data structure to apply STL algorithms calls
  • ...

This paper proposes to add local runtime-sized arrays with automatic storage duration to C++, for example:
void f(std::size_t n)
{
   int a[n];
   for (std::size_t i = 0; i < n; ++i)
       a[i] = 2*i;
   std::sort(a, a+n);
}

Traditionally, the array bound "n" had to be a constant expression (see 8.3.4 dcl.array). For local arrays with automatic storage duration, this paper proposes to lift that restriction. The syntax is intended to be the same as that used for C99 variable length arrays (VLAs), except that implementation support for VLAs is optional in C11 and aggregate initialization is not supported in C.

As a design guideline, the same rules should apply to "new T[n]" and a local array "T a[n]", except that arrays of zero size are only supported for new.

There is well-established existing practice with gcc, Clang, and Intel C++ all implementing a similar, if not identical feature. In fact, Douglas Gregor reported in c++std-ext-12553 on 2012-01-30: "Users really seem to want this feature. It's a fairly common extension, and when we tried to ban it out of principle (in Clang), our users reacted *very* strongly."

Add a Comment

Comments are closed.

Comments (0)

There are currently no comments on this entry.