On Friday, 10 October 2014 at 08:03:49 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 10 Oct 2014 01:32:51 +0000
dcrepid via Digitalmars-d <[email protected]> wrote:
So no possibility of using objects as resource acquire/release
mechanisms.
I assume using scoped with class objects will have a similar
problem..
no, stack-allocated object is GC root, so anything it holds
reference
to will not be destroyed until stack object is alive. so
destructor of
stack-allocated object *can* be used for doing cleanup.
but you can use templates to build your "anchor" structs. it's
hard to
say without concrete code samples.
What I mean with the scoped objects is that you still need to
provide a constructor with parameters, yes? I will have to try
this out myself, but I've avoided it since some people seem to
indicate this is going to be deprecated..
Basically what I was doing code-wise was creating a 'FixedBuffer'
structure, which would have its size passed as a template
parameter. The constructor would do a malloc on it, and all the
checks for bounds would only need to rely on that template
parameter. Net result is that the cost of having a pretty safe
bounds-checked buffer was just the size of one pointer.
I *sorta* get the whole concept of being able to easily reason
and work with structures in D, but why then does it have a
destructor and a way to disable a default constructor, along with
operator overloads and whatnot. It seems to me its trying to be
object-like and POD-like at the same time which doesn't mesh well.
As far as the 'scoped' object, I was referring to default
construction - is it possible? Or do I need to use Walter's
factory production workaround everytime I want something with
deterministic create/destroy properties in this context?
I would very readily accept using objects over structs if they
had a guarantee of when they are destroyed, and weren't as risky
to pass around as C pointers (i.e. possibility of them being
null).
