On Fri, 10 Oct 2014 21:45:32 +0000 dcrepid via Digitalmars-d <[email protected]> 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.
signature.asc
Description: PGP signature
