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.


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.

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:






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:






 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:



















(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 


the lines of

 "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


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:
 







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.


 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.


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;
 };


but faster. Perhaps with a modified binary search algorithm?

Florian
Mar 30 2005