www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Length of fixed size arrays

reply "Benjamin Thaut" <code benjamin-thaut.de> writes:
Do we already have something like this in phobos? If not should 
we add it? I'm not quite sure if the .length property of a static 
array is always a compile time constant.

I use something similar in C++ quite often.

template staticLength(alias symbol)
{
   enum size_t staticLength = staticLengthImpl!(typeof(symbol));
}

template staticLengthImpl(T : U[N], U, size_t N)
{
   enum size_t staticLengthImpl = N;
}

template staticLengthImpl(T)
{
   static assert(0, T.stringof ~ " is not an static array");
}

Kind Regards
Benjamin Thaut
Nov 17 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/17/12, Benjamin Thaut <code benjamin-thaut.de> wrote:
 I'm not quite sure if the .length property of a static
 array is always a compile time constant.

When is it not a constant?
Nov 17 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Benjamin Thaut:

 I'm not quite sure if the .length property of a static array is 
 always a compile time constant.

Currently it's always a compile-time constant. But I have asked for some kind of Variable Length arrays allocated on the stack, as in C99, because using alloca() to create a 2D array on the stack is not good, it's noisy, unsafe and bug-prone. In this case their length is contained in some scoped variable or in an argument, at run-time. They are discussing VLAs again for C++14: http://root.cern.ch/drupal/content/c14 Bye, bearophile
Nov 17 2012
prev sibling next sibling parent "Benjamin Thaut" <code benjamin-thaut.de> writes:
On Saturday, 17 November 2012 at 16:55:46 UTC, Andrej Mitrovic 
wrote:
 On 11/17/12, Benjamin Thaut <code benjamin-thaut.de> wrote:
 I'm not quite sure if the .length property of a static
 array is always a compile time constant.

When is it not a constant?

I had a problem in the past where it complained that accessing the length is not possible without a instance. But that could have been a bug. Kind Regards Benjamin Thaut
Nov 17 2012
prev sibling next sibling parent "Benjamin Thaut" <code benjamin-thaut.de> writes:
On Saturday, 17 November 2012 at 17:10:40 UTC, bearophile wrote:
 Benjamin Thaut:

 I'm not quite sure if the .length property of a static array 
 is always a compile time constant.

Currently it's always a compile-time constant. But I have asked for some kind of Variable Length arrays allocated on the stack, as in C99, because using alloca() to create a 2D array on the stack is not good, it's noisy, unsafe and bug-prone. In this case their length is contained in some scoped variable or in an argument, at run-time. They are discussing VLAs again for C++14: http://root.cern.ch/drupal/content/c14 Bye, bearophile

That would be nice, but a bigger problem I'm currently having, is that you can not initialize fixed size arrays like this: int[4] bla = [1,2,3,4]; Without causing a allocation. The literal will be allocated on the heap, then copied onto the stack, and then it will become garbage. Kind Regards Benjamin Thaut
Nov 17 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 17, 2012 17:55:37 Andrej Mitrovic wrote:
 On 11/17/12, Benjamin Thaut <code benjamin-thaut.de> wrote:
 I'm not quite sure if the .length property of a static
 array is always a compile time constant.

When is it not a constant?

It's always a constant. The length of static arrays must always be known at compile time. - Jonathan M Davis
Nov 17 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 17, 2012 18:19:50 Benjamin Thaut wrote:
 That would be nice, but a bigger problem I'm currently having, is
 that you can not initialize fixed size arrays like this:
 
 int[4] bla = [1,2,3,4];
 
 Without causing a allocation. The literal will be allocated on
 the heap, then copied onto the stack, and then it will become
 garbage.

It's a well-known issue and will be fixed at some point. I suspect that it's simply a matter of one of the compiler devs making it a priority, but I don't know what all is involved in making the change. Certainly, it's an implementation issue rather than a language issue. My guess though is that it hasn't been tackled primarily because it's a performance issue, whereas so many other bugs actually result in incorrect programs. - Jonathan M Davis
Nov 17 2012