Are these things possible at compile-time?
1 - instancing templated struct/class and using them
2 - calling dynamically linked C functions
3 - accessing files

thanks for answers

Sorry I swapped the topic and user name fields :|

Is this possible at compile time? <c1o2n3t4a5c6t@gamesfrommars.fr> wrote:

> Are these things possible at compile-time?
> 1 - instancing templated struct/class and using them

Structs yes, classes no. And not all kinds.

> 2 - calling dynamically linked C functions

No.

> 3 - accessing files

Yes. import( "filename" ) gives you the contents as a string.


-- 
Simen

ponce:

> Are these things possible at compile-time?
> 1 - instancing templated struct/class and using them

Currently classes can't be created at compile time, this fails:


class Foo {}
int bar() {
    Foo f = new Foo;
    return 0;
}
enum int ignore = bar();
void main() {}


But this limit may be eventually removed for some well behaved classes (like classes with pure methods that don't contain other things forbidden in CTFE). Don is more expert on this and he is probably able to give you a better answer.

Bye,
bearophile

bearophile wrote:
> ponce:
> 
>> Are these things possible at compile-time?
>> 1 - instancing templated struct/class and using them
> 
> Currently classes can't be created at compile time, this fails:
> 
> 
> class Foo {}
> int bar() {
>     Foo f = new Foo;
>     return 0;
> }
> enum int ignore = bar();
> void main() {}
> 
> 
> But this limit may be eventually removed for some well behaved classes (like classes with pure methods that don't contain other things forbidden in CTFE). Don is more expert on this and he is probably able to give you a better answer.
> 
> Bye,
> bearophile
Yes. The rules will be:
* no globals (same as pure).
* no unsafe features (eg, no asm).
* source code must be available.
Everything else should work.

Don:

> Yes. The rules will be:
> * no globals (same as pure).
> * no unsafe features (eg, no asm).
> * source code must be available.
> Everything else should work.

If a class is instantiated at compile-time the memory of its instance goes in the static mutable memory, but then the GC has to manage it differently, because you can't deallocate that memory. Is this a problem? It looks a little like the problems with scoped classes (that are now deprecated by Andrei).

(Time ago I have read an interesting paper about a C-like language that supports some kind of classes too. This language is designed for embedded CPUs, so classes may be allocated at compile time only, and never at runtime (where there isn't a dynamic heap), and the compiler takes even care of compacting and squeezing the class instances in the static memory (to reduce as possible the amount of memory they use). Allocating objects at compile time may be a performance optimization for D).

Bye,
bearophile

On Tuesday 09 November 2010 12:42:06 bearophile wrote:
> Don:
> > Yes. The rules will be:
> > * no globals (same as pure).
> > * no unsafe features (eg, no asm).
> > * source code must be available.
> > Everything else should work.
> 
> If a class is instantiated at compile-time the memory of its instance goes in the static mutable memory, but then the GC has to manage it differently, because you can't deallocate that memory. Is this a problem? It looks a little like the problems with scoped classes (that are now deprecated by Andrei).

Given that it's possible to serialize entire objects to disk in binary form, including all the references that they hold and whatnot in languages like Java, I'm sure that it would be possible to make it so that any objects allocated with new during CTFE would be in the dynamic heap during runtime.

- Jonathan M Davis

Jonathan M Davis:

> it would be possible to make it so that any objects allocated with new during CTFE would be in the dynamic heap during runtime.

This is possible, but it doesn't seem what you usually desire when you allocate an object at compile time.

Bye,
bearophile

bearophile wrote:
> Jonathan M Davis:
> 
>> it would be possible to make it so that any objects allocated with new during CTFE would be in the dynamic heap during runtime.
> 
> This is possible, but it doesn't seem what you usually desire when you allocate an object at compile time.
> 
> Bye,
> bearophile

If it's mutable, it'll go on the heap. If it's immutable, it could optionally go into read-only memory (it will be exactly like the .init of a class instance). Classes which are used only during execution of CTFE functions will not be instantiated at runtime.

On Tuesday, November 09, 2010 13:49:12 bearophile wrote:
> Jonathan M Davis:
> > it would be possible to make it so that any objects allocated with new during CTFE would be in the dynamic heap during runtime.
> 
> This is possible, but it doesn't seem what you usually desire when you allocate an object at compile time.

Why not? CTFE stuff should either disappear in the binary, because it's not needed anymore, or it should be the same as if it were created at runtime. CTFE is a great opportunity to create more complicated stuff at cheaper cost (since the calculations are done at compile time instead of runtime), and more importantly, have compile-time constants which are more complex. It's also a great way to generate code. But I don't see why you'd want statically-created objects to be treated differently once the program is running.

- Jonathan M Davis