There may be other limitations as well, but I think of it as a question of where to store the object after compilation, but before runtime.
Clearly, it must be saved in the compiled artifact itself. We have an example of this already with string literals. This is part of the compiled artifact, and cannot be changed at runtime. So, in theory we could allow compile time allocations to be accessed at runtime, on the condition that they are never deallocated.
However, this would introduce a large complication. Objects may contain pointers to other objects, where string literals cannot contain pointers to other string literals. We don’t know where the artifact will be loaded into memory, so those pointers may not be valid. To support them, they would need to be updated as the artifact is being loaded.
There is precedent for this, as updating pointers when loading a library is one way to implement shared libraries. However, shared libraries only require this for externally-exposed symbols. Internal function calls can use relative jumps instead. For saving an object, which may contain pointers to itself, private objects would also need to have their pointers updated, which would add to the overhead. So, rather than requiring compilers to add what amounts to an additional dynamic-linking step, the standard forbids the runtime use of a compile time allocation altogether.
(At least, that’s my overall understanding, and I would be happy to be corrected on it if wrong.)
Clearly, it must be saved in the compiled artifact itself. We have an example of this already with string literals. This is part of the compiled artifact, and cannot be changed at runtime. So, in theory we could allow compile time allocations to be accessed at runtime, on the condition that they are never deallocated.
However, this would introduce a large complication. Objects may contain pointers to other objects, where string literals cannot contain pointers to other string literals. We don’t know where the artifact will be loaded into memory, so those pointers may not be valid. To support them, they would need to be updated as the artifact is being loaded.
There is precedent for this, as updating pointers when loading a library is one way to implement shared libraries. However, shared libraries only require this for externally-exposed symbols. Internal function calls can use relative jumps instead. For saving an object, which may contain pointers to itself, private objects would also need to have their pointers updated, which would add to the overhead. So, rather than requiring compilers to add what amounts to an additional dynamic-linking step, the standard forbids the runtime use of a compile time allocation altogether.
(At least, that’s my overall understanding, and I would be happy to be corrected on it if wrong.)