www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - static array length

reply "Saaa" <empty needmail.com> writes:
Isn't it possible to make the .length variable for static arrays.
Its ofcourse an error to make it longer than the original size (extra 
property?)

char[100] c;
c[0..4]='1234`;

and maybe this:
c=`1234`; // implicit length adjustment.

Or would this break something?
Jan 29 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Saaa:

 Isn't it possible to make the .length variable for static arrays.
 Its ofcourse an error to make it longer than the original size (extra 
 property?)
 char[100] c;
 c[0..4]='1234`;
 
 and maybe this:
 c=`1234`; // implicit length adjustment.
 Or would this break something?


Thanks to your questions the thread regarding the string literals have shown me
that there are things I have to learn still regarding strings, but you can
answer most of your own questions when you know a bit what the hidden array
implementation is. Static arrays are nude chunks of data (probably with some
information for the GC and sometimes the memory allocator of the OS too),
probably allocated on the stack with alloca(), while dynamic arrays are structs
of <pointer, length> allocated on the stack that point to a chunk of memory on
the heap (I don't know if this is true for string literals too). The length of
the static array is a compile time constant, and it's virtual at runtime, so
you can't change it at runtime. (Tuples too exists only at compile time. At
runtime they are just a scattered group of variables with a common way to index
them).
Often knowing how things are implemented and run on the level just below the
one you use is all you need to program effectively :-)

Bye,
bearophile
Jan 30 2008
parent reply "Saaa" <empty needmail.com> writes:
A static string still has the .length info somewhere.
Thinking about it again, it won't work on static multidimentional arrays as 
changing one of the lengths would corrupt the way data is accessed.
I don't suggest that the actual internal size of the array would be changed, 
just the .length value.
It would make working with strings a lot simpler, or maybe I'm missing some 
nice way to do this:
char[100] c;
c=`1234`;
writefln(c); //even with c[0..4]=`1234`, this will crash



 Saaa:

 Isn't it possible to make the .length variable for static arrays.
 Its ofcourse an error to make it longer than the original size (extra
 property?)
 char[100] c;
 c[0..4]='1234`;

 and maybe this:
 c=`1234`; // implicit length adjustment.
 Or would this break something?


 Thanks to your questions the thread regarding the string literals have 
 shown me that there are things I have to learn still regarding strings, 
 but you can answer most of your own questions when you know a bit what the 
 hidden array implementation is. Static arrays are nude chunks of data 
 (probably with some information for the GC and sometimes the memory 
 allocator of the OS too), probably allocated on the stack with alloca(), 
 while dynamic arrays are structs of <pointer, length> allocated on the 
 stack that point to a chunk of memory on the heap (I don't know if this is 
 true for string literals too). The length of the static array is a compile 
 time constant, and it's virtual at runtime, so you can't change it at 
 runtime. (Tuples too exists only at compile time. At runtime they are just 
 a scattered group of variables with a common way to index them).
 Often knowing how things are implemented and run on the level just below 
 the one you use is all you need to program effectively :-)

 Bye,
 bearophile
Jan 31 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Saaa:

 A static string still has the .length info somewhere.


The compiler knows it, but it may be absent in the compiled code.

Bye,
bearophile
Jan 31 2008
parent reply "Saaa" <empty needmail.com> writes:
Are you sure about this?
Because I can do:
writefln(c.length);



 Saaa:

 A static string still has the .length info somewhere.


 The compiler knows it, but it may be absent in the compiled code.

 Bye,
 bearophile
Jan 31 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Saaa wrote:

 Are you sure about this?
 Because I can do:
 writefln(c.length);


If you disassemble it, it might be:
writefln(some_integer_constant);
Jan 31 2008
parent reply "Saaa" <empty needmail.com> writes:
Ok, thanks :)
that just leaves me with a good way to do this:

char[100] c;
c[0..4]=`1234`;
writefln(c);


 Saaa wrote:

 Are you sure about this?
 Because I can do:
 writefln(c.length);


 If you disassemble it, it might be:
 writefln(some_integer_constant);
Jan 31 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Saaa" <empty needmail.com> wrote in message 
news:fnsgfv$1gti$1 digitalmars.com...

 Ok, thanks :)
 that just leaves me with a good way to do this:

 char[100] c;
 c[0..4]=`1234`;
 writefln(c);


c[0 .. 4] = `1234`;
char[] d = c[0 .. 4];
writefln(d);
Jan 31 2008
parent reply "Saaa" <empty needmail.com> writes:
If I'd know the lenght I would just do :)

c[0 .. 4] = `1234`;
writefln( c[0 .. 4]);

I'm looking into making use of:
struct charS{
    char c;
    int leng;
}



 c[0 .. 4] = `1234`;
 char[] d = c[0 .. 4];
 writefln(d);
Jan 31 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Saaa" <empty needmail.com> wrote in message 
news:fnsmjb$1vsq$1 digitalmars.com...

 If I'd know the lenght I would just do :)

 c[0 .. 4] = `1234`;
 writefln( c[0 .. 4]);

 I'm looking into making use of:
 struct charS{
    char c;
    int leng;
 }


So, in other words, you're re-implementing dynamic arrays?

What I'm wondering is why you need this?  What is it that you're trying to 
do?
Jan 31 2008
parent reply "Saaa" <empty needmail.com> writes:
Except that it will be on the stack :)

I'll be testing the speed difference.


 So, in other words, you're re-implementing dynamic arrays?

 What I'm wondering is why you need this?  What is it that you're trying to 
 do?
Jan 31 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Saaa" <empty needmail.com> wrote in message 
news:fntlub$1iq8$1 digitalmars.com...

 Except that it will be on the stack :)

 I'll be testing the speed difference.


So you want a string buffer on the stack, or what?  If it's on the stack and 
you're doing a lot of operations that would otherwise involve 
concatenations, it'll be faster.  If it's in a function that's called a lot, 
it'll be faster, since no heap allocation will occur.  But, then you're 
limited by the size of the array, and you can't use the same things -- no 
concatenations, namely.

It's a tradeoff of syntactic niceness and flexibility of size vs. speed.
Jan 31 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Saaa:

 I'll be testing the speed difference.


You can allocate memory on the stack with alloca() too.
It may sound strange, but iterating on a dynamic array is often a bit faster.

Bye,
bearophile
Jan 31 2008
parent reply "Saaa" <empty needmail.com> writes:
Yes, that does sound strange.
Do you know why this is the case?


 You can allocate memory on the stack with alloca() too.
 It may sound strange, but iterating on a dynamic array is often a bit 
 faster.

 Bye,
 bearophile
Feb 01 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Saaa:

 Yes, that does sound strange.
 Do you know why this is the case?


I don't know why, but you can write a little benchmark in 5 minutes to see if
it's true on your PC too :-)

Bye,
bearophile
Feb 01 2008
parent "Saaa" <empty needmail.com> writes:
I'll do that, but my computer isn't that prototypical that I can use the 
outcome as a standard for all my customers :D


 Yes, that does sound strange.
 Do you know why this is the case?


 I don't know why, but you can write a little benchmark in 5 minutes to see 
 if it's true on your PC too :-)

 Bye,
 bearophile
Feb 01 2008
prev sibling parent downs <default_357-line yahoo.de> writes:
Saaa wrote:

 A static string still has the .length info somewhere.


Nope - if it's static, the length info is derived from the type - so if you
type "foob".length, that's replaced at compile time.

 --downs
Jan 31 2008