On Wed, Feb 22, 2017 at 06:17:14PM +0000, Stefan Koch via Digitalmars-d-learn wrote: > On Wednesday, 22 February 2017 at 17:05:17 UTC, H. S. Teoh wrote: > > On Wed, Feb 22, 2017 at 04:08:45PM +0000, Stefan Koch via > > Digitalmars-d-learn wrote: > > > [...] > > > > I'm not sure it's that simple. Just because AA's become CTFEable > > doesn't mean they will automatically be convertible to object code > > in the executable that allows runtime AA lookups. For instance, a > > CTFE pointer will have a value that has no correspondence with the > > object code in the executable, and neither will memory allocated > > during CTFE have any correspondence with the emitted object code > > (because this memory is allocated in the compiler, not in the object > > code). So if the CTFE AA implementation allocates nodes for storing > > key/value pairs, they will only exist in the CTFE engine, and > > pointers to them will only make sense within the CTFE engine. In > > order to make them work in the executable (so that you can do AA > > lookups to these computed nodes at runtime), you will need to > > somehow map them to object code. Just because AA's become CTFEable > > will not automatically solve this for you. > > > > [...] > > The CTFE allocated memory can be copied into the object file verbatim > because the structure is the same. Pointers are easy to fix up as > well, because by definition the have to point to static data that will > be in the object file.
This will fail for cross-compilation. Unless you mean that the new CTFE engine is emulating the target machine directly? T -- Computers shouldn't beep through the keyhole.
