Unless I'm confused, classses are ALWAYS heap (unless explicitely
scoped) objects in D. The garbage collector is the one that is tasked
with reclaiming their memory and calling their deconstructor.
If you want the semantics you're talking about Foo would need to be a
"scoped Foo foo = new Foo();"
I could be wrong, I haven't had a change to touch D in about a year
though, some stuff could have changed.
(And please don't top quote, argh! ;))
-SC
On 2009-12-14 05:47:44 -0800, Leandro Lucarella <[email protected]> said:
lws, el 14 de diciembre a las 01:06 me escribiste:
I don't know if I believe this is necesarrily bad. It's revealing
some bad coding on your part.
You shouldn't be doing opEquals with an rvalue of a class. Make
getFoo return a reference.
ref Foo getFoo() {} fixes the problem and avoids value-copying for
no reason to an rvalue that's going to get garbage collected.
If you are using "garbage collected" as a general term to denote
"automatic memory reclamation", you are right, but the garbage collector
have nothing to do with rvalues, they are allocated in the stack, and they
will be "garbage collected" by the compiler when unwinding the stack, not
the GC.
I don't know if this is relevant to the discussion, I'm clarifying, just
in case :)
On 2009-12-12 07:14:50 -0800, dsimcha <[email protected]> said:
I've noticed that, for DMD 2.037, we've started mandating that the input
parameter for struct opEquals be const ref T. This seemed like a good idea
initially, but it creates the horribly leaky abstraction that the right-hand
argument to opEquals can't be an rvalue. Example:
struct Foo {
bool opEquals(const ref Foo rhs) const { // Only signature
// that compiles.
return true;
}
}
Foo getFoo() {
return Foo();
}
void main() {
Foo foo = getFoo();
bool isEqual = foo == getFoo();
}
Error: Foo.opEquals type signature should be const bool(ref const(Foo)) not
const bool(Foo rhs)
Will this be getting fixed witht he new operator overloading?
