Hi all!
I've read the topic and I am really surprised so many engeneers
arguing for so long and not having systematic approach to the
problem.
As I see it, Walter states that there are eenvironmental errors
and program bugs, which are non-recoverable. So use exceptions
(enforce) for first ones
Thanks a lot!
There is a problem though: when i pass incorrect parameters to
such a method, it says, that S has no such field, which is a
misleading error message.
There is also a problem: when i declare opDispatch to be private,
i still have access to this forwarding from another package. Is
it a bug or what?
Nah, this gives me lots of compiler crap, like .empty and others,
when compiler tries to compile them.
Cool! Only this does not show me where the error was. __FILE__
and __LINE__ is not any help here, because it's a template. Any
other way to find out where the actual error was?
I tried this:
struct S {
R opDispatch(string name, R, Args...)(Args args) {
return mixin((*iface). ~ name)(iface, args);
}
SomeT ** iface;
}
But then val.foo(1, 2) gives me no property 'foo' for type 'S'.
I've seen the template solution:
struct S {
Actyaly, last variant didn't work either: i was testing it
inside S like ifc.foo(1), so UFCS kiked in, not alias this.
On Saturday, 21 June 2014 at 18:16:17 UTC, monnoroch wrote:
Actyaly, last variant didn't work either: i was testing it
inside S like ifc.foo(1), so UFCS kiked in, not alias this.
Oh, my bad, alias impl this; actually did work. But the first
argument problem still holds.
I can't link to libjvm.so.
Here's my code:
extern (C) {
int JNI_CreateJavaVM(void ** pvm, void ** penv, void * args);
}
void main() {
writefln(0x%x, .JNI_CreateJavaVM);
}
Which ptints wrong stuff. When then i use it and check the
contents of **pvm is also prints wrong stuff
Oh, found a problem, it was about one more layer of pointer
indirection.
I've been reading all the topics with those radical ideas about
the GC and dtors and, honestly, i'd rather call them insane.
After all the reading and thinking, i came to conclusion, that
what Andrey suggests is to call dtors only on stack-allocated
structs. That also implies, that one can't
Hey I have this global variable, if I assign a value to it and
later null it, it'll call its destructor if its not referenced
anywhere else.
Which in turn would make me think ref counting would be a good
idea.
It seems, that ARC is the only way. There were idea to make all
non-scoped (in
Scoped-objects + ARC on non-scoped objects with dtors + GC on
non-scoped objects w/o dtors would arguably solve the problem,
especially, is arrays of scoped objects would be considered also
scoped, or just add separate scoped arrays.
Interesting, we haven't explored that. The most problematic
implication would be that classes with destructors will form a
hierarchy separate from Object.
As i understood, you want to remove dtors for non-scoped objects
completely, so all classes will be without it, except user
defined ones.
The most problematic implication would be that classes with
destructors will form a hierarchy separate from Object.
What for? As i understand object's dtor does nothing, so for any
class we can determine, if dtor is empty. I don't see a problem
here.
Cycles and locks for RC are the biggest
What about namespaces?
I often see, that D developers say something like remove
allocations from std lib, and it seems, that the main reason to
do it is eliminate gc calls.
What about the idea, that local objects do not use gc at all?
Maby, all temporary variables can be destroyed just like in C++,
when out of scope
17 matches
Mail list logo
