www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How the memory layout of global variable is reliable ?

reply "Cjkp" <Cjkp nowhere.fr> writes:
Hello, I have an idea about a small code tool related to the 
application resources.
It would rely on the assumption that some global variabled, 
sharing the same type and attributes, declared in group, are 
contiguous.

In short I need to know if the following assertions are always 
true and reliable over time:

--------------
import std.stdio;

// used as base adress
static string beg = "";
// arbitrary generated by a tool and mixed at compile time.
static string a = "";
static string b = "";
static string c = "";
static string d = "";
static string e = "";
static string f = "";

void main(string args[])
{
     void* offs = &beg;
     assert( &a == (offs + (size_t.sizeof * 2) * 1) ); // length + 
ptr
     assert( &b == (offs + (size_t.sizeof * 2) * 2) ); // length + 
ptr
     assert( &c == (offs + (size_t.sizeof * 2) * 3) ); // etc.
     assert( &d == (offs + (size_t.sizeof * 2) * 4) );
}
--------------

In a second time I need to be sure that the return tuple of the 
trait "allMembers" follow the declarations order. The 
documentation says that:

"The order in which the strings appear in the result is not 
defined".

But so far, it looks like it's ordered according to the 
declaration (at least for a module containing only some global 
variables).

Any other remarks about the topic are welcome.
Oct 22 2014
parent reply "Freddy" <Hexagonalstar64 gmail.com> writes:
On Wednesday, 22 October 2014 at 20:29:58 UTC, Cjkp wrote:

 Hello, I have an idea about a small code tool related to the 
 application resources.
 It would rely on the assumption that some global variabled, 
 sharing the same type and attributes, declared in group, are 
 contiguous.

 In short I need to know if the following assertions are always 
 true and reliable over time:

 --------------
 import std.stdio;

 // used as base adress
 static string beg = "";
 // arbitrary generated by a tool and mixed at compile time.
 static string a = "";
 static string b = "";
 static string c = "";
 static string d = "";
 static string e = "";
 static string f = "";

 void main(string args[])
 {
     void* offs = &beg;
     assert( &a == (offs + (size_t.sizeof * 2) * 1) ); // length 
 + ptr
     assert( &b == (offs + (size_t.sizeof * 2) * 2) ); // length 
 + ptr
     assert( &c == (offs + (size_t.sizeof * 2) * 3) ); // etc.
     assert( &d == (offs + (size_t.sizeof * 2) * 4) );
 }
 --------------

 In a second time I need to be sure that the return tuple of the 
 trait "allMembers" follow the declarations order. The 
 documentation says that:

 "The order in which the strings appear in the result is not 
 defined".

 But so far, it looks like it's ordered according to the 
 declaration (at least for a module containing only some global 
 variables).

 Any other remarks about the topic are welcome.


Plese don't do this, it's undefined behavior and could make you
code invalid with a new compiler release or different compiler.
If possible use static arrays instead.
----
int[2] arr=[1,2];
 property auto ref b(){
      return arr[1];
}
---
Oct 22 2014
parent reply "Cjkp" <Cjkp nowhere.fr> writes:
On Wednesday, 22 October 2014 at 20:37:43 UTC, Freddy wrote:

 On Wednesday, 22 October 2014 at 20:29:58 UTC, Cjkp wrote:

 Hello, I have an idea about a small code tool related to the 
 application resources.
 It would rely on the assumption that some global variabled, 
 sharing the same type and attributes, declared in group, are 
 contiguous.

 In short I need to know if the following assertions are always 
 true and reliable over time:

 --------------
 import std.stdio;

 // used as base adress
 static string beg = "";
 // arbitrary generated by a tool and mixed at compile time.
 static string a = "";
 static string b = "";
 static string c = "";
 static string d = "";
 static string e = "";
 static string f = "";

 void main(string args[])
 {
    void* offs = &beg;
    assert( &a == (offs + (size_t.sizeof * 2) * 1) ); // length 
 + ptr
    assert( &b == (offs + (size_t.sizeof * 2) * 2) ); // length 
 + ptr
    assert( &c == (offs + (size_t.sizeof * 2) * 3) ); // etc.
    assert( &d == (offs + (size_t.sizeof * 2) * 4) );
 }
 --------------

 In a second time I need to be sure that the return tuple of 
 the trait "allMembers" follow the declarations order. The 
 documentation says that:

 "The order in which the strings appear in the result is not 
 defined".

 But so far, it looks like it's ordered according to the 
 declaration (at least for a module containing only some global 
 variables).

 Any other remarks about the topic are welcome.


 Plese don't do this, it's undefined behavior and could make you
 code invalid with a new compiler release or different compiler.
 If possible use static arrays instead.
 ----
 int[2] arr=[1,2];
  property auto ref b(){
      return arr[1];
 }
 ---


I've probably badly explained the what and the why. I ask this 
because of this draft: http://dpaste.dzfl.pl/e15305cbc32d

Tool: generate a module with some static strings. (used as 
ressources, e.g pictures, tables, etc.)
Manager: use the first item as base address since the other are 
using the import expression.

Actually I don't get the sample you added to your answer, that 
leads me to think that my initial Question is not well exposed.
Oct 23 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 23 Oct 2014 07:55:36 +0000
Cjkp via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:


 I've probably badly explained the what and the why. I ask this=20
 because of this draft: http://dpaste.dzfl.pl/e15305cbc32d
=20
 Tool: generate a module with some static strings. (used as=20
 ressources, e.g pictures, tables, etc.)
 Manager: use the first item as base address since the other are=20
 using the import expression.
=20
 Actually I don't get the sample you added to your answer, that=20
 leads me to think that my initial Question is not well exposed.
=20


why do you want all that voodoo? ain't it easier to make your tool
generate something like "resource list array" too?
Oct 23 2014
parent "Cjkp" <Cjkp somewhere.fr> writes:
On Thursday, 23 October 2014 at 08:04:23 UTC, ketmar via 
Digitalmars-d-learn wrote:

 On Thu, 23 Oct 2014 07:55:36 +0000
 Cjkp via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com> wrote:


 I've probably badly explained the what and the why. I ask this 
 because of this draft: http://dpaste.dzfl.pl/e15305cbc32d
 
 Tool: generate a module with some static strings. (used as 
 ressources, e.g pictures, tables, etc.)
 Manager: use the first item as base address since the other 
 are using the import expression.
 
 Actually I don't get the sample you added to your answer, that 
 leads me to think that my initial Question is not well exposed.
 


 why do you want all that voodoo? ain't it easier to make your 
 tool
 generate something like "resource list array" too?


Not wrong, I realize that I've been biased by being stubborn on 
my initial idea (which is: using the traits to link a member name 
to a pointer).
Oct 23 2014