struct and default constructor
dcrepid via Digitalmars-d
digitalmars-d at puremagic.com
Fri Oct 10 11:50:29 PDT 2014
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 <digitalmars-d at puremagic.com> 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).
More information about the Digitalmars-d
mailing list