Everything on the Stack

[Janthinidae]

First thanks for you long response,

> > I'm currently working on project where hard RT
> > requirements matter. In most places the GC is not suitable.
> 
> Please, show me the benchmarks you have seen or written, that rule out the D GC for your purposes. There's always the possibility that you have written bad benchmarks.

There is no benchmark, it's just that the software has to have a
worstcase latency to some relevant below 1 ms. If the GC kicks in the
wrong time shit happens. With not using malloc at all or the GC I just
have some kind of proof that this will never be a problem.

> > I think that only "struct" and "scope class" are suitable to create
> > objects. structs have the simple advantage that I don't have to type
> > "scope" in my whole program (can't alias it e.g.), but have the
> > disadvantage that I can't use an interface nor inheritance.
> 
> scope, used for your purpose, is deprecated (another usage of scope, for function arguments, to avoid them to exit the function scope, or to avoid to pass heap-allocated closures to functions, is still usable).
> As Trass3r has said, there is a replacement for scoped classes (but it has some problems still).

I looked at this class and just have seen that it internally uses a
uint8 array to store the data. This means executable size gets larger
and larger like for any other array.

> scope was deprecated also because it was broken. The library defined "scoped" is similarly broken, but better to have a broken library than a broken language feature :-)

Ok didn't knew that it is deprecated.

> > The next thing I tried to solve is some kind of a templated Queue
> > class, which can store anything. In C++ it's easy to write a container
> > class that only works on the stack and uses some uninitialized bytes of
> > memory and placement new to copy construct objects into the Queue. With
> > "scope class" this seems to fail because it seems to be impossible to
> > return a class if it's type uses "scope" class. Missing copy
> > construction one could probably solve manually, by just carefully
> > create an own core class library (or just juse memcpy).
> 
> Generally what's possible in C++ is possible in D too, even if maybe in a different way. I think all you say here is doable in D too, with different means.

Yes both are Turing complete :) But after all I hope that D makes
things easier and helps me to spot errors of certain aspects of my
program.

> > Another problem with my whole, everything on the stack idea, is that D
> > limits my arrays to an internal limit (any paramter to change it?).
> > It's easy to create a stack overflow anyway, so why a limit?
> 
> Walter says the limit is present because linkers have such limits and different linkers have different limits. So I think to allow people to compile (link) D code with different linkers, there is a built-in limit that is probably smaller than the limit of most linkers.
> Walter also says that past a certain size, it's not good to allocate an array on the stack, and it's better to allocate it on the heap. If you really want the stack there is alloca(), but I think allocating a single chunk of memory from the D-GC or C heaps at the start of the program, doesn't damage the hard RT qualities of your code.

Ok I understand it, but if some linkers fail, then isn't this the
linkgers problem? I still think something like an option would be nice
until the compiler can ask the linker (which never may happen). Even if
we would say D has the correct approach here, then one can ask why it's
not possible to write

int[10000000] t10 = void;

but possible to write

int[1000000] t0 = void;
...
int[1000000] t0 = void;

But the problem for me here is that all static arrays are in the .data
section (that's why I mentioned it) and make the executable that big.
If I declare an array with "Type[N] = void" I somehow expect, that it
is not initialized and that there is no data allocated in the .data
section.

Trying everything with alloca is maybe a better idea (and rewriting the
Scope template).

> > That the new core.memory.GC somehow misses a function to
> > analyze if there is any hidden malloc in any used function would be
> > usefull as well, because it's not always obvious which construct had
> > what effect (forgetting scope on a delegate etc...)
> 
> I have an enhancement request related to this, that usually people appreciate:
> http://d.puremagic.com/issues/show_bug.cgi?id=5070
> I think there is a similar enhancement request for generic allocations. Plus I have suggested a @noheap annotation, but it was not appreciated by Don.
> I suggest you to ask for this feature in the main D newsgroup. The more people asks for something similar, the more probable/sooner that it will be implemented.

Ok I'll do that. Thanks once more.