digitalmars.D.learn - How the memory layout of global variable is reliable ?
- Cjkp (38/38) Oct 22 2014 Hello, I have an idea about a small code tool related to the
- Freddy (10/48) Oct 22 2014 Plese don't do this, it's undefined behavior and could make you
- Cjkp (9/65) Oct 23 2014 I've probably badly explained the what and the why. I ask this
- ketmar via Digitalmars-d-learn (4/15) Oct 23 2014 why do you want all that voodoo? ain't it easier to make your tool
- Cjkp (5/22) Oct 23 2014 Not wrong, I realize that I've been biased by being stubborn on
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
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
On Wednesday, 22 October 2014 at 20:37:43 UTC, Freddy wrote:On Wednesday, 22 October 2014 at 20:29:58 UTC, Cjkp 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.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 23 2014
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. =20why do you want all that voodoo? ain't it easier to make your tool generate something like "resource list array" too?
Oct 23 2014
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: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).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?
Oct 23 2014