On 12/16/22 7:17 AM, Nick Treleaven wrote:
This code segfaults when the GC calls the dtor after the unittest succeeds:
```d
unittest
{
int i;
struct S
{
~this() { i++; }
}
(*new S).destroy;
}
```
It seems destroy clears the context pointer. Is there a way to
On Tuesday, 20 December 2022 at 06:31:09 UTC, ag0aep6g wrote:
On 16.12.22 14:07, Nick Treleaven wrote:
This seems to work:
~this() @trusted { if ( > cast(void*)1024) i++; }
It would be better if there was a struct property to get the
context pointer though.
A quick test suggests
On 16.12.22 14:07, Nick Treleaven wrote:
This seems to work:
~this() @trusted { if ( > cast(void*)1024) i++; }
It would be better if there was a struct property to get the context
pointer though.
A quick test suggests that the context pointer is the last item in
`tupleof`. So this
On Friday, 16 December 2022 at 12:17:40 UTC, Nick Treleaven wrote:
This code segfaults when the GC calls the dtor after the
unittest succeeds:
```d
unittest
{
int i;
struct S
{
~this() { i++; }
}
(*new S).destroy;
}
```
It seems destroy clears the context pointer.
On Friday, 16 December 2022 at 12:17:40 UTC, Nick Treleaven wrote:
It seems destroy clears the context pointer. Is there a way to
test if the context pointer is null in the dtor, to prevent the
increment?
This seems to work:
~this() @trusted { if ( > cast(void*)1024) i++; }
It would
This code segfaults when the GC calls the dtor after the unittest
succeeds:
```d
unittest
{
int i;
struct S
{
~this() { i++; }
}
(*new S).destroy;
}
```
It seems destroy clears the context pointer. Is there a way to
test if the context pointer is null in the dtor,
On Sunday, 16 May 2021 at 11:42:19 UTC, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
[...]
destroy + GC.free has a quirk - GC.free only works on what
GC.malloc returns, a base pointer, NOT what `new` returns. The
documentation says this but it is a subtle detail
On Sunday, 16 May 2021 at 11:42:19 UTC, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
I tracked down the problem but wasn't 100% sure about the fix.
Adding the GC.baseOf thing works for me but i didn't upstream
since idk if it works for everyone else.
maybe i
On Sunday, 16 May 2021 at 11:42:19 UTC, Adam D. Ruppe wrote:
On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
If the goal is to absolutely squeeze the GC back down after
using new or dynamic arrays, I find destroy + GC.free often
fails to do the trick (e.g. GC.stats.usedSize remains high).
On Sunday, 16 May 2021 at 08:04:06 UTC, cc wrote:
If the goal is to absolutely squeeze the GC back down after
using new or dynamic arrays, I find destroy + GC.free often
fails to do the trick (e.g. GC.stats.usedSize remains high).
destroy + GC.free has a quirk - GC.free only works on what
On Saturday, 15 May 2021 at 18:24:19 UTC, Alain De Vos wrote:
Thanks, good idea but,
It does not initiate a GC cycle or free any GC memory.
Personally I wish D would re-implement "delete" and make it "just
work" like one would assume, but from what I've seen there have
been many many debates
On Saturday, 15 May 2021 at 18:26:08 UTC, Adam D. Ruppe wrote:
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
Feature request, a function old which does the opposite of
new, allowing deterministic,real-time behavior and memory
conservation.
You're best off doing malloc+free if
I'll try first the first tip of Adam, here the code,
```
import std.stdio:writeln;
import core.memory: GC;
void myfun(){
class C{
int[1] x;
}//class C
struct S {
C c=null;
@disable this();
this(int dummy) {
c=new C();
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
Feature request, a function old which does the opposite of new,
allowing deterministic,real-time behavior and memory
conservation.
You're best off doing malloc+free if you want complete control
though.
Sorry free does , indeed.
On Saturday, 15 May 2021 at 18:15:24 UTC, Dennis wrote:
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
Feature request, a function old which does the opposite of
new, allowing deterministic,real-time behavior and memory
conservation.
You can use
Thanks, good idea but,
It does not initiate a GC cycle or free any GC memory.
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote:
Feature request, a function old which does the opposite of new,
allowing deterministic,real-time behavior and memory
conservation.
You can use
[object.destroy](https://dlang.org/phobos/object.html#.destroy)
to destruct, and
Feature request, a function old which does the opposite of new,
allowing deterministic,real-time behavior and memory conservation.
On Saturday, 15 May 2021 at 16:53:04 UTC, Adam D. Ruppe wrote:
On Saturday, 15 May 2021 at 16:52:10 UTC, Alain De Vos wrote:
When I do a "new" in a struct constructor to assign to a
member variable of this struct, what do i write in the same
struct destructor to free the memory
When I do a "new" in a struct constructor to assign to a member
variable of this struct, what do i write in the same struct
destructor to free the memory ?
On Saturday, 15 May 2021 at 16:52:10 UTC, Alain De Vos wrote:
When I do a "new" in a struct constructor to assign to a member
variable of this struct, what do i write in the same struct
destructor to free the memory ?
If you used `new` the garbage collector is responsible for it.
On Friday, 16 October 2020 at 16:00:07 UTC, Steven Schveighoffer
wrote:
On 10/16/20 9:12 AM, tchaloupka wrote:
So when the exception is thrown within Foo destructor (and
it's bad on it's own but can easily happen as destructors
aren't nothrow @nogc by default).
Is this behavior expected?
On 10/16/20 9:05 AM, Steven Schveighoffer wrote:
> The destruction of members is outside the destructor's purview. It can't
> turn the destruction off, so it should logically be considered part of
> an enclosing function.
Thank you. Makes sense.
Ali
On 10/16/20 11:11 AM, Ali Çehreli wrote:
On 10/16/20 6:12 AM, tchaloupka wrote:
> struct Foo {
> Bar bar;
> bool err;
>
> ~this() {
> // scope(failure) destroy(bar); // < this fixes the Bar
> destructor call
> enforce(!err, "Test err");
Well, that check
On 10/16/20 9:12 AM, tchaloupka wrote:
So when the exception is thrown within Foo destructor (and it's bad on
it's own but can easily happen as destructors aren't nothrow @nogc by
default).
Is this behavior expected?
I would say it's a bug. The compiler is going to call the member
On Friday, 16 October 2020 at 15:19:51 UTC, Paul Backus wrote:
On Friday, 16 October 2020 at 13:12:04 UTC, tchaloupka wrote:
So when the exception is thrown within Foo destructor (and
it's bad on it's own but can easily happen as destructors
aren't nothrow @nogc by default).
Is this behavior
On Friday, 16 October 2020 at 13:12:04 UTC, tchaloupka wrote:
So when the exception is thrown within Foo destructor (and it's
bad on it's own but can easily happen as destructors aren't
nothrow @nogc by default).
Is this behavior expected?
This is a compiler/language bug. It was fixed in
On 10/16/20 6:12 AM, tchaloupka wrote:
> struct Foo {
> Bar bar;
> bool err;
>
> ~this() {
> // scope(failure) destroy(bar); // < this fixes the Bar
> destructor call
> enforce(!err, "Test err");
Well, that check means "cannot continue", which means the compiler
Found a pretty nasty bug in vibe-d:
https://github.com/vibe-d/vibe.d/issues/2484
And it's caused by this behavior.
```D
import std;
struct Foo {
Bar bar;
bool err;
~this() {
// scope(failure) destroy(bar); // < this fixes the Bar
destructor call
enforce(!err,
On Saturday, March 2, 2019 4:32:53 AM MST JN via Digitalmars-d-learn wrote:
> Compare this D code:
>
> import std.stdio;
>
> struct Foo
> {
> ~this()
> {
> writeln("Destroying foo");
> }
> }
>
> void main()
> {
> Foo[string] foos;
>
> foos["bar"] = Foo();
>
/dlang.org/spec/struct.html#struct-destructor
"Destructors are called when an object goes out of scope. Their
purpose is to free up resources owned by the struct object."
Example:
import std.stdio;
struct S
{
~this()
{
import std.stdio;
writeln(&q
Compare this D code:
import std.stdio;
struct Foo
{
~this()
{
writeln("Destroying foo");
}
}
void main()
{
Foo[string] foos;
foos["bar"] = Foo();
writeln("Preparing to destroy");
foos.remove("bar");
writeln("Ending program");
}
and equivalent C++ code:
On 7/19/18 4:50 AM, RazvanN wrote:
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is annotated with
@disable
I was expecting that disabling the destructor would make it as
On Thursday, 19 July 2018 at 10:04:34 UTC, RazvanN wrote:
On Thursday, 19 July 2018 at 09:50:32 UTC, Jim Balter wrote:
On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
On Thursday, July 19, 2018 10:04:34 RazvanN via Digitalmars-d-learn wrote:
> I just don't understand why you would ever mark the destructor of
> a struct with @disable. When is that useful? If it's not, why not
> just forbit it?
There's nothing special about destructors here. You can @disable any
On Thursday, 19 July 2018 at 10:04:34 UTC, RazvanN wrote:
I just don't understand why you would ever mark the destructor
of a struct with @disable. When is that useful? If it's not,
why not just forbit it?
struct S1 {
~this() { /* stuff */ }
}
struct S2 {
S1 s;
@disable ~this();
On Thursday, 19 July 2018 at 09:50:32 UTC, Jim Balter wrote:
On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is
On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is
annotated with @disable
I was expecting that disabling the
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is
annotated with @disable
I was expecting that disabling the destructor would make it as if
the struct does not have a
.
Another less likely, but possible, way is to have the struct
destructor to do the scope(exit) part only if it gets destroyed
in some certain state. For example, if the transaction receiver
is null.
I need to perform an action, in multiple separate functions, if
scope exits with an exception. The trouble is I don't want to
litter my code with scope(failure) everywhere. I already create
an instance of a struct at each location, with the sole purpose
of doing things at the end of scope.
So
On Wednesday, 21 December 2016 at 17:49:22 UTC, kinke wrote:
Basic stuff such as this is appropriately tested. The named
return value optimization is enforced by D (incl. unoptimized
builds), so behavior doesn't change by this optimization. It's
you who changed the behavior by removing the if.
On 12/21/2016 07:01 AM, Eugene Wissner wrote:
> Isn't an optimization that changes the behavior bad? I had a crash in
> the code where the destructor did something meaningfull, freed the
> memory (the same pointer) twice.
Sounds like you ended up with two objects that owned the same resource.
On Wednesday, 21 December 2016 at 18:02:54 UTC, bauss wrote:
It removes an unnecessary allocation for the returning copy of
the struct, as the return value is never used. Hence why it's
pointless that it would be compiled anyway.
That's incorrect, it doesn't have anything to do with the
On Wednesday, 21 December 2016 at 15:01:20 UTC, Eugene Wissner
wrote:
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints
On Wednesday, 21 December 2016 at 15:01:20 UTC, Eugene Wissner
wrote:
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints "Destruct" only 2 times - the behavior
I'm expecting. Why?
Possibly to do
On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints "Destruct" only 2 times - the behavior
I'm expecting. Why?
Possibly to do
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
This prints 3 times "Destruct" with dmd 0.072.1. If I remove
the if block, it prints "Destruct" only 2 times - the behavior
I'm expecting. Why?
Possibly to do with named return value optimisation.
On Wednesday, 21 December 2016 at 12:32:51 UTC, Nicholas Wilson
wrote:
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
Consider we have a function that returns a struct. So for
example:
import std.stdio;
struct A {
~this() {
writeln("Destruct");
}
}
A
On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner
wrote:
Consider we have a function that returns a struct. So for
example:
import std.stdio;
struct A {
~this() {
writeln("Destruct");
}
}
A myFunc() {
auto a = A(), b = A();
if (false) {
return a;
Consider we have a function that returns a struct. So for example:
import std.stdio;
struct A {
~this() {
writeln("Destruct");
}
}
A myFunc() {
auto a = A(), b = A();
if (false) {
return a;
}
return b;
}
void main() {
myFunc();
}
This prints 3
module main;
import std.stdio;
void main(string[] args)
{
with(test())
{
foo();
}
}
struct test
{
void foo()
{
writeln(foo);
}
~this()
{
writeln(destoy);
}
}
prints:
On Tuesday, 3 February 2015 at 05:09:55 UTC, Ali Çehreli wrote:
Yes, it's a known bug that has been fixed on git head but I
can't find the bug report. :-/
Ok cool, good to know.
The new output:
foo
destoy
Yes, without the 'r'. ;)
Ali
Yeah, i noticed the typo right after I posted...
On 02/02/2015 07:51 PM, Tofu Ninja wrote:
module main;
import std.stdio;
void main(string[] args)
{
with(test())
{
foo();
}
}
struct test
{
void foo()
{
writeln(foo);
}
~this()
{
writeln(destoy);
}
}
prints:
destroy
Is this a bug? I'm very puzzled; it seems that the destructor
for struct mystruct is called pre-maturely. It should be after
the 'in call(): X 12, Y 0, Z 9 line, should it not?
Using DMD64 D Compiler v2.062 on OSX 10.6.8 and Linux x86_64
Output is:
$ dmd -run named14.d
start of main
in
import std.stdio;
void main() {
struct S {
this(bool a) { writeln( this); }
~this() { writeln( ~this); }
}
writeln(scoped:);
{
auto s = S(true);
}
writeln(with:);
with(S(true)) {
}
}
Output:
scoped:
this
~this
with:
this
On 2011-06-08 13:31, simendsjo wrote:
import std.stdio;
void main() {
struct S {
this(bool a) { writeln( this); }
~this() { writeln( ~this); }
}
writeln(scoped:);
{
auto s = S(true);
}
writeln(with:);
with(S(true)) {
}
}
Output:
scoped:
this
~this
with:
this
Report it
On 08.06.2011 23:14, Jonathan M Davis wrote:
On 2011-06-08 13:31, simendsjo wrote:
import std.stdio;
void main() {
struct S {
this(bool a) { writeln( this); }
~this() { writeln( ~this); }
}
writeln(scoped:);
{
auto s = S(true);
}
writeln(with:);
with(S(true)) {
}
}
Output:
scoped:
this
60 matches
Mail list logo
