Thanks to a reddit thread I stumbled over D and thought I should give
it a chance. I'm currently working on project where hard RT
requirements matter. In most places the GC is not suitable. I tried to
port some core functionaly of an existing application which is
currently written in C/C++. I tried to convert some things 1:1 to D,
well aware that a better approach may exist.

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.

The application should have a dictionary which contains values of many
different objects. For this example, all objects should support a toFoo
method. To make it generic I've to rule out a struct, or to write
everything in a more functional style (a everythingToFoo method handles
all different types).

interface Entry {
        Foo toFoo();
}

scope class EntryNumeric(T) : Entry {
        T value = T.init;

        Foo toFoo() {
                ...
        }
}

alias Entry!(int) EntryInt;
alias Entry!(float) EntryFloat;

setup(Entry[] entries) {
        scope auto e1 = new EntryInt();
        Foo = e1.toFoo();

        scope auto e2 = new EntryInt();
        Foo = e2.toFoo();

        entries[0] = e1;
        entries[1] = e2;
}

init() {
        Entry entries[2];
        setup(entries);
        entries[0].toFoo();
        entries[1].toFoo();
}

I wonder why I can compile the above piece, because e1/e2 shouldn't be
allowed to leave the scope. It obviously crashes.

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).

struct Queue(T, int N) {
}

scope class MyClass {
}

Queue!(MyClass) m;

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? That
static arrays are stored in the .data section make things even more
complicated. 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...)

Thanks for any insight, tips, hints, ...

Reply via email to