On 11/14/14 11:55 AM, Rainer Schuetze wrote:
On 14.11.2014 16:44, Steven Schveighoffer wrote:
The issue I have is, how do you enforce that as the author of the struct?
You can define "new" in the struct:
struct S
{
new(size_t sz);
int x;
}
This doesn't stop array allocation, or
On 14.11.2014 16:44, Steven Schveighoffer wrote:
On 11/14/14 6:25 AM, Rainer Schuetze wrote:
On 11.11.2014 21:41, Steven Schveighoffer wrote:
In other words, putting a struct in the GC heap that was written to be
scope-destroyed is an error before and after this pull. Before the pull,
the d
On 11/14/14 6:25 AM, Rainer Schuetze wrote:
On 11.11.2014 21:41, Steven Schveighoffer wrote:
In other words, putting a struct in the GC heap that was written to be
scope-destroyed is an error before and after this pull. Before the pull,
the dtor doesn't run, which is wrong, and after the pull
On 11.11.2014 21:41, Steven Schveighoffer wrote:
In other words, putting a struct in the GC heap that was written to be
scope-destroyed is an error before and after this pull. Before the pull,
the dtor doesn't run, which is wrong, and after the pull the dtor may
cause race issues, which is wron
On 11/12/14 3:00 PM, Uranuz wrote:
If we will have something like *scoped destructor* (that will be
executed at scope exit) could it help to release some resources? I worry
about this problem too because even using class to hold resource I
expirience some *delays* in relesing them. For example I
On Wednesday, 12 November 2014 at 20:00:31 UTC, Uranuz wrote:
If we will have something like *scoped destructor* (that will
be executed at scope exit) could it help to release some
resources?
Don't know what you mean here. Isn't that just a normal
destructor?
I worry about this problem too
If we will have something like *scoped destructor* (that will be
executed at scope exit) could it help to release some resources?
I worry about this problem too because even using class to hold
resource I expirience some *delays* in relesing them. For example
I have database connection opened.
On 11/11/14 11:59 PM, Shachar Shemesh wrote:
On 10/11/14 16:19, Steven Schveighoffer wrote:
Only classes call dtors from the GC. Structs do not. There are many
hairy issues with structs calling dtors from GC. Most struct dtors
expect to be called synchronously, and are not expecting to deal wit
On 11/12/14 12:05 AM, Shachar Shemesh wrote:
On 11/11/14 22:41, Steven Schveighoffer wrote:
At this point, I am not super-concerned about this. I cannot think of
any bullet-proof way to ensure that struct dtors for structs that were
meant only for stack variables can be called correctly from th
On Wednesday, 12 November 2014 at 13:56:08 UTC, Shachar Shemesh
wrote:
On 12/11/14 11:29, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
Supposedly, a struct destructor will only access resources
that the
struct itself manages. As long as that's the case, it will be
safe. In
practice, there's still
On 12/11/14 11:29, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote:
Supposedly, a struct destructor will only access resources that the
struct itself manages. As long as that's the case, it will be safe. In
practice, there's still a lot that can go wrong.
Either a struct's destructor can be run from th
On Monday, 10 November 2014 at 14:19:26 UTC, Steven Schveighoffer
wrote:
Is the resource a GC resource? If so, don't worry about it.
I might be wrong but my view is that in presence of a GC and
undre the abstraction of R Chen, it is wrong to think about
memory as being a resource anymore.
On Wednesday, 12 November 2014 at 04:59:33 UTC, Shachar Shemesh
wrote:
On 10/11/14 16:19, Steven Schveighoffer wrote:
Only classes call dtors from the GC. Structs do not. There are
many
hairy issues with structs calling dtors from GC. Most struct
dtors
expect to be called synchronously, and a
On 11/11/14 22:41, Steven Schveighoffer wrote:
At this point, I am not super-concerned about this. I cannot think of
any bullet-proof way to ensure that struct dtors for structs that were
meant only for stack variables can be called correctly from the GC.
Isn't "structs meant only for stack vari
On 10/11/14 16:19, Steven Schveighoffer wrote:
Only classes call dtors from the GC. Structs do not. There are many
hairy issues with structs calling dtors from GC. Most struct dtors
expect to be called synchronously, and are not expecting to deal with
multithreading issues.
Note that structs in
On 11/11/14 2:46 PM, Rainer Schuetze wrote:
On 10.11.2014 15:19, Steven Schveighoffer wrote:
Now, imagine you wanted to put this on the GC heap, and the GC would
call struct dtors. And let's say the program is multi-threaded. First,
the memory referred to by t isn't guaranteed to be alive, it
On 10.11.2014 15:19, Steven Schveighoffer wrote:
Now, imagine you wanted to put this on the GC heap, and the GC would
call struct dtors. And let's say the program is multi-threaded. First,
the memory referred to by t isn't guaranteed to be alive, it could have
already been finalized and freed.
Am Mon, 10 Nov 2014 09:13:09 +
schrieb "Tomer Filiba" :
> Thanks for the info, ketmar.
>
> By the way, what do you guys think of adding @nogc to structs, in
> which case they cannot be instantiated by the GC?
>
> e.g.,
>
> @nogc struct S {...}
> auto s = new S(); // does not compile
> S s;
On 11/10/14 3:10 AM, Tomer Filiba wrote:
The following code does not invoke S.~this. If I change `struct S` to
`class S` - it does. Memory consumption remains constant, meaning memory
is collected, but destructors are not called.
import std.stdio;
import std.conv;
struct S {
string s;
Thanks for the info, ketmar.
By the way, what do you guys think of adding @nogc to structs, in
which case they cannot be instantiated by the GC?
e.g.,
@nogc struct S {...}
auto s = new S(); // does not compile
S s; // all is well
-tomer
On Monday, 10 November 2014 at 08:28:03
On Mon, 10 Nov 2014 08:10:08 +
Tomer Filiba via Digitalmars-d wrote:
> The following code does not invoke S.~this. If I change `struct
> S` to `class S` - it does. Memory consumption remains constant,
> meaning memory is collected, but destructors are not called.
>
> import std.stdio;
> im
The following code does not invoke S.~this. If I change `struct
S` to `class S` - it does. Memory consumption remains constant,
meaning memory is collected, but destructors are not called.
import std.stdio;
import std.conv;
struct S {
string s;
~this() {
writeln("~S");
}
}
22 matches
Mail list logo
