• Cheng Wei (9/9) Sep 28 2011 extern(C) {
• bearophile (11/23) Sep 28 2011 It's not specific of associative arrays:
• travert phare.normalesup.org (Christophe) (1/1) Sep 29 2011 what is the error message ?
• Trass3r (2/11) Sep 29 2011 Just use void* for opaque pointers in D.
• Timon Gehr (3/19) Sep 29 2011 Or an empty struct.
• Cheng Wei (8/8) Sep 29 2011 Thanks a lot. This solves the problem.
• travert phare.normalesup.org (Christophe) (11/21) Sep 30 2011 I guess D is not designed to use abstract classes because they are not
• Cheng Wei (5/5) Sep 29 2011 The problem is that the void* cannot convert back to AB* when we want to

Cheng Wei <rivercheng gmail.com> writes:

extern(C) {
    struct ab;
}

ab*[int] map;

void main() {
    map.clear();
}


Cannot be compiled. Why?

Thanks.

bearophile <bearophileHUGS lycos.com> writes:

Cheng Wei:

 extern(C) {
     struct ab;
 }
 
 ab*[int] map;
 
 void main() {
     map.clear();
 }
 
 
 Cannot be compiled. Why?

It's not specific of associative arrays:

extern(C) {
    struct AB;
}
AB*[] arr;
void main() {
    arr.length += 1;
}

Bye,
bearophile

travert phare.normalesup.org (Christophe) writes:

what is the error message ?

Trass3r <un known.com> writes:

Am 29.09.2011, 06:51 Uhr, schrieb Cheng Wei <rivercheng gmail.com>:

 extern(C) {
     struct ab;
 }

 ab*[int] map;

 void main() {
     map.clear();
 }


 Cannot be compiled. Why?

 Thanks.

Just use void* for opaque pointers in D.

Timon Gehr <timon.gehr gmx.ch> writes:

On 09/29/2011 01:28 PM, Trass3r wrote:
 Am 29.09.2011, 06:51 Uhr, schrieb Cheng Wei <rivercheng gmail.com>:

 extern(C) {
 struct ab;
 }

 ab*[int] map;

 void main() {
 map.clear();
 }


 Cannot be compiled. Why?

 Thanks.

 Just use void* for opaque pointers in D.

Or an empty struct.

struct ab{}

Cheng Wei <rivercheng gmail.com> writes:

Thanks a lot. This solves the problem.

However, it breaks the abstractness. Now in D side, we can call
auto v = ab(). This does not make sense, because then &v cannot be used
in the C library.

I don't understand why when we manipulate AB*, D compiler needs to know
the size of struct ab. Moreover, when we use AB*[int], the D compiler
complains about there's no opHash defined for AB. I don't think they are
necessary at all.

travert phare.normalesup.org (Christophe) writes:

Cheng Wei , dans le message (digitalmars.D.learn:29865), a écrit :
 Thanks a lot. This solves the problem.
 
 However, it breaks the abstractness. Now in D side, we can call
 auto v = ab(). This does not make sense, because then &v cannot be used
 in the C library.
 
 I don't understand why when we manipulate AB*, D compiler needs to know
 the size of struct ab. Moreover, when we use AB*[int], the D compiler
 complains about there's no opHash defined for AB. I don't think they are
 necessary at all.

I guess D is not designed to use abstract classes because they are not 
needed in the language: the compiler reads all the symbols in the file 
before doing the real compilation, but there may be no real issue for 
the compiler, as long as you do not use the ab* for anything else than 
passing it to C code.
 
You could file an enhancement request to support abstract pointer for 
the sake of interoperability with C.

-- 
Christophe

Cheng Wei <rivercheng gmail.com> writes:

The problem is that the void* cannot convert back to AB* when we want to
use it in c library.

Just don't understand why the cast(AB*)p (p is void *) needs to know the
size of AB. Is there any unsafe cast which can blindly cast the
pointers?