On Monday, 22 May 2017 at 00:45:27 UTC, Adam D. Ruppe wrote:
On Monday, 22 May 2017 at 00:36:24 UTC, Stanislav Blinov wrote:
I can't think of any case where you'd want preconditions on
destructor when the object is in .init state.
I think we're actually saying the same thing: I mean the
On Monday, 22 May 2017 at 00:36:24 UTC, Stanislav Blinov wrote:
I can't think of any case where you'd want preconditions on
destructor when the object is in .init state.
I think we're actually saying the same thing: I mean the
destructor must be callable on .init so you might do like
struct
On Monday, 22 May 2017 at 00:23:26 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 14:13:20 UTC, Stanislav Blinov wrote:
Not if you either emplace() or blit Foo.init into all of the
array elements.
You especially need to be safe calling ~this on Foo.init.
How so? .init is supposed to be
On Sunday, 21 May 2017 at 14:13:20 UTC, Stanislav Blinov wrote:
Not if you either emplace() or blit Foo.init into all of the
array elements.
You especially need to be safe calling ~this on Foo.init.
On Sunday, 21 May 2017 at 23:59:08 UTC, Guillaume Piolat wrote:
On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote:
Any struct should be able to have its destructor called
Does this rule also applies to class objects?
Yes. If your destructor does modify the state, you should expect
On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote:
Any struct should be able to have its destructor called
Does this rule also applies to class objects?
On Sunday, 21 May 2017 at 12:48:10 UTC, Adam D. Ruppe wrote:
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
// Why is this._foo null here???
The others have answered why and what to do, but note that
according to the spec, that any struct should be able to
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
// Why is this._foo null here???
The others have answered why and what to do, but note that
according to the spec, that any struct should be able to have its
destructor called, so you should do a null check in
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
Looks like you would want to use emplace [0] here.
public this(int n)
{
this._data = (cast(Foo*) calloc(n, Foo.sizeof))[0 .. n];
foreach(ref element; this._data)
{
On Saturday, 20 May 2017 at 12:25:39 UTC, Stanislav Blinov wrote:
Oof. Dangerous stuff.
:)
Thanks for the heads up but I think I'm covering all cases in my
main code.
On Saturday, 20 May 2017 at 11:15:57 UTC, Moritz Maxeiner wrote:
Because `element = tmp` destroys `element`, which you allocated
filled with zeroes.
The destructor will run for each `element`.
Right, I get it because the destructors running on the struct
that is being replaced. Doh!
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
In the following code, the `_foo` pointer (of the Foo struct)
is null in the first call to the destructor. Why is this? I
think it's got something to do with the foreach loop but I'm
not sure. Any ideas?
Oof. Dangerous stuff.
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
In the following code, the `_foo` pointer (of the Foo struct)
is null in the first call to the destructor. Why is this? I
think it's got something to do with the foreach loop but I'm
not sure. Any ideas?
struct Bar
{
In the following code, the `_foo` pointer (of the Foo struct) is
null in the first call to the destructor. Why is this? I think
it's got something to do with the foreach loop but I'm not sure.
Any ideas?
import std.stdio;
import core.stdc.stdlib : malloc, calloc, free;
struct Foo
{
14 matches
Mail list logo
