www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - ~= call copy ctor?

reply "Namespace" <rswhite4 googlemail.com> writes:
I have a 2 questions.

I have this code:

[code]
import std.stdio;

struct Test {
public:
	this(int i = 0) {
		writeln("Test CTor.");
	}

	this(this) {
		writeln("Test Copy CTor");
	}

	~this() {
		writeln("Test DTor");
	}
}

Test[] _arr;

void copy_save(Test t) {
	_arr ~= t;
}

void by_ref_save(ref Test t) {
	_arr ~= t;
}

[/code]

Why get i with

[code]
void main() {
	Test t = 42;

	by_ref_save(t);
}
[/code]

this output:

Test CTor.
Test Copy CTor
Test DTor

?

Why t is copied?

And the same if i have this:

[code]
void main() {
	Test t = 42;

	copy_save(t);
}
[/code]

t is already a clone. Why it is copied again?

Thanks in advance. :)
Jul 19 2012
next sibling parent Matthias Walter <xammy xammy.info> writes:
On 07/19/2012 02:27 PM, Namespace wrote:
 I have a 2 questions.
 
 I have this code:
 
 [code]
 import std.stdio;
 
 struct Test {
 public:
     this(int i = 0) {
         writeln("Test CTor.");
     }
 
     this(this) {
         writeln("Test Copy CTor");
     }
 
     ~this() {
         writeln("Test DTor");
     }
 }
 
 Test[] _arr;
 
 void copy_save(Test t) {
     _arr ~= t;
 }
 
 void by_ref_save(ref Test t) {
     _arr ~= t;
 }
 
 [/code]
 
 Why get i with
 
 [code]
 void main() {
     Test t = 42;
 
     by_ref_save(t);
 }
 [/code]
 
 this output:
 
 Test CTor.
 Test Copy CTor
 Test DTor

As you mentioned in the subject the copy constructor is not called while the struct is passed by reference but on array concatenation. But this must occur since the array has its memory region and the original variable t in main() also has. Since they are different, at some point the struct must be copied from t in main() into the array. The "ref" only ensures that it is passed via reference (a pointer to the memory of t in main()) to the function by_ref_save().
 And the same if i have this:
 
 [code]
 void main() {
     Test t = 42;
 
     copy_save(t);
 }
 [/code]
 
 t is already a clone. Why it is copied again?

Here it is once copied from t in main() into the local variable t in copy_save() and then copied (as in your 1st example) into the array. Imagine the copy_save routine is in a different module and only its signature is exposed to main. When calling the function, the compiler does not know what happens inside copy_save but it must put the variable onto the stack at the position of the first parameter (well, in this case it is probably put into a CPU register, but that doesn't matter here). Then, when copy_save is invoked it only knows the local variable which it then copies into the array memory (after enlarging the array). It *may* be the when you enable compiler optimizations (-O -inline) that copy_save gets inlined and hence the compiler can optimize one of the copy calls away. But that I don't know for sure. Best regards, Matthias
Jul 19 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Is there any way to avoid the implizit copy ctor by array 
concatenation?
Or is the only way to use a pointer?
Jul 19 2012
prev sibling next sibling parent Matthias Walter <xammy xammy.info> writes:
On 07/19/2012 03:00 PM, Namespace wrote:
 Is there any way to avoid the implizit copy ctor by array concatenation?
 Or is the only way to use a pointer?

Yes, in some way you have to. If you want to not copy a lot of data (or avoid additional on-copy effort) you either have to you pointers explicitly (Test*[]) or implicitly. The latter works e.g. by making Test a class which means that the variable actually does store a pointer to the instance. Note that for struct pointers you should not escape them, i.e. have a variable local in a function, puts its address into some array and returning that array. Since the local variable is gone, the pointer is invalid as well. (Nothing happens if you do not access it). Best regards, Matthias
Jul 19 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Ok, so if a put a struct into an array, it will copied into the 
array. But then? How it is deleted?

For exmaple, i have this code:

[code]
import std.stdio;

struct Test {
public:
	static uint _counter;

	this(int i = 0) {
		writeln("Test CTor.");

		_counter++;
	}

	this(this) {
		writeln("Test Copy CTor");

		_counter++;
	}

	~this() {
		writeln("Test DTor");

		if (_counter > 0) {
			_counter--;
		}
	}
}

void main() {
	{
		Test[] _arr;

		void copy_save(Test t) {
			_arr ~= t;
		}

		void by_ref_save(ref Test t) {
			_arr ~= t;
		}

		Test t = 42;

		//copy_save(t);
		by_ref_save(t);

		writeln("end scope");
	}

	writefln("Counter: %d", Test._counter);
}
[/code]

_counter is still 1 but the scope is released. How is that 
possible?
Even with _arr.clear(); at the end of the scope, _counter is 
still 1.
I see one CTor and one Copy CTor but only one DTor.
Jul 19 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
Use std.algorithm.move if you want to avoid the copy ctor call.
Jul 19 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 19 July 2012 at 14:31:02 UTC, Timon Gehr wrote:
 Use std.algorithm.move if you want to avoid the copy ctor call.

With "move" I see the lost DTor call, but not without. Ist that a bug? o.O
Jul 19 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 19 July 2012 at 15:36:01 UTC, Namespace wrote:
 _counter is still 1 but the scope is released. How is that 
 possible?
 Even with _arr.clear(); at the end of the scope, _counter is 
 still 1.
 I see one CTor and one Copy CTor but only one DTor.

_arr is actually a dynamic array, which allocates from the garbage collector. When _arr goes out of scope, you are only destroying the "Slice" that is looking at the data, but not the data itself. You have to wait until the Garbage Collector runs and collects. Either that, or use a stack allocated static array, but I wouldn't recommend it. Furthermore, D does not actually guarantee that all your objects are destroyed (eg. destructors called) when the program ends. D's approach is "The program has ended, ergo anything left in memory is moot. Just let the OS clear it." If you really need RAII, you can use RefCounted objects, such as RefCounted! directly, or by using Array.
Jul 19 2012
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
New question:

I have this code:
[code]
import std.stdio;

struct Test {
public:
	this(int i = 0) {
		writeln("CTOR");
	}

	this(this) {
		writeln("COPY CTOR");
	}

	~this() {
		writeln("DTOR");
	}
}

void main() {
	Test[] _arr;

	_arr ~= Test(0);

	writeln("end main");
}
[/code]

And as output i see:

CTOR
COPY CTOR
DTOR
end main

Why on earth....?

I create a struct Test. It's not a local variable, it's directly 
assigned,
but it is copied and the original is destroyed. Why?
If i store something important, like a pointer, in Test and will 
free him in the DTOR i cannot assign this way Test's to an array, 
because the pointer was deleted because the DTOr was called.

I think the correct output would be:

CTOR
end main

Maybe DTOR before "end main". But not COPY CTOR anywhere.
Jul 20 2012
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/20/2012 09:02 AM, Namespace wrote:
 If i  disable the postblit i get a strange behaviour:

Something is not right. Compiled with dmd 2.059, the linker says: undefined reference to `_D6deneme4Test10__postblitMFZv' 64 bit Linux... Ali
Jul 20 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/20/2012 02:54 PM, Namespace wrote:
 On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote:
 On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
 Why comes "DTOR class" _after_ "end main" and not before?
 If i write "scope TestC c = ...;" it is correct, but i read that
 "scope" will be deprecated. Can someone explain me that behaviour?

The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David

Really? Holy crap... Can i correct this? And will "scope" for classes really deprecated?

The truth is, the destructor may not ever be called. Yes scope is (will be?) deprecated and is replaced by std.typecons.scoped: import std.typecons; // ... auto c = scoped!TestC(); Prints: begin scope CTOR class CTOR struct end scope DTOR struct DTOR class end main Ali
Jul 20 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Fri, 20 Jul 2012 14:50:19 +0100, Namespace <rswhite4 googlemail.com>  
wrote:

 New question:

 I have this code:
 [code]
 import std.stdio;

 struct Test {
 public:
 	this(int i = 0) {
 		writeln("CTOR");
 	}

 	this(this) {
 		writeln("COPY CTOR");
 	}

 	~this() {
 		writeln("DTOR");
 	}
 }

 void main() {
 	Test[] _arr;

 	_arr ~= Test(0);

 	writeln("end main");
 }
 [/code]

 And as output i see:

 CTOR
 COPY CTOR
 DTOR
 end main

 Why on earth....?

 I create a struct Test. It's not a local variable, it's directly  
 assigned,
 but it is copied and the original is destroyed. Why?

Because that's how assignment works, rhs is evaluated, struct is constructed, then assigned to lhs, lhs copies the variable into the array. Your variable is a struct, so it is copied. Use a pointer instead and the pointer is copied into the array. Use a reference and the reference is copied into the array. The variable, whatever it is, is /always/ copied into the array. It's a long standing optimisation issue and the reason for the recent distinction between lvalues and rvalues made in C++0x for their new 'move' optimisation where assignments involving rvalues/temporaries can move the rvalue instead of copying - or something like that, I'm a bit vague having watched a vid a few days back and not paying a lot of attention to it, sorry. Does: _arr[0] = Test(0); avoid the copy construction? R
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
For correctness:
A copy call is still fine if I assign a local variable to _arr 
(even if i think that ref parameters should'nt be copied), but i 
think that it is not fine if I assign directly, as you see above.
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Does:

 _arr[0] = Test(0);

 avoid the copy construction?

 R

[code] void main() { Test[2] _arr = void; _arr[0] = Test(0); writeln("end main"); } [/code] puts CTOR DTOR end main DTOR DTOR If i wrote Test[] instead of Test[2] i get an exception. There is no dynamic way for that problem? Even with "move" it prints "COPY CTOR"...
Jul 20 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 20, 2012 15:50:19 Namespace wrote:
 Why on earth....?

http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move- semantics If you want to guarantee that you don't get any copies while moving an object around, it needs to be a reference type (which would include a pointer to a value type). - Jonathan M Davis
Jul 20 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 20 July 2012 at 13:50:20 UTC, Namespace wrote:
 New question:

 I have this code:
 [code]
 import std.stdio;

 struct Test {
 public:
 	this(int i = 0) {
 		writeln("CTOR");
 	}

Be careful about "int i = O". Structs are not allowed to have default constructors. This is so they can have a static default value of Test.init which can be efficiently mem-copied.
 	this(this) {
 		writeln("COPY CTOR");
 	}

 	~this() {
 		writeln("DTOR");
 	}
 }

 void main() {
 	Test[] _arr;

 	_arr ~= Test(0);

 	writeln("end main");
 }
 [/code]

 And as output i see:

 CTOR
 COPY CTOR
 DTOR
 end main

 Why on earth....?

 I create a struct Test. It's not a local variable, it's 
 directly assigned, but it is copied and the original is 
 destroyed. Why?

Seems perfectly reasonable to me. ~= is an operator, eg, a function that needs arguments. Test(0) _IS_ a local variable that you pass as an argument in main (CTOR), and you pass it to the operator. From there, operator!"~=" will build a new object straight from the old object (COPY CTOR). Then, you return to main, and the stack local Test(T) object is destroyed (DTOR). Finally, main ends (end main). The last missing destructor is the one of the object in the array.
 If i store something important, like a pointer, in Test and 
 will free him in the DTOR i cannot assign this way Test's to an 
 array, because the pointer was deleted because the DTOr was 
 called.

Well if you do that, then your object can't be copied ever. -------- Here is a funner test though: Though: Test TestBuilder(int i) { return Test(i); } void main() { Test[] _arr; _arr ~= TestBuilder(3); writeln("end main"); } Output: CTOR COPY CTOR end main _This_ smells funky to me. There should be a destroyer somewhere in there: At the end of the day, there is only 1 element left in memory, but two have been created, yet none have been destroyed !?
Jul 20 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 20, 2012 08:08:47 Jonathan M Davis wrote:
 On Friday, July 20, 2012 15:50:19 Namespace wrote:
 Why on earth....?

http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move - semantics If you want to guarantee that you don't get any copies while moving an object around, it needs to be a reference type (which would include a pointer to a value type).

Alternatively, you can disable this(this), which would make copies illegal, but then I'd be worried about code breaking when the compiler adjusted some of its optimizations (though it would generally be unlikely for a move to become a copy - the opposite would be far more likely, which wouldn't break anything). - Jonathan M Davs
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
If i  disable the postblit i get a strange behaviour:

[code]
struct Test {
public:
	int _id;

	this(int i) {
		_id = i;

		writeln("CTOR");
	}

	 disable
	this(this);

	~this() {
		writeln("DTOR");
	}
}

void main() {
	Test[] _arr;

	_arr ~= Test(42);

	writeln(_arr[0]._id);

	writeln("end main");
}
[/code]

prints:

CTOR
DTOR
42
end main

The DTor is called _before_ i write Test's id but i can still 
print the correct id.
Implicit Copy CTor? ;)
Jul 20 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 20 July 2012 at 16:02:18 UTC, Namespace wrote:
 If i  disable the postblit i get a strange behaviour:

 	 disable
 	this(this);

I think disable is broken right now, and does nothing (ei: allows a default implementation of this(this) ). If you replace by the C++ "declare but don't implement" scheme: "this(this);" Then you get a normal linker error. So to answer your question: Yes, implicit Copy CTor.
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
It seems structs are very broken right now...
I would use classes, but they are nullable and without 
correct/good error handling instead of "access violation" i 
prefer structs.
Funny, all variables are default initialized which would be even 
done by the OS. But Null Exceptions aren't exists and D let the 
OS thrown an uninformative message (at least on windows).

I think the only "good" decision is to store important thinks 
like pointers eternal and let the GC free them. Or use an 
reference counter.
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Something else which is against classes: incorrect scope
behaviour:

[code]
import std.stdio;

class TestC {
public:
	this() {
		writeln("CTOR class");
	}

	~this() {
		writeln("DTOR class");
	}
}

struct TestS {
public:
	this(int i) {
		writeln("CTOR struct");
	}

	~this() {
		writeln("DTOR struct");
	}
}

void main() {
	{
		writeln("begin scope");

		TestC c  = new TestC();
		TestS s = TestS(42);

		writeln("end scope");
	}

	writeln("end main");
}
[/code]

Prints

begin scope
CTOR class
CTOR struct
end scope
DTOR struct
end main
DTOR class

Why comes "DTOR class" _after_ "end main" and not before?
If i write "scope TestC c = ...;" it is correct, but i read that
"scope" will be deprecated. Can someone explain me that behaviour?
Jul 20 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
 Why comes "DTOR class" _after_ "end main" and not before?
 If i write "scope TestC c = ...;" it is correct, but i read that
 "scope" will be deprecated. Can someone explain me that 
 behaviour?

The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote:
 On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
 Why comes "DTOR class" _after_ "end main" and not before?
 If i write "scope TestC c = ...;" it is correct, but i read 
 that
 "scope" will be deprecated. Can someone explain me that 
 behaviour?

The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David

Really? Holy crap... Can i correct this? And will "scope" for classes really deprecated?
Jul 20 2012
prev sibling next sibling parent "Lukasz" <wrzoski gmail.com> writes:
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
 Something else which is against classes: incorrect scope
 behaviour:

 [code]
 import std.stdio;

 class TestC {
 public:
 	this() {
 		writeln("CTOR class");
 	}

 	~this() {
 		writeln("DTOR class");
 	}
 }

 struct TestS {
 public:
 	this(int i) {
 		writeln("CTOR struct");
 	}

 	~this() {
 		writeln("DTOR struct");
 	}
 }

 void main() {
 	{
 		writeln("begin scope");

 		TestC c  = new TestC();
 		TestS s = TestS(42);

 		writeln("end scope");
 	}

 	writeln("end main");
 }
 [/code]

 Prints

 begin scope
 CTOR class
 CTOR struct
 end scope
 DTOR struct
 end main
 DTOR class

 Why comes "DTOR class" _after_ "end main" and not before?
 If i write "scope TestC c = ...;" it is correct, but i read that
 "scope" will be deprecated. Can someone explain me that 
 behaviour?

That happens because the destructor is being called when Garbage collector is cleaning the memory used by the class instance.
Jul 20 2012
prev sibling next sibling parent "Lukasz" <wrzoski gmail.com> writes:
On Friday, 20 July 2012 at 21:54:05 UTC, Namespace wrote:
 On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote:
 On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
 Why comes "DTOR class" _after_ "end main" and not before?
 If i write "scope TestC c = ...;" it is correct, but i read 
 that
 "scope" will be deprecated. Can someone explain me that 
 behaviour?

The destructor will be invoked when the GC collects the object, not when the last reference to it goes »out of scope«. David

Really? Holy crap... Can i correct this? And will "scope" for classes really deprecated?

I suppose that you need this: http://dlang.org/phobos/std_typecons.html#scoped
Jul 20 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 That happens because the destructor is being called when Garbage
 collector is cleaning the memory used by the class instance.

How can i call the DTOR or at least a Release method after end of scope? Optimally automatic without any explicit calls.
Jul 20 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 21, 2012 00:04:21 Namespace wrote:
 That happens because the destructor is being called when Garbage
 collector is cleaning the memory used by the class instance.

How can i call the DTOR or at least a Release method after end of scope? Optimally automatic without any explicit calls.

You can use std.typecons.scoped, but then you can't pass the class around, which is exactly what would have happened with scoped. It's inherently unsafe. You can do something like MyObj obj = createObj(); scope(exit) clear(obj); but again, it's going to be destroyed immediately when it leaves scope, and any reference to it which escapes will blow up when you use it. In neither case is there any reference counting. You could use std.typecons.RefCounted, but unless _every_ instance of the object is wrapped in it (unfortunately, it uses alias this on its payload, making it easy to accidentally have references to its payload escape - which will be screwed up when the ref count reaches zero, and the payload is destroyed) The reality of the matter is that if you want deterministic destruction, you should be using a struct, not a class. There are ways to force a class to be destroyed when it leaves scope, but they're inherently unsafe, so they should only be used if you really need them and know what you're doing. Classes are intended to live on the GC heap and be destroyed and freed by the GC when a garbage collection cycle finds that nothing refers to that object anymore. - Jonathan M Davis
Jul 20 2012
prev sibling next sibling parent reply "Kenji Hara" <k.hara.pg gmail.com> writes:
On Friday, 20 July 2012 at 16:02:18 UTC, Namespace wrote:
 If i  disable the postblit i get a strange behaviour:

 [code]
 struct Test {
 public:
 	int _id;

 	this(int i) {
 		_id = i;

 		writeln("CTOR");
 	}

 	 disable
 	this(this);

 	~this() {
 		writeln("DTOR");
 	}
 }

 void main() {
 	Test[] _arr;

 	_arr ~= Test(42);

 	writeln(_arr[0]._id);

 	writeln("end main");
 }
 [/code]

 prints:

 CTOR
 DTOR
 42
 end main

 The DTor is called _before_ i write Test's id but i can still 
 print the correct id.
 Implicit Copy CTor? ;)

Array appending and struct postblit behavior is now broken. I've suggested a pull request to fix these bugs. https://github.com/D-Programming-Language/dmd/pull/1037 Bye. Kenji Hara
Jul 21 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/21/2012 01:41 PM, Namespace wrote:
 Ok. I hope it will not take months. :/

 BTW:
 I have a new strange behaviour by experiementing with structs.

 This code http://dpaste.dzfl.pl/new#top
 works fine, as long as i don't do _any_ operation after line 91.
 If i activate one of the out comment operations or something else, the
 program works still fine but crashes after termination.

 I use Windows 7, dmd 2.059 and compile with
 -w -O -property -unittest -debug

 I have no explanation.

I was able to reproduce the segmentation fault when I compiled with -m32 under a 64 bit Linux environment. And this much is sufficient to reproduce the problem: void main() { Foo f3 = new Foo(); Test t = new Test(f3); writeln("exit main"); // <-- note the added line } One thing that I've noticed is that opAssign() is probably buggy because it overwrites this._ptr without taking care of it first (i.e. it is not doing '*_ptr = null'). But I don't think it is related to the main issue. 'Test' is a class having a struct member. The destructor of that member is accessing memory that is already gone. The last line in main makes it more clear how that destructor is accessing an already destroyed pointer: this this exit main <-- DTOR TEST DESTROY SCOPED make: *** [deneme] Segmentation fault _sc_f._ptr points to f3, which is a local object in main. Ali
Jul 21 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
First, my earlier writeln("exit main"); wasn't achieving much without 
putting everything before it in a scope (like it is below).

On 07/21/2012 03:12 PM, Namespace wrote:
 Cool. Any idea how to fix it?
 Check whether this._ptr! is null && *this._ptr! is null does not help.
 Although I'm just experimenting, but it would be nice to have a solution.

For Test to own a scoped_ptr member that holds on to a local class reference, it must be destroyed when leaving the same scope as the class reference (not potentially much later when the GC kicks in.) One of guaranteeing it is using std.typecons.scoped: import std.typecons; void main() { { Foo f3 = new Foo(); auto t = scoped!Test(f3); } writeln("exit main"); } Now it is destroyed at the end of its scope (the scope is NOT needed for correctness, just for demonstration): this this DTOR TEST exit main <-- Ali
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
That's great. Hope 2.060 fixes many errors, especially in structs.
BTW: When comes 20060? I thought dmd versions come in cycles of 
2-3 months?
Jul 21 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 21, 2012 22:18:40 Namespace wrote:
 That's great. Hope 2.060 fixes many errors, especially in structs.
 BTW: When comes 20060? I thought dmd versions come in cycles of
 2-3 months?

Usually, they do, but Walter got caught up in working on COFF support for Windows and there's no sign of him looking to do a release before that's done. So, it could actually be a few months away. It probably would have been better to do a release _before_ adding all of the COFF support, but that doesn't seem to be happening. That's partially why that whole discussion on creating a D stable branch popped up in the main newsgroup, and there's now a side project created to do that as announced in the announce group (though, they intended to start with 2.060, so I don't know what they're going to do given the delay). - Jonathan M Davis
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Ok. I hope it will not take months. :/

BTW:
I have a new strange behaviour by experiementing with structs.

This code http://dpaste.dzfl.pl/new#top
works fine, as long as i don't do _any_ operation after line 91.
If i activate one of the out comment operations or something 
else, the program works still fine but crashes after termination.

I use Windows 7, dmd 2.059 and compile with
-w -O -property -unittest -debug

I have no explanation.
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I have tried various compiler flag combinations, even without.
But it still crashes. Seems to be a Windows bug.
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 21 July 2012 at 20:48:16 UTC, Namespace wrote:
 I have tried various compiler flag combinations, even without.
 But it still crashes. Seems to be a Windows bug.

I'm stupid... I only compiles but not save my paste. Here is the Code: http://dpaste.dzfl.pl/d385c56b
Jul 21 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, July 21, 2012 22:41:10 Namespace wrote:
 Ok. I hope it will not take months. :/

Well, it's looking like it's going to take at least a month or two, but we'll see. It'll likely depend on how quickly Walter can complete what he's working on. He could have it done by the end of the month for all I know, but adding COFF support will take some time. If you absolutely need the fixes that are currently on github sooner, you can always build the version on github. The easiest way to do that would probably be using DVM: https://bitbucket.org/doob/dvm/wiki/Home
 BTW:
 I have a new strange behaviour by experiementing with structs.
 
 This code http://dpaste.dzfl.pl/new#top
 works fine, as long as i don't do _any_ operation after line 91.
 If i activate one of the out comment operations or something
 else, the program works still fine but crashes after termination.
 
 I use Windows 7, dmd 2.059 and compile with
 -w -O -property -unittest -debug
 
 I have no explanation.

If you find a bug, please report it: http://d.puremagic.com/issues - Jonathan M Davis
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I'm not sure if it's a bug or my code is nonsense. ;)
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Cool. Any idea how to fix it?
Check whether this._ptr! is null && *this._ptr! is null does not 
help.
Although I'm just experimenting, but it would be nice to have a 
solution.
Jul 21 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
The strange constructs in std.algorithm aren't something i like 
to use in real projects. Is there some other solution?
Jul 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 22, 2012 09:48:39 Namespace wrote:
 The strange constructs in std.algorithm aren't something i like
 to use in real projects. Is there some other solution?

And what's so strange about them? That they use ranges? If you start avoiding ranges, you're going to be missing out on a large portions of the standard library very quickly and will be left on your own to provide that functionality or provide it elsewhere. Phobos is very heavily range based and only becoming more so. If you haven't read this tutorial on ranges yet, you probably should: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis
Jul 22 2012
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 21 July 2012 at 21:12:55 UTC, Namespace wrote:
 I'm not sure if it's a bug or my code is nonsense. ;)

While there are some bugs D, you have to realize that D is a garbage collected language, which means you should not rely on objects being destructed in a timely fashion (or at all). Furthermore, it discourages manipulating raw pointers. While experimenting is fine and all (and I encourage it), you really need to embrace the language for what it is, rather than force a design on to it (scoped!). I'd be willing to bet big money you are coming from C++? I had the same difficulties at first.
Jul 22 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/22/2012 01:46 AM, Namespace wrote:
 Oh yes, i mean std.typecons, not std.algorithm, my bad.

 If delete will be deprecated, how can i delete/call dtor of one of my
 objects manually?

In C++, deleting involves two steps: call the destructor and release the memory. It is different in D: releasing memory should be the responsibility of the GC; after all, GC is the one that runs some algorithm that fits its needs. On the other hand, calling the destructor is still acceptable in D because it may be important for the programmer to run the contents earlier than GC would. clear() does that: auto t = new Test(f3); // ... clear(t); // <-- Run the destructor Unfortunately it has a bad name, which is going to be changed. Ali
Jul 22 2012
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/22/2012 09:27 AM, Mafi wrote:

 Unfortunately it has a bad name, which is going to be changed.


 Really? I thought we have to stay with this name now. In my
 opinion this name is quite bad, especially in the presence of
 UFCS. What is going to be changed to? destroy()?

Yep! :) It should be available in 2.060: // Scheduled for deprecation in December 2012. // Please use destroy instead of clear. https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L682 Ali
Jul 22 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/22/2012 09:35 AM, Namespace wrote:
 A other question:
 How can i check if t is valid, after i call "clear"?

After the destructor is run, the object itself is put into a strange state. I amnot really sure about the actual details but I think the virtual function table is cleared (or perhaps just the destructor's entry?) so that the destructor is not going to be run again by the GC later. Regarding the references to it, like 't' below, clear() cannot know about all of the references to the object. It could null the reference that is passed to it but apparently it doesn't do that maybe because null'ing one reference out of many wouldn't buy much. Of course it is always possible to set it to null explicitly after calling clear(): clear(t); t = null; Because now we know that we shouldn't be using the local reference. Ali
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Yes, C++ was my previous language.

And no, nobody say anything about Ranges. But i doesn't like 
stuff who is deprecated as language feature and is rebuild as 
std.algorithm construct. It is that simple. :)
Jul 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 22, 2012 10:16:25 Namespace wrote:
 Yes, C++ was my previous language.
 
 And no, nobody say anything about Ranges. But i doesn't like
 stuff who is deprecated as language feature and is rebuild as
 std.algorithm construct. It is that simple. :)

std.algorithm doesn't have anything like that. Are you talking about std.typecons.scoped? Regardless, it was decided that it was _bad_ language feature, which is why it was removed from the language (or will be anyway - I don't think that it's actually been deprecated yet like it's supposed to be). The same goes for delete. They're _not_ safe when dealing with GC memory, and their use should generally be strongly discouraged. - Jonathan M Davis
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Oh yes, i mean std.typecons, not std.algorithm, my bad.

If delete will be deprecated, how can i delete/call dtor of one 
of my objects manually?
Jul 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 22, 2012 10:46:51 Namespace wrote:
 Oh yes, i mean std.typecons, not std.algorithm, my bad.
 
 If delete will be deprecated, how can i delete/call dtor of one
 of my objects manually?

You're _really_ not supposed to be doing that. If you're dealing with GC allocated memory, then it's the GC that should be freeing it, not you. It's unsafe for you to be doing it, and it's just asking for bugs. If you want to be manually managing memory, you should be using malloc and free (which admittedly is a bit of pain with objects right now - custom allocators should fix that once we get them). But if you absolutely insist on trying to manage GC memory manually, then use the stuff in core.memory: http://dlang.org/phobos/core_memory.html But again, that's really only for when you _really_ need it. If you're doing much with it, then it's just about a guarantee that you're not using D as it's intended to be used. You're trying to program in C++ with D, which is just going to cause you trouble. - Jonathan M Davis
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
The reason for my experiements is just to find a good solution 
for Not Null types. :)
As long as they are not implement in std.typecons. Maybe you take 
my solution, if i have some. ;)
Jul 22 2012
prev sibling next sibling parent "Mafi" <mafi example.org> writes:
 On the other hand, calling the destructor is still acceptable 
 in D because it may be important for the programmer to run the 
 contents earlier than GC would. clear() does that:

     auto t = new Test(f3);
     // ...
     clear(t);    // <-- Run the destructor

 Unfortunately it has a bad name, which is going to be changed.

 Ali

Really? I thought we have to stay with this name now. In my opinion this name is quite bad, especially in the presence of UFCS. What is going to be changed to? destroy()? Mafi
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Nice to know. A name like "destroy" or "delete " would be better 
i think.
But isn't a solution for the not null problem.
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
A other question:
How can i check if t is valid, after i call "clear"?

[code]
import std.stdio;

class Test {
public:
	this() {
		writeln("CTor");
	}

	~this() {
		writeln("DTor");
	}
}

void main() {
	Test t = new Test();

	clear(t);

	writeln("end main");
}
[/code]

If i write assert(t !is null); it fails, and if i write 
writeln(t); or assert(t); i get an access violation.
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
A other question:
How can i check if t is valid, after i call "clear"?

[code]
import std.stdio;

class Test {
public:
	this() {
		writeln("CTor");
	}

	~this() {
		writeln("DTor");
	}
}

void main() {
	Test t = new Test();

	clear(t);

	writeln("end main");
}
[/code]

If i write assert(t !is null); it fails, and if i write
writeln(t); or assert(t); i get an access violation.
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 22 July 2012 at 17:41:33 UTC, Ali Çehreli wrote:
 On 07/22/2012 09:27 AM, Mafi wrote:

 Unfortunately it has a bad name, which is going to be


 Really? I thought we have to stay with this name now. In my
 opinion this name is quite bad, especially in the presence of
 UFCS. What is going to be changed to? destroy()?

Yep! :) It should be available in 2.060: // Scheduled for deprecation in December 2012. // Please use destroy instead of clear. https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L682 Ali

And how do I check if my object is still valid?
Jul 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 22, 2012 20:14:20 Namespace wrote:
 On Sunday, 22 July 2012 at 17:41:33 UTC, Ali =C3=87ehreli wrote:
 On 07/22/2012 09:27 AM, Mafi wrote:
 Unfortunately it has a bad name, which is going to be


changed. =20
 Really? I thought we have to stay with this name now. In my
 opinion this name is quite bad, especially in the presence of
 UFCS. What is going to be changed to? destroy()?

Yep! :) It should be available in 2.060: =20 // Scheduled for deprecation in December 2012. // Please use destroy instead of clear. =20 https://github.com/D-Programming-Language/druntime/blob/master/src/=


 di#L682
=20
 Ali

And how do I check if my object is still valid?

You don't. The object is completely invalid at that point. Its vtbl has= been=20 zeroed out. Asking how you check whether it's valid is like asking how = you can=20 tell whether an object in C++ which has been deleted is valid. It just = doesn't=20 work that way. If you're destroying it, you need to then _never_ use it= for=20 _anything_. You can set a reference which pointed to it to null, and th= en it's=20 null, and you can check for null, but an object which has had clear/des= troy=20 called on it is in an invalid state and should not be touched. It's=20 specifically set up such that it's highly likely to cause your program = to crash=20 if you try and use it at all. If you want to check an object for validi= ty, you=20 need to do something else. - Jonathan M Davis
Jul 22 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 22 July 2012 at 18:14:21 UTC, Namespace wrote:
 On Sunday, 22 July 2012 at 17:41:33 UTC, Ali Çehreli wrote:
 On 07/22/2012 09:27 AM, Mafi wrote:

 Unfortunately it has a bad name, which is going to be


 Really? I thought we have to stay with this name now. In my
 opinion this name is quite bad, especially in the presence of
 UFCS. What is going to be changed to? destroy()?

Yep! :) It should be available in 2.060: // Scheduled for deprecation in December 2012. // Please use destroy instead of clear. https://github.com/D-Programming-Language/druntime/blob/master/src/object.di#L682 Ali

And how do I check if my object is still valid?

AFAIK, there are no invalid objects in D*. structs don't have default constructors, because they all have a compile time "init" value which they are filled with when "emptied"/"moved"/"cleared". Ergo, even after being "destroyed", they are still valid. Arrays are set to a null slice. Pointers and class references are set to null. To check a class reference, then "if(instance is null)" should do what you want BTW. *Provided you don't go out of your way to give them an invalid state, of course.
Jul 22 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Works fine. :)
Now my little test case work as expected:

[code]
import std.stdio;

class Test {
public:
	this() {
		writeln("CTor");
	}

	~this() {
		writeln("DTor");
	}

	void echo() const {
		writeln("Here is Test");
	}
}

struct scoped {
private:
	Test* _t;

public:
	this(ref Test t) {
		this._t = &t;

		writeln(" >> scoped CTor");
	}

	 disable
	this(this);

	ref scoped opAssign(ref Test t) {
		this.Release();

		this._t = &t;

		writeln(" >> scoped Assign");

		return this;
	}

	~this() {
		writeln(" >> scoped DTor");
		this.Release();
	}

	void Release() {
		if (this._t !is null && *this._t !is null) {
			writeln("Clear scoped content");

			clear(*this._t);
			*this._t = null;
			this._t = null;
		}
	}

	 property
	Test* Value() {
		return this._t;
	}

	alias Value this;
}

class Bar {
private:
	scoped _sc;

public:
	this(ref Test f) {
		writeln("begin this");
		this._sc = f;
		writeln("end this");
	}

	~this() {
		writeln("DTOR BAR");
	}
}

void main() {
	Test t = new Test();

	clear(t);

	Test t2 = new Test();

	{
		scoped s = t2;
		s.echo();

		writeln("end scope");
	}

	assert(t2 is null);

	Test t3 = new Test();
	Bar b = new Bar(t3);

	assert(t3 !is null);

	writeln("end main");
}
[/code]
Jul 22 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, July 22, 2012 20:45:05 monarch_dodra wrote:
 AFAIK, there are no invalid objects in D*. structs don't have
 default constructors, because they all have a compile time "init"
 value which they are filled with when
 "emptied"/"moved"/"cleared". Ergo, even after being "destroyed",
 they are still valid.
 
 Arrays are set to a null slice.
 
 Pointers and class references are set to null.
 
 To check a class reference, then "if(instance is null)" should do
 what you want BTW.
 
 *Provided you don't go out of your way to give them an invalid
 state, of course.

Nothing in D is in an invalid state as long as you place nice, but it's perfectly possible to put an object in an invalid state if you try. int i = void; will make i garbage. It avoids the initialization and is therefore an optimization technique, but by using it, you do get a variable which is an an invalid state. Calling clear on a class object puts it in an invalid state. It calls its finalizer and zeroes out its vtbl. It's _not_ null, and using it will likely result in a segfault (some non-virtual stuff may still work, but anything virtual will cause a segfault because of the zeroed out vtbl). Calling clear on pretty much everything else is safe, since it generally just sets everything else to null without doing any kind of destruction or cleanup. The on exception would be structs, and with them, they get put in their init state if they're on the stack, and if they're on the heap, the pointer to them gets set to null. The struct itself is untouched. But for classes, it's _not_ safe. The object _does_ get put in an invalid state. Stuff like initializing to void or calling clear on an object are really only there so that you have more fine-grained control when you really need it, and they come with definite responsibility when you do use them, because you're telling the language that you don't need its full protection and that you know what you're doing. They really shouldn't be used in your average D program. - Jonathan M Davis
Jul 22 2012