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.

> 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"...

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

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 !?

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

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? ;)

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.

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.

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

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?