struct and default constructor

[dcrepid via Digitalmars-d]

On Friday, 10 October 2014 at 20:25:16 UTC, ketmar via 
Digitalmars-d wrote:
> On Fri, 10 Oct 2014 18:50:29 +0000
> dcrepid via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>> 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..
> only the syntax `scope auto a = new A();` is deprecated, not 
> the whole
> concept. you just have to write it this now:
>
>   import std.typecons : scoped; // yep, it's in a library now
>   ...
>   class A {
>     this () { ... }
>     ~this () { ... }
>   }
>   ...
>   {
>     // allocate class instance on the stack
>     auto a = scoped!A();
>     ...
>   } // here destructor for 'a' will be called
>
> just be careful and don't let 'a' escape the scope. ;-)

Great, thanks for the tips!

> it's better to use slices for that. you can create struct like 
> this:
> (snipped)

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? But more than that I 
think its a waste to check whether the buffer is there every time 
you need to access it. 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.

How I am currently using it is using either .ptr, .data, or 
slices to create the necessary access or D slices. It works 
pretty well for what I'm using it for. I'm interfacing with the 
Windows API with the .ptr property, and then when I need to use 
it with D functions I typically use opSlice since the data is 
often variable lengths.

I've pasted most of the struct I've been using here:
http://dpaste.dzfl.pl/15381d5828f8

I would use it in say, a call to Windows' WinHttpReadData() using 
OutBuffer.ptr, then work with the received data (stored in 
dwDownloaded) using OutBuffer[0 .. dwDownloaded], for example. It 
works pretty nicely even if its not up to D's standards.

About escaping scope - I'm aware this is possible, but the idea 
is that this is supposed to be used temporarily in a certain 
scope, then discarded (as the Scope prefix indicates).. there's 
better methods to doing it safely, for sure. But to do the same 
with only a single pointer?

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..


>>  It seems to me its trying to be object-like and POD-like at 
>> the same time which doesn't mesh well.
> 'cause there are two kinds of structs, actually. one kind is 
> POD, and
> another is object-like, with methods, destructors and so on. 
> this may be
> confusing a little. ;-) just don't mix 'em.

Haha.. I'll try not to (I think?)

>> 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).
> 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 =\

Thanks for your time