Janthinidae: > Thanks to a reddit thread I stumbled over D and thought I should give > it a chance.
Welcome here then. Your post is quite interesting, your questions are complex. > 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. > 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. It looks like an interesting project for D, also useful to spot possible problems in D itself or its Phobos. > 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 wonder why I can compile the above piece, because e1/e2 shouldn't be > allowed to leave the scope. It obviously crashes. 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 :-) > 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. > 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. > That static arrays are stored in the .data section make things > even more complicated. I am not expert on this, sorry. What problems is this giving you? > 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. Bye, bearophile
