www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - char[]/ubyte[] compile error

reply Damien Gibson <spiceywolf.archaicsoft outlook.com> writes:
Hi all. As I'm sure you all know documentation is hit and miss 
for if it exists or is good with DLang (And compilers) and this 
issue i'm not totally sure if either or at this point.

C++ cooperation with dlls made in dmd was pretty nonexistant from 
all my previous attempts and LDC works fine.

However in the case of what i'm currently making it requires the 
use of a byte array (0-255) and i've tried either char[] or 
ubyte[] and on either of them the compiler always returned this 
error:

'Error: Internal Compiler Error: unsupported type char[]'

a direct method of reproducing this is:

1) Make a shared library(dll).
2) Generate in some code file - Module Name,
                                 export:extern(C++):,
                                 use above type as return or param;
3) Compile.

I haven't had any luck finding documentation as to why this may 
be or what it extends to if it isnt just arrays of those types 
nor do I have any luck finding alternative methods to accomplish 
the same tasks those 2 known types are required for.

What I would like help for basicly is just to find out if maybe 
there is limited usage in there and what alternative approach 
someone else may have to the arrays. Thanks.
Jul 12
next sibling parent Johan Engelen <j j.nl> writes:
On Wednesday, 12 July 2017 at 21:14:09 UTC, Damien Gibson wrote:
 
 'Error: Internal Compiler Error: unsupported type char[]'

 a direct method of reproducing this is:

 1) Make a shared library(dll).
 2) Generate in some code file - Module Name,
                                 export:extern(C++):,
                                 use above type as return or 
 param;
 3) Compile.
This is probably because `char[]` cannot be mangled to a C++ type. So you cannot have an extern(C++) function with a `T[]` (any slice) as return type or parameter type. - Johan
Jul 12
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-07-12 23:14, Damien Gibson wrote:
 Hi all. As I'm sure you all know documentation is hit and miss for if it 
 exists or is good with DLang (And compilers) and this issue i'm not 
 totally sure if either or at this point.
 
 C++ cooperation with dlls made in dmd was pretty nonexistant from all my 
 previous attempts and LDC works fine.
 
 However in the case of what i'm currently making it requires the use of 
 a byte array (0-255) and i've tried either char[] or ubyte[] and on 
 either of them the compiler always returned this error:
 
 'Error: Internal Compiler Error: unsupported type char[]'
 
 a direct method of reproducing this is:
 
 1) Make a shared library(dll).
 2) Generate in some code file - Module Name,
                                  export:extern(C++):,
                                  use above type as return or param;
 3) Compile.
 
 I haven't had any luck finding documentation as to why this may be or 
 what it extends to if it isnt just arrays of those types nor do I have 
 any luck finding alternative methods to accomplish the same tasks those 
 2 known types are required for.
 
 What I would like help for basicly is just to find out if maybe there is 
 limited usage in there and what alternative approach someone else may 
 have to the arrays. Thanks.
Perhaps you can declare a struct that contains a pointer and the length of the array. This is the internal representation of an array in D [1]. The struct would look like: Array { size_t length; char* ptr; } [1] http://dlang.org/spec/abi.html#arrays -- /Jacob Carlborg
Jul 13
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 13 July 2017 at 09:51:00 UTC, Jacob Carlborg wrote:
 On 2017-07-12 23:14, Damien Gibson wrote:
 [...]
Perhaps you can declare a struct that contains a pointer and the length of the array. This is the internal representation of an array in D [1]. The struct would look like: Array { size_t length; char* ptr; } [1] http://dlang.org/spec/abi.html#arrays
I do this for interacting with Cython and it works well for me.
Jul 13
parent reply Johan Engelen <j j.nl> writes:
On Thursday, 13 July 2017 at 13:02:23 UTC, John Colvin wrote:
 Array
 {
     size_t length;
     char* ptr;
 }

 [1] http://dlang.org/spec/abi.html#arrays
I do this for interacting with Cython and it works well for me.
I think such a C-like construct that is equivalent with slices really should be part of Phobos/druntime somehow. What do you think John?
Jul 13
parent reply Johan Engelen <j j.nl> writes:
On Thursday, 13 July 2017 at 22:03:37 UTC, Johan Engelen wrote:
 On Thursday, 13 July 2017 at 13:02:23 UTC, John Colvin wrote:
 Array
 {
     size_t length;
     char* ptr;
 }

 [1] http://dlang.org/spec/abi.html#arrays
I do this for interacting with Cython and it works well for me.
I think such a C-like construct that is equivalent with slices really should be part of Phobos/druntime somehow. What do you think John?
What I mean is, a construct like your "Array" on the D-side, that is automatically convertable from/to a slice on the D-side. Such that you can define cross-C++-D functions that accept slices on the D-side, and accepts Array structs on the C++ side, and all is mangled properly because the D-side is also using the Array struct yet still accepting slices.
Jul 13
parent Jacob Carlborg <doob me.com> writes:
On 2017-07-14 00:06, Johan Engelen wrote:

 What I mean is, a construct like your "Array" on the D-side, that is 
 automatically convertable from/to a slice on the D-side. Such that you 
 can define cross-C++-D functions that accept slices on the D-side, and 
 accepts Array structs on the C++ side, and all is mangled properly 
 because the D-side is also using the Array struct yet still accepting 
 slices.
Yeah, that would be nice. This feature request is related [1]. If that's implemented and we're satisfied without any implicit conversions we would not need any special language support. The feature request is useful for other scenarios as well. [1] https://issues.dlang.org/show_bug.cgi?id=17636 -- /Jacob Carlborg
Jul 13