On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis
wrote:
On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis
wrote:
They're not the same thing at all. scoped is supposed to put
the class on the stack, not the heap. And it's not
ref-counted. It's so that you can create a class object in
place, use it, and throw it away without doing any heap
allocation. Essentially, it allows you to use a class as if
it were a non-copyable struct. Even if we end up with
ref-counting supported in the language, it doesn't obviate
the need for scoped classes. They're for different use cases.
For my purposes, they are pretty much the same.
So again, I'll paste the same example:
class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever,
will this be called?
}
Memory is not only thing that has to be cleaned up.
Well, they might seem the same when you only look at that part,
but they won't both solve your problem, depending on what
you're trying to do.
But in general, at this point, with D, if you want
deterministic destruction, then you use structs. Classes are
not the appropriate place for it. If they were ref-counted,
then they could be, but as long as they're not, then classes
are not the place to have stuff that cares about deterministic
destruction. And if you're stuck with stuff in classes that do
care about deterministic destruction, then you have to use the
sort of solutions that C# and Java use where you don't rely on
the destructor/finalizer to clean anything up except for the
cases where you screw up and forget to manually call the
function that does the cleanup.
I'm not sure what else I can say. The example I posted says it
all, and it can't be done properly in D (or C#, but why lower the
bar because of their mistakes? ;)
I'm not sure exactly how C# and Java handle destruction for
non-memory resources, but I'm guessing it's something like
calling GC.collect() manually every couple of seconds. If the
textures aren't released in the destructor, I don't really see
any other way to tell when they're referenced or not.
Of course though, mobile devices are the new PC, and battery life
is very much a concern, so this is a total waste...especially if
I'm doing very little GC allocation anyways. Also, of course,
there are the performance issues.
I expect that we'll get ref-counting for classes at some point,
since while ref-counting with structs works, as I understand
it, it does have some holes that make it less than ideal (but
not necessarily unusable). And for some reason, IIRC,
RefCounted doesn't work with classes, so you'd be forced to
write your own ref-counted wrapper. It can certainly be done
though.
- Jonathan M Davis
Correct, RefCounted doesn't work with classes. Not sure why, but
I wrote my own, and trivial unittests pass:
http://dpaste.dzfl.pl/997615d2d188
But again, as I've already mentioned, it hides the type, has
annoying syntax, and most importantly, is error prone. I can't
really write a class thats meant to be used with RC(T) and know
that no one will ever try to use it on it's own, GC allocated.
D needs a real solution here.
http://imgur.com/v6CIWln
Bit
