Re: free causes exception
V Tue, 26 Jan 2016 14:20:29 +
Igor via Digitalmars-d-learn
napsáno:
> I have successfully malloc'ed an object but when I go to free it
> in the destructor I get an exception. The destructor simply has
>
> ~this() // destructor for Foo
> {
> core.stdc.stdlib.free(&this);
> }
>
>
> auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize,
> App))[0..__traits(classInstanceSize, App)];
> auto app = cast(App)emplace!App(buffer[]);
>
> I tried to retain a ptr to buffer and free that but still no
> good. I also get a depreciation warning that &this is not an
> lvalue. Hopefully I don't have to keep a ptr around to this
> simply to free it and avoid future issues?
>
> So how am I suppose to free an object?
>
>
core.stdc.stdlib.free(cast(void *)this);
Re: free causes exception
V Tue, 26 Jan 2016 15:24:00 + Igor via Digitalmars-d-learn napsáno: > On Tuesday, 26 January 2016 at 14:48:48 UTC, Daniel Kozak wrote: > > V Tue, 26 Jan 2016 14:20:29 + > > Igor via Digitalmars-d-learn > > napsáno: > > > >> [...] > > > > core.stdc.stdlib.free(cast(void *)this); > > I still get an exception: > > Exception thrown at 0x7FF6C7CA3700 in test.exe: 0xC005: > Access violation reading location 0x. Can you post full code?
Re: free causes exception
On Tuesday, 26 January 2016 at 14:48:48 UTC, Daniel Kozak wrote: V Tue, 26 Jan 2016 14:20:29 + Igor via Digitalmars-d-learn napsáno: [...] core.stdc.stdlib.free(cast(void *)this); I still get an exception: Exception thrown at 0x7FF6C7CA3700 in test.exe: 0xC005: Access violation reading location 0x.
Re: free causes exception
On 01/26/2016 06:20 AM, Igor wrote:
> I have successfully malloc'ed an object but when I go to free it in the
> destructor I get an exception. The destructor simply has
>
> ~this() // destructor for Foo
> {
> core.stdc.stdlib.free(&this);
> }
That design suggests a complexity regarding object responsibilities:
Assuming that the object was constructed on a piece of memory that it
did *not* allocate, the memory was owned by somebody else. In that case
and in general, freeing the memory should be the responsibility of that
other somebody as well.
Even if it is acceptable, you must also make sure that opAssign() and
post-blit do the right thing: no two object should own the same piece of
memory.
Ali
Re: free causes exception
On 1/26/16 9:20 AM, Igor wrote:
I have successfully malloc'ed an object but when I go to free it in the
destructor I get an exception. The destructor simply has
~this() // destructor for Foo
{
core.stdc.stdlib.free(&this);
}
auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize,
App))[0..__traits(classInstanceSize, App)];
auto app = cast(App)emplace!App(buffer[]);
I tried to retain a ptr to buffer and free that but still no good. I
also get a depreciation warning that &this is not an lvalue. Hopefully I
don't have to keep a ptr around to this simply to free it and avoid
future issues?
So how am I suppose to free an object?
Don't do it in the destructor.
I can only imagine that you are triggering the destructor with destroy?
In this case, destroy is calling the destructor, but then tries to zero
the memory (which has already been freed).
There is a mechanism D supports (but I believe is deprecated) by
overriding new and delete. You may want to try that. It's deprecated,
but has been for years and years, and I doubt it's going away any time soon.
A class shouldn't care how it's allocated or destroyed. That is for the
memory manager to worry about.
-Steve
Re: free causes exception
On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven Schveighoffer
wrote:
On 1/26/16 9:20 AM, Igor wrote:
I have successfully malloc'ed an object but when I go to free
it in the
destructor I get an exception. The destructor simply has
~this() // destructor for Foo
{
core.stdc.stdlib.free(&this);
}
auto buffer =
core.stdc.stdlib.malloc(__traits(classInstanceSize,
App))[0..__traits(classInstanceSize, App)];
auto app = cast(App)emplace!App(buffer[]);
I tried to retain a ptr to buffer and free that but still no
good. I
also get a depreciation warning that &this is not an lvalue.
Hopefully I
don't have to keep a ptr around to this simply to free it and
avoid
future issues?
So how am I suppose to free an object?
Don't do it in the destructor.
I can only imagine that you are triggering the destructor with
destroy? In this case, destroy is calling the destructor, but
then tries to zero the memory (which has already been freed).
There is a mechanism D supports (but I believe is deprecated)
by overriding new and delete. You may want to try that. It's
deprecated, but has been for years and years, and I doubt it's
going away any time soon.
A class shouldn't care how it's allocated or destroyed. That is
for the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't
have to worry about the god forsaken memory manager. Why is it so
difficult? I create the object and release it when I need to.
I can replace the destroy(f) with free(inline the code) but I
don't see why that should matter. The whole point of destructors
is to do this sort of stuff. That's why they were invented in the
first place!?!
Re: free causes exception
On Tuesday, 26 January 2016 at 19:34:22 UTC, Ali Çehreli wrote:
On 01/26/2016 06:20 AM, Igor wrote:
> I have successfully malloc'ed an object but when I go to free
it in the
> destructor I get an exception. The destructor simply has
>
> ~this() // destructor for Foo
> {
> core.stdc.stdlib.free(&this);
> }
That design suggests a complexity regarding object
responsibilities: Assuming that the object was constructed on a
piece of memory that it did *not* allocate, the memory was
owned by somebody else. In that case and in general, freeing
the memory should be the responsibility of that other somebody
as well.
Even if it is acceptable, you must also make sure that
opAssign() and post-blit do the right thing: no two object
should own the same piece of memory.
Ali
That shouldn't be the case. I allocate in a static method called
New once. I then deallocate in the destructor. Basically just as
one would do in C++.
I'm not sure about opAssign and post-blit
class Foo
{
~this() // destructor for Foo
{
core.stdc.stdlib.free(cast(void *)this);
}
// Creates a Foo
static public Foo New()
{
auto buffer =
core.stdc.stdlib.malloc(__traits(classInstanceSize,
Foo))[0..__traits(classInstanceSize, Foo)];
auto app = cast(Foo)emplace!Foo(buffer[]);
}
}
hence
auto f = Foo.New();
then .destroy(f);
which is where the crash happens. If I don't destroy, it works
fine + memory leak.
Re: free causes exception
On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote:
On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven
Schveighoffer wrote:
On 1/26/16 9:20 AM, Igor wrote:
I have successfully malloc'ed an object but when I go to free
it in the
destructor I get an exception. The destructor simply has
~this() // destructor for Foo
{
core.stdc.stdlib.free(&this);
}
auto buffer =
core.stdc.stdlib.malloc(__traits(classInstanceSize,
App))[0..__traits(classInstanceSize, App)];
auto app = cast(App)emplace!App(buffer[]);
I tried to retain a ptr to buffer and free that but still no
good. I
also get a depreciation warning that &this is not an lvalue.
Hopefully I
don't have to keep a ptr around to this simply to free it and
avoid
future issues?
So how am I suppose to free an object?
Don't do it in the destructor.
I can only imagine that you are triggering the destructor with
destroy? In this case, destroy is calling the destructor, but
then tries to zero the memory (which has already been freed).
There is a mechanism D supports (but I believe is deprecated)
by overriding new and delete. You may want to try that. It's
deprecated, but has been for years and years, and I doubt it's
going away any time soon.
A class shouldn't care how it's allocated or destroyed. That
is for the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't
have to worry about the god forsaken memory manager. Why is it
so difficult? I create the object and release it when I need to.
I can replace the destroy(f) with free(inline the code) but I
don't see why that should matter. The whole point of
destructors is to do this sort of stuff. That's why they were
invented in the first place!?!
Why not simply:
class Foo { this(Arg1, Arg2) { ... } ... }
// Option A:
import std.typecons : scoped;
auto foo = scoped!Foo(arg1, arg2);
// Option B:
import std.experimental.allocator : make, dispose;
import std.experimental.allocator.mallocator;
auto foo = Mallocator.instance.make!Foo(arg1, arg2);
scope(exit) Mallocator.instance.dispose(foo);
http://dlang.org/phobos/std_typecons#.scoped
http://dlang.org/phobos/std_experimental_allocator
Re: free causes exception
On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote: On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven Schveighoffer wrote: On 1/26/16 9:20 AM, Igor wrote: [...] Don't do it in the destructor. I can only imagine that you are triggering the destructor with destroy? In this case, destroy is calling the destructor, but then tries to zero the memory (which has already been freed). There is a mechanism D supports (but I believe is deprecated) by overriding new and delete. You may want to try that. It's deprecated, but has been for years and years, and I doubt it's going away any time soon. A class shouldn't care how it's allocated or destroyed. That is for the memory manager to worry about. um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to. I can replace the destroy(f) with free(inline the code) but I don't see why that should matter. The whole point of destructors is to do this sort of stuff. That's why they were invented in the first place!?! Destructors are meant to destroy the members of the object, not the object itself. An object should be freed by the destructor of its owner and so on, transitively. A class should not have a hard coded dependency on malloc/free, or the GC. You should strive to design it in such a way that the clients of the class are free to decide how to manage its memory.
Re: free causes exception
On 01/26/2016 01:21 PM, Igor wrote:
> I allocate in a static method called New once. I then deallocate in the
> destructor. Basically just as one would do in C++.
I would never do that in even C++. I don't know any C++ idiom that
warrants 'delete this' where superior alternatives cannot be used.
> class Foo
> {
> ~this() // destructor for Foo
> {
> core.stdc.stdlib.free(cast(void *)this);
> }
>
> // Creates a Foo
> static public Foo New()
> {
> auto buffer =
> core.stdc.stdlib.malloc(__traits(classInstanceSize,
> Foo))[0..__traits(classInstanceSize, Foo)];
> auto app = cast(Foo)emplace!Foo(buffer[]);
> }
> }
>
> hence
>
> auto f = Foo.New();
>
> then .destroy(f);
Something else in the program must have something to do with it. I don't
see the crash with the following program:
import std.stdio;
import core.stdc.stdlib;
import std.conv;
class Foo
{
~this() // destructor for Foo
{
core.stdc.stdlib.free(cast(void *)this);
}
// Creates a Foo
static public Foo New()
{
auto buffer =
core.stdc.stdlib.malloc(
__traits(classInstanceSize, Foo))
[0..__traits(classInstanceSize, Foo)];
auto app = cast(Foo)emplace!Foo(buffer[]);
return app;
}
}
void main() {
auto f = Foo.New();
.destroy(f);
}
Ali
Re: free causes exception
On Tuesday, 26 January 2016 at 21:23:28 UTC, Igor wrote: um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to. He's talking about *your* memory manager, whatever system you have set up to allocate and deallocate memory. I can replace the destroy(f) with free(inline the code) but I don't see why that should matter. The whole point of destructors is to do this sort of stuff. That's why they were invented in the first place!?! Not in D! You have to get your mind out of C++ mode when programming in D. D is not C++, no matter how similar they are, and there are idioms that work well in C++ that do not work in D. There are cases where D's destructors behave like those in C++, but not always. Since this approach is failing for you, I suggest you make a function or template that can take any object you've manually allocated, call destroy on it, then deallocate it. The destructor can still clean up any resources the object maintains, but the responsibility for deallocating the object will be taken out of the destructor. It also ensures that deallocation does not interfere with the operation of destroy.
Re: free causes exception
On Tuesday, 26 January 2016 at 21:21:29 UTC, Igor wrote: That shouldn't be the case. I allocate in a static method called New once. I then deallocate in the destructor. Basically just as one would do in C++. You can't deallocate in destructor in C++, because an object can be embedded in another object, so if it's destructor deallocates itself, it will deallocate the container object before it finishes its destruction. It's delete operator that deallocates memory in C++.
Re: free causes exception
On 1/26/16 4:23 PM, Igor wrote:
On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven Schveighoffer wrote:
On 1/26/16 9:20 AM, Igor wrote:
I have successfully malloc'ed an object but when I go to free it in the
destructor I get an exception. The destructor simply has
~this() // destructor for Foo
{
core.stdc.stdlib.free(&this);
}
auto buffer = core.stdc.stdlib.malloc(__traits(classInstanceSize,
App))[0..__traits(classInstanceSize, App)];
auto app = cast(App)emplace!App(buffer[]);
I tried to retain a ptr to buffer and free that but still no good. I
also get a depreciation warning that &this is not an lvalue. Hopefully I
don't have to keep a ptr around to this simply to free it and avoid
future issues?
So how am I suppose to free an object?
Don't do it in the destructor.
I can only imagine that you are triggering the destructor with
destroy? In this case, destroy is calling the destructor, but then
tries to zero the memory (which has already been freed).
There is a mechanism D supports (but I believe is deprecated) by
overriding new and delete. You may want to try that. It's deprecated,
but has been for years and years, and I doubt it's going away any time
soon.
A class shouldn't care how it's allocated or destroyed. That is for
the memory manager to worry about.
um? Memory manager? I am doing it manually C++ style so I don't have to
worry about the god forsaken memory manager. Why is it so difficult? I
create the object and release it when I need to.
As Mike said, I mean whatever you are using for memory management. The
class is not responsible for allocating or deallocating itself, just
initializing itself and deinitializing itself.
So if you use malloc and free, that is your memory manager.
I can replace the destroy(f) with free(inline the code) but I don't see
why that should matter. The whole point of destructors is to do this
sort of stuff. That's why they were invented in the first place!?!
It isn't even this way in C++. No destructors deallocate 'this'.
All D destructors should destroy all the members. And generally
speaking, if you ever plan to use a class with the GC, you should only
destroy non-GC members. The GC members may already be destroyed.
-Steve
Re: free causes exception
On Wednesday, 27 January 2016 at 14:31:20 UTC, Steven Schveighoffer wrote: On 1/26/16 4:23 PM, Igor wrote: On Tuesday, 26 January 2016 at 20:17:20 UTC, Steven Schveighoffer wrote: [...] um? Memory manager? I am doing it manually C++ style so I don't have to worry about the god forsaken memory manager. Why is it so difficult? I create the object and release it when I need to. As Mike said, I mean whatever you are using for memory management. The class is not responsible for allocating or deallocating itself, just initializing itself and deinitializing itself. So if you use malloc and free, that is your memory manager. I can replace the destroy(f) with free(inline the code) but I don't see why that should matter. The whole point of destructors is to do this sort of stuff. That's why they were invented in the first place!?! It isn't even this way in C++. No destructors deallocate 'this'. All D destructors should destroy all the members. And generally speaking, if you ever plan to use a class with the GC, you should only destroy non-GC members. The GC members may already be destroyed. -Steve There needs to be better docs on this? Or at least someone needs to provide a link! ;) Why can there be an "deplace" equivalent to emplace? Everone says it's so easy not to use the GC in D yet I can't seem to find any real world examples ;/
Re: free causes exception
On 1/27/16 5:35 PM, Igor wrote: On Wednesday, 27 January 2016 at 14:31:20 UTC, Steven Schveighoffer wrote: All D destructors should destroy all the members. And generally speaking, if you ever plan to use a class with the GC, you should only destroy non-GC members. The GC members may already be destroyed. BTW, I wrote that wrong, I should have said "All D destructors *should do is* destroy all the members." In other words, you shouldn't do anything but destroy members. There needs to be better docs on this? Or at least someone needs to provide a link! ;) http://dlang.org/spec/class.html#destructors "Furthermore, the order in which the garbage collector calls destructors for unreference objects is not specified. This means that when the garbage collector calls a destructor for an object of a class that has members that are references to garbage collected objects, those references may no longer be valid. **This means that destructors cannot reference sub objects.**" (emphasis mine) Why can there be an "deplace" equivalent to emplace? emplace is not responsible for allocation, it just does all the necessary things to place an object inside memory you provide (wherever it came from), and call the proper constructor. The opposite of emplace is destroy. This calls the destructor and resets the class to a "destroyed" state (so calling destroy on a class a second time will not call the destructor again). Everone says it's so easy not to use the GC in D yet I can't seem to find any real world examples ;/ The easiness of doing it is a judgment call. However, it is possible. I'm sure there are examples out there, but I'm not well versed in where to find them. -Steve
