I have just discovered that the postblit constructor is not able to be invoked like a "normal" constructor, or, as one would manually do so in C++ with a copy constructor. Accordingly I have a couple questions:

1) What are the various ways to invoke the postblit constructor? I have not tested, but assume that:

auto s1 = MyStruct();
auto s2 = s1;

Is one such way to invoke it and that:

auto s1 = MyStruct;
foo(s1);

Where foo is defined as: void foo(MyStruct s) {}

is another way. Are there others?


2) I ran into this issue while attempting to leverage the postblit for code-reuse. In particular, I have a setup that is similar to:

struct A {
  this(B b) { /* Stuff */ }
}

struct B {

}

void foo(T)(T param) {
  auto a = A(param);
  /* Stuff */
}

unittest {
  foo(A()); //Fails
  foo(B()); //Succeeds
}

The notion being that A and B are 2 ways to represent the same thing, why not convert everything to the A format and proceed from there; I figured the compiler would optimize out the pointless copy when T == A. Alas, as shown in my unittest, foo fails to accept arguments of type A.

I suppose my question would be: What is the idiomatic way of accomplishing this form of code reuse in D?

I'd prefer to not have to write two versions of foo, even if one is as simple as converting the argument and passing it to the other. I'd also prefer to avoid having some shenangians along the lines of:

void foo(T)(T param) {
  static if (is(T == A)) {
    auto a = param;
  } else {
    auto a = A(param);
  }
}

As this would be difficult to express in a template constraint in the function signature.

Did some thinking: Realized that the appropriate mechanism to express that A and B are two ways of representing the same thing is to do so via opCast. I had not considered this option carefully initially as I am translating someone else's C++ code to D and hoped that they had used the appropriate representations on the C++ side.

I added the appropriate code to permit casting and I was then able to get the desired code-reuse and template constraints.

Accordingly, I no longer need an answer to my second question unless someone knows of a more idiomatic way to get the same results.

Mark Isaacson:

> Accordingly, I no longer need an answer to my second question unless someone knows of a more idiomatic way to get the same results.

Is the "alias this" useful in this case?

Bye,
bearophile

@bearophile - Unless I'm missing something, alas, no. Neither A nor B is a subtype of the other. In particular, in the real code one is a CartesianVector and the other a PolarVector. For what it's worth, 'foo' is actually opBinary addition.

Thanks for the thought though.

On 05/03/14 01:05, Mark Isaacson via Digitalmars-d-learn wrote:
> 2) I ran into this issue while attempting to leverage the postblit for code-reuse. In particular, I have a setup that is similar to:
> 
> struct A {
>   this(B b) { /* Stuff */ }
> }
> 
> struct B {
> }
> 
> void foo(T)(T param) {
>   auto a = A(param);
>   /* Stuff */
> }
> 
> unittest {
>   foo(A()); //Fails
>   foo(B()); //Succeeds
> }
> 
> The notion being that A and B are 2 ways to represent the same thing, why not convert everything to the A format and proceed from there; I figured the compiler would optimize out the pointless copy when T == A. Alas, as shown in my unittest, foo fails to accept arguments of type A.

What actually fails is the initialization of 'a'.
Add another

   this(A a) { /* Stuff */ }

constructor to the 'A' struct, and it will work.


And, yes, the missing cpctors are a language problem.

artur

> What actually fails is the initialization of 'a'.
> Add another
>
>    this(A a) { /* Stuff */ }
>
> constructor to the 'A' struct, and it will work.
>
>
> And, yes, the missing cpctors are a language problem.
>
> artur


Thanks. Yeah, I figured I could do that, I was just hoping that I could leverage the postblit.

Ultimately my answer to my second question became: "Calling the postblit directly is far too low level, just use std.conv.to instead". to!A(x) did exactly the right thing (without any modification of the original classes I think).