www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Stack or heap?

reply Florian Sonnenberger <florian sonnenberger-wolnzach.de> writes:
Hello, I'm this week's newbie.
I discovered D while searching for a free C++ compiler a few months ago 
and I'm very thankful for this powerful language.


My program needs 3 associative arrays ( ubyte[char[]] ) with 256 
elements each. The strings are maximum 10 chars. The arrays should be 
const but unfortunately this isn't possible yet.

-Should I make them static or normal? Would it be the same in my case?

-Should they be on the heap or is the space on the stack enough? I have 
no idea of this memory allocation stuff since I came from Visual Basic.

I hope Walter will add the nice initialisation soon.
const ubyte[char[]] foo = [ "Foo":2, "Fooo":3, "Fooooo":5 ]


I also would suggest to make  static class  an error or at least a 
warning. I was wondering what the static in front of a class declaration 
could mean untill I read it in the docs:
 (...) Static is ignored when applied to other declarations.

should be an error. I want to know what the compiler does and what not. Thanks for your responses. Florian
Mar 29 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Florian Sonnenberger wrote:
 This is confusing. If static class makes no sense to the compiler, it 
 should be an error. I want to know what the compiler does and what not.

The trouble would come from D's "block attributes". Consider: # private static: # void someUtility() { ... } # void another() { ... } # class Foo { ... } To make things like this work fine without extra typing, DMD's philosophy is, if the attribute doesn't make sense, ignore it. Although it might possibly be worth having a Warning about it, along the lines of "somefile(0): attribute 'static' ignored in this context" *shrug* -- Chris Sauls
Mar 29 2005
parent reply Florian Sonnenberger <florian sonnenberger-wolnzach.de> writes:
Chris Sauls wrote:
 Florian Sonnenberger wrote:

 This is confusing. If static class makes no sense to the compiler, it
 should be an error. I want to know what the compiler does and what
 not.

The trouble would come from D's "block attributes". Consider: # private static: # void someUtility() { ... } # void another() { ... } # class Foo { ... } To make things like this work fine without extra typing, DMD's philosophy is, if the attribute doesn't make sense, ignore it.

OK, I see. Another thing about the block attributes: # module test; # # int someNumber() { ... } // This is public (1) # # static: # void someThing() { ... } // This is public static (2) # # # private: # class Foo { ... } // This is private (3) # # static: # void someUtility() { ... } // Is this private static # // or public static (4) # # private static: # void another() { ... } // This is private static (5) (1)In module scope everything without a private,protected,... is public. (2)If I set it static then it's public static. (3)If I set it private, the "static:" isn't kept and so it's private. ->(4)If I set it static, is the "private:" kept or not? (5)If I set it private static then it's private static.
 Although it might possibly be worth having a Warning about it, along 

 "somefile(0): attribute 'static' ignored in this context"

Or more exact: "somefile(0): attribute 'static' ignored in class declarations" BTW: Is it also ignored in # static const int bar = 123; Then your warning might be better.
 *shrug*
 -- Chris Sauls

Thanks, Florian
Mar 30 2005
parent Chris Sauls <ibisbasenji gmail.com> writes:
Florian Sonnenberger wrote:
 Another thing about the block attributes:
 
 # private:
 # class Foo { ... }          // This is private (3)
 #
 # static:
 # void someUtility() { ... } // Is this private static

It is my understanding that it will be private static. As far as I know any attribute set with the "attr:" syntax continues unbroken until another attribute (of the same 'class' or whatever) usurps it, or until the current scope ends. -- Chris Sauls
Mar 30 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Florian Sonnenberger" <florian sonnenberger-wolnzach.de> wrote in message 
news:d2bvlu$1pth$1 digitaldaemon.com...
 My program needs 3 associative arrays ( ubyte[char[]] ) with 256 elements 
 each. The strings are maximum 10 chars. The arrays should be const but 
 unfortunately this isn't possible yet.
 -Should I make them static or normal? Would it be the same in my case?
 -Should they be on the heap or is the space on the stack enough? I have no 
 idea of this memory allocation stuff since I came from Visual Basic.

All arrays in D are on the heap (unless you use some *really* ugly hacks). The only part of the array that sits on the stack is the array reference, which is all of 8 bytes (4 bytes for length, 4 bytes for a pointer to the data). Making the array static will have little effect. If you declare the array inside a function as static, it means the array will be preserved between calls to the function. If you declare the array as a static global, it doesn't do anything differently. It may put the array reference in the data segment of the program, but that wouldn't get you much.
Mar 29 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Jarrett Billingsley wrote:
 "Florian Sonnenberger" <florian sonnenberger-wolnzach.de> wrote in message 
 news:d2bvlu$1pth$1 digitaldaemon.com...
 
 All arrays in D are on the heap (unless you use some *really* ugly hacks). 
 The only part of the array that sits on the stack is the array reference, 
 which is all of 8 bytes (4 bytes for length, 4 bytes for a pointer to the 
 data).

I suspect that you are correct when it comes to associative arrays, though I don't know for sure. However, your statement is definitely not correct for all arrays. Arrays of fixed length can be put on the stack. (And, obviously, dynamic arrays can be set to point at fixed length arrays, so long as you don't append to or extend them.)
Mar 29 2005
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message 
news:d2cg3n$2c9s$1 digitaldaemon.com...
 I suspect that you are correct when it comes to associative arrays, though 
 I don't know for sure.  However, your statement is definitely not correct 
 for all arrays.  Arrays of fixed length can be put on the stack. (And, 
 obviously, dynamic arrays can be set to point at fixed length arrays, so 
 long as you don't append to or extend them.)

Well there's a 'gotcha'. Though looking at the AA source in src/phobos/internal/aaA.d, it does look as though everything is created on the heap with 'new'.
Mar 29 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 29 Mar 2005 18:27:50 +0200, Florian Sonnenberger wrote:

 Hello, I'm this week's newbie.
 I discovered D while searching for a free C++ compiler a few months ago 
 and I'm very thankful for this powerful language.
 
 
 My program needs 3 associative arrays ( ubyte[char[]] ) with 256 
 elements each. The strings are maximum 10 chars. The arrays should be 
 const but unfortunately this isn't possible yet.
 
 -Should I make them static or normal? Would it be the same in my case?

I believe that 'static' means that there is only one instance of the data in existence during the run-time life of the program, and that is on the heap, and is permanently allocated to the scope it is declared in.
 -Should they be on the heap or is the space on the stack enough? I have 
 no idea of this memory allocation stuff since I came from Visual Basic.

You have no choice. Arrays are held on the heap. However, the array reference is on the stack if it is declared inside a function without the static attribute. An array reference is 8 bytes long on 32-bit machines and will be 16 bytes on 64-bit machines. When you declare an array, you are actually defining an array reference 'structure'. It is as if it was a struct { size_t length; <type>* ptr; } and the ptr field points to data on the heap. If you declare it as static, or declare it in the module scope (not in a function), the array reference also lives on the heap.
 I hope Walter will add the nice initialisation soon.
 const ubyte[char[]] foo = [ "Foo":2, "Fooo":3, "Fooooo":5 ]

Amen to that.
 I also would suggest to make  static class  an error or at least a 
 warning. I was wondering what the static in front of a class declaration 
 could mean untill I read it in the docs:
 (...) Static is ignored when applied to other declarations.

should be an error. I want to know what the compiler does and what not.

This is just a nicety so we can have block-scoped attributes without the hassle of too many messages. private { static { int abc; class foo {. . .} } long xyz; } -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 30/03/2005 7:23:58 AM
Mar 29 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 30 Mar 2005 07:24:04 +1000, Derek Parnell wrote:


[snip]
 
 -Should they be on the heap or is the space on the stack enough? I have 
 no idea of this memory allocation stuff since I came from Visual Basic.

You have no choice. Arrays are held on the heap.

Oops! Russ is correct. My previous comments are for dynamic arrays. Fixed arrays can live on the stack if they are declared inside a function scope without the static attribute. Associative arrays are always dynamic arrays; there are no fixed length associative arrays (yet?). -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 30/03/2005 7:27:59 AM
Mar 29 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1fcs19ene2ob1.1bhkftcf383b5
 there are no fixed length associative arrays (yet?).

Ooh, would that be cool. They could just compile to constants. Mmmmm....
Mar 29 2005
prev sibling parent Florian Sonnenberger <florian sonnenberger-wolnzach.de> writes:
Derek Parnell wrote:
 On Wed, 30 Mar 2005 07:24:04 +1000, Derek Parnell wrote:
 
 
 [snip]
  
 
-Should they be on the heap or is the space on the stack enough? I have 
no idea of this memory allocation stuff since I came from Visual Basic.

You have no choice. Arrays are held on the heap.

Oops! Russ is correct. My previous comments are for dynamic arrays. Fixed arrays can live on the stack if they are declared inside a function scope without the static attribute. Associative arrays are always dynamic arrays; there are no fixed length associative arrays (yet?).

I found out that it's complicated to search a part of the string in an associative array. I must search for those very often and so I think it's better to take an array of strings in this case, but nevertheless thank you for your explanations. Are there any good functions in Phobos (or other libs) that can search for a string in each element of a string array? Such as:
 import std.string;
 
 int findInArray(char[][] array, char[] string)
 {
     foreach(int i, char[] element; array)
     {
         if (find(element,inout string) != -1) return i;
     };
     return -1;
 };

Florian
Mar 30 2005