struct and default constructor

[ketmar via Digitalmars-d]

On Fri, 10 Oct 2014 21:45:32 +0000
dcrepid via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> Great, thanks for the tips!
you're welcome. ;-)

> Thanks for the effort of providing a proof of concept, even 
> though I don't agree with what the data property should do. 
> Shouldn't properties not mutate the data?
it depends. ;-) i think that doing such "lazy initialization" in
property is acceptable. maybe not the best style, but acceptable. yet i
may be wrong, of course.

> I think its a waste to check whether the buffer is there every time 
> you need to access it.
this check costs almost nothing. and when you need buffer, most of the
time you need it for some lengthy operation anyway, so checking cost
can be ignored. and you can do `auto mypointer = a.data.ptr;` to avoid
further checks. actually, it's meant to be used like this:

  auto d = a.data;
  // here we'll work with d, so no more checks

> Its better to allocate at the start, throw 
> an exception if it can't be allocated, then provide access to it 
> without any wasteful checks between. At least, this is the RAII 
> type of idiom I'm after.
the main caveat with lazy initialization is that your program can fail
at arbitrary place (where you'll first access .data), not when you
declaring buffer this can be bad 'cause you may already execute some
preparation code thinking that you have your buffer at hand.

> I've pasted most of the struct I've been using here:
> http://dpaste.dzfl.pl/15381d5828f8
will take a closer look at it later, i'm sleepy now. ;-)

btw, i'm used to call core.exception.onOutOfMemoryError when malloc()
fails. We can't be sure that we still have memory to construct new
Error object. sure, we'll lose linenumber info this way. it's not a
rule of thumb, though (Phobos tend to throw new OutOfMemoryError
instances, for example). but if we are working with memory on such low
level...

> better methods to doing it safely, for sure. But to do the same 
> with only a single pointer?
why do you insisting on having single pointer? sure you can use all
sort of tricks to pack alot of data in single pointer, but i can't see
any practical sense in it. today when smartphones have gigabytes of
RAM, i'll trade some more pointers for ease of using and safety.

> I think I like the idea of the factory method now though, as I've 
> learned you can hide a struct inside a function, and then call 
> the function to set the struct up properly and return it. At 
> least, I'm sure I've seen code that does that..
ah, yes, it's "Voldemort type". ;-)

  auto thatWhoCantBeNamed () {
    static struct A { ... }
    return A();
  }

voila. you have type that you can use but cannot create without
factory. but you need to have postblit enabled with this.

> > you can pass pointers to structs. pointers can be null. ;-)
> I thought ref gives us the same guarantee that C++'s references 
> do?  Pointers are so.. 90's =P  But yeah, the nullable object 
> thing has bitten my ass a few times as I'm learning D, which 
> really frustrates me =\
i've never used nullable myself. i'm just constantly forgetting about
it (and about ~80% of Phobos for that matter ;-).

> Thanks for your time
your posts made me think about some things ;-), so thanks for your time
too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141011/09f02924/attachment.sig>