Re: RAII pointers

2017-06-03 Thread Stanislav Blinov via Digitalmars-d-learn
On Saturday, 3 June 2017 at 21:39:54 UTC, Moritz Maxeiner wrote: On Saturday, 3 June 2017 at 21:16:08 UTC, Stanislav Blinov wrote: On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner wrote: Quite, but if you backtrack to my initial statement, it was about ptr not being/becoming null

Re: RAII pointers

2017-06-03 Thread Moritz Maxeiner via Digitalmars-d-learn
On Saturday, 3 June 2017 at 21:16:08 UTC, Stanislav Blinov wrote: On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner wrote: Quite, but if you backtrack to my initial statement, it was about ptr not being/becoming null (implicitly) in the first place, which *might* allow you to skip

Re: RAII pointers

2017-06-03 Thread Stanislav Blinov via Digitalmars-d-learn
On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner wrote: On Saturday, 3 June 2017 at 20:25:22 UTC, Stanislav Blinov wrote: On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner wrote: Calling std.algorithm.move is explicit programmer intent, I consider that about as accidental as

Re: RAII pointers

2017-06-03 Thread Moritz Maxeiner via Digitalmars-d-learn
On Saturday, 3 June 2017 at 20:25:22 UTC, Stanislav Blinov wrote: On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner wrote: Calling std.algorithm.move is explicit programmer intent, I consider that about as accidental as calling memcpy with a source full of zeroes. In any case, having

Re: RAII pointers

2017-06-03 Thread Stanislav Blinov via Digitalmars-d-learn
On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner wrote: Calling std.algorithm.move is explicit programmer intent, I consider that about as accidental as calling memcpy with a source full of zeroes. In any case, having that check in the destructor is fairly cheap, so better safe than

Re: RAII pointers

2017-06-03 Thread Moritz Maxeiner via Digitalmars-d-learn
On Saturday, 3 June 2017 at 19:55:30 UTC, ag0aep6g wrote: On 06/03/2017 09:37 PM, Moritz Maxeiner wrote: Of course, but AFAIK you'd need to explicitly assign it to an object, so `ptr` won't null by accident, but only by explicit programmer intent (same as overwriting the memory the object

Re: RAII pointers

2017-06-03 Thread Stanislav Blinov via Digitalmars-d-learn
On Saturday, 3 June 2017 at 19:55:30 UTC, ag0aep6g wrote: On 06/03/2017 09:37 PM, Moritz Maxeiner wrote: Of course, but AFAIK you'd need to explicitly assign it to an object, so `ptr` won't null by accident, but only by explicit programmer intent (same as overwriting the memory the object

Re: RAII pointers

2017-06-03 Thread ag0aep6g via Digitalmars-d-learn
On 06/03/2017 09:37 PM, Moritz Maxeiner wrote: Of course, but AFAIK you'd need to explicitly assign it to an object, so `ptr` won't null by accident, but only by explicit programmer intent (same as overwriting the memory the object lives in via things like `memcpy`); and you can always screw

Re: RAII pointers

2017-06-03 Thread Moritz Maxeiner via Digitalmars-d-learn
On Saturday, 3 June 2017 at 19:21:58 UTC, ag0aep6g wrote: On 06/03/2017 09:06 PM, Moritz Maxeiner wrote: - null check in destructor: That's just because I forgot to add it. If you add `@disable(this)` (disable the default constructor), all elaborate constructors ensure it is not null, and no

Re: RAII pointers

2017-06-03 Thread ag0aep6g via Digitalmars-d-learn
On 06/03/2017 09:06 PM, Moritz Maxeiner wrote: - null check in destructor: That's just because I forgot to add it. If you add `@disable(this)` (disable the default constructor), all elaborate constructors ensure it is not null, and no members can set it to null, you might be able to skip the

Re: RAII pointers

2017-06-03 Thread Moritz Maxeiner via Digitalmars-d-learn
On Saturday, 3 June 2017 at 17:40:32 UTC, Russel Winder wrote: Would one be considered more idiomatic D, or is it a question of different circumstances different approaches. The differences are mainly in construction I believe. Well, the differences I spot are: - null check in destructor:

Re: RAII pointers

2017-06-03 Thread Russel Winder via Digitalmars-d-learn
Thanks to Moritz and Stanislav for their examples, most useful. There are similarities (which I have just taken :-) but also some differences. Would one be considered more idiomatic D, or is it a question of different circumstances different approaches. The differences are mainly in construction I

Re: RAII pointers

2017-05-29 Thread Stanislav Blinov via Digitalmars-d-learn
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote: C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: class Dvb::FrontendParameters_Ptr { private: dvb_v5_fe_parms * ptr; public:

Re: RAII pointers

2017-05-29 Thread Moritz Maxeiner via Digitalmars-d-learn
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote: C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: class Dvb::FrontendParameters_Ptr { private: dvb_v5_fe_parms * ptr; public:

Re: RAII pointers

2017-05-29 Thread Nicholas Wilson via Digitalmars-d-learn
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote: C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: [...] std.stdio.File does basically the same thing with C's FILE*