Hello!
We have object, for example, objA.
ObjectAType objA = new ObjectAType(...);
// we have a many references to objA
void someFunction1(...)
{
// destroying the objA
destroy(one_of_the_refToObjA);
//
}
void someFunction2()
{
// "segmentation fault" if the objA is
import std.stdio;
class ObjectAType {
bool ok;
this() {ok = true;}
}
void main()
{
auto a = new ObjectAType;
assert(a.ok);
destroy(a);
assert(!a.ok); // a has been destroyed.
}
This method of detection of collected objects is what I needed.
Thanks to everybody for yo
Thank you very much, Steven!
class C1
{
int a1, b1, c1, d1, e1;
string sdb1;
this(string s)
{
sdb1 = s;
a1=90;
b1=19;
d1=22;
e1=23;
}
~this()
{
if (sdb1 == "lll")
If a "destroy" method is used together with GC inside of my
app,it makes my app unstable.
In this case I need to choose how to destroy my objects: 1)
always manually by method "destroy", but without GC; 2) or always
automatically by GC, but without using the "destroy" method.
In the first case
Why do you want to use destroy?
The destroy method always calls a dtor of the objects, where I
can destroy some
object's variables in that order that I need, I think. And this
is very good for me, because I have a full control of the
object's destroying stage.
But if I use the GC, I have no gar
If we are using a DMD realization of destroying of
objects, happens the following: at the calling the «destroy»
method the calling of dtor takes place always, and then the
object which is being destroyed is initialized by the default
state. In other words, after calling «destroy» method,
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, &m_tex);
glTexImage2D(); // texture in video memory
On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote:
Exactly. That's why it's wrong to rely on the GC if you need
deterministic resource management. It's simply the wrong tool
for that.
Unfortunately, the "right" tools are a bit awkward to use, for
the time being. I still have h
On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:
sure. but when it comes, for example, for big data structures
with
complex cross-references, you'll inevitably found that you
either leaking
memory, or writing your own half-backed semi-working GC
realization.
ah, good luck doing ef
interface IA
{
void fnA();
}
interface IB
{
void fnB();
}
shared interface IC : IA, IB
{
void fnC();
}
shared class C : IA, IB
{
override void fnA() // Error: function main.C.fnA does not
override any function, did you mean to override 'main.IA.fnA'?
{
On Sunday, 15 February 2015 at 11:30:46 UTC, anonymous wrote:
On Sunday, 15 February 2015 at 10:43:46 UTC, Andrey Derzhavin
wrote:
what is wrong in declarations, if I need to declare shared
classes D and C?
`shared` on a class/interface makes all members shared. And
that's all it does.
So t
On Sunday, 15 February 2015 at 14:59:20 UTC, anonymous wrote:
Hm? Works for me. What error do you get, or what doesn't work?
Which compiler are you using, which version?
The error "Error: function main.C.fnA does not
override any function, did you mean to override 'main.IA.fnA'?"
has occured
On Sunday, 15 February 2015 at 14:59:20 UTC, anonymous wrote:
Sorry everything is OK. It's my fault. Thanks))
14 matches
Mail list logo
