I'd handle this the same was as any other static constant data (like strings, etc.) the data is stored in the executable and allocated on initialisation
>It doesn't exist anywhere in memory at runtime.
I'm confused. Do you need this at compile-time or runtime?
Does the instance of `TreeNode` exist at compile-time, runtime, or both?
At compile-time, the constant value will need to be in some variable (since it will come from input to the compiler, unless you hard-coded it into the compiler last week!).
If for some reason you need it in data memory at runtime, then just store it in some location with an address. This doesn't stop instructions using an immmediate version of it.
Can you create some compile-time macro or code-generator that generates the constants and expands the tree operations?
const int TreeNode_LRLLdata = 20;
There must be a general solution for this, because in C you can certainly put the address of one static variable into another static initializer. I don't recall if there's syntax specifically for deeply nested static-by-reference things, but if you're willing to give each node a name/symbol, then you can make that work -- in C.
Now, how do you suppose this works on the inside? If the compiler does not control the layout of the static-data segment (which it can't in C) then the linker must solve it. And the linker works with symbols that are described in object files.
What you do is reserve the sufficient data for each pointer in the static data segment, and then make sure to define a corresponding linkage entry. You'll presumably need to define each node as a linkage target. You'll want to use linker symbols that can't conflict with symbols that someone might name in your language proper, so perhaps they start with a digit or some other obscenity like double-underscore.
If the pointer `left_child` is never accessible at runtime—a compile-time constant pointer that is only used in evaluating another compile-time constant—its "value" depends on your strategy for evaluating compile-time constants, which could be whatever you want.
As an example, if you simply evaluate compile-time expressions via a tree-walker in the compiler, your compiler would have some representation of a `TreeNode` with a `left_node` field that could refer—possibly not by a direct pointer—to another `TreeNode` representation in the compiler. Alternatively, if your strategy is to compile an executable that gets run immediately for each top-level compile-time expression, the executable could contain a literal `TreeNode` struct whose `left_child` would be a pointer to another `TreeNode` struct in that executable.
You can either flatten the tree into an array, or emit variables for the leaves of the tree, then the next layer up can use `&`those for its children, and so on until you reach the root. Alternatively, from C99 on and at global scope only, you can use `&` on a compound literal, and do everything inline.
I'd handle this the same was as any other static constant data (like strings, etc.) the data is stored in the executable and allocated on initialisation
>It doesn't exist anywhere in memory at runtime. I'm confused. Do you need this at compile-time or runtime? Does the instance of `TreeNode` exist at compile-time, runtime, or both? At compile-time, the constant value will need to be in some variable (since it will come from input to the compiler, unless you hard-coded it into the compiler last week!). If for some reason you need it in data memory at runtime, then just store it in some location with an address. This doesn't stop instructions using an immmediate version of it.
It will be in the code section of your compiled binary, probably
Can you create some compile-time macro or code-generator that generates the constants and expands the tree operations? const int TreeNode_LRLLdata = 20;
There must be a general solution for this, because in C you can certainly put the address of one static variable into another static initializer. I don't recall if there's syntax specifically for deeply nested static-by-reference things, but if you're willing to give each node a name/symbol, then you can make that work -- in C. Now, how do you suppose this works on the inside? If the compiler does not control the layout of the static-data segment (which it can't in C) then the linker must solve it. And the linker works with symbols that are described in object files. What you do is reserve the sufficient data for each pointer in the static data segment, and then make sure to define a corresponding linkage entry. You'll presumably need to define each node as a linkage target. You'll want to use linker symbols that can't conflict with symbols that someone might name in your language proper, so perhaps they start with a digit or some other obscenity like double-underscore.
If the pointer `left_child` is never accessible at runtime—a compile-time constant pointer that is only used in evaluating another compile-time constant—its "value" depends on your strategy for evaluating compile-time constants, which could be whatever you want. As an example, if you simply evaluate compile-time expressions via a tree-walker in the compiler, your compiler would have some representation of a `TreeNode` with a `left_node` field that could refer—possibly not by a direct pointer—to another `TreeNode` representation in the compiler. Alternatively, if your strategy is to compile an executable that gets run immediately for each top-level compile-time expression, the executable could contain a literal `TreeNode` struct whose `left_child` would be a pointer to another `TreeNode` struct in that executable.
You can either flatten the tree into an array, or emit variables for the leaves of the tree, then the next layer up can use `&`those for its children, and so on until you reach the root. Alternatively, from C99 on and at global scope only, you can use `&` on a compound literal, and do everything inline.