On Saturday, 3 June 2017 at 21:46:45 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 21:39:54 UTC, Moritz Maxeiner wrote:
It's always true, because I explicitly wrote *might*, not
*will*, to indicate that it depends on your use case. Your
example is a common use case where you can't sk
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 (im
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 the
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
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 t
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 s
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
live
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
live
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 th
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 m
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 ch
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: That
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
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:
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:
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*
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:
FrontendParameters_Ptr(FrontendId const & fei, unsign
17 matches
Mail list logo