digitalmars.D.ldc - char[]/ubyte[] compile error
- Damien Gibson (23/23) Jul 12 2017 Hi all. As I'm sure you all know documentation is hit and miss
- Johan Engelen (5/14) Jul 12 2017 This is probably because `char[]` cannot be mangled to a C++
- Jacob Carlborg (12/41) Jul 13 2017 Perhaps you can declare a struct that contains a pointer and the length
- John Colvin (2/13) Jul 13 2017 I do this for interacting with Cython and it works well for me.
- Johan Engelen (4/13) Jul 13 2017 I think such a C-like construct that is equivalent with slices
- Johan Engelen (7/21) Jul 13 2017 What I mean is, a construct like your "Array" on the D-side, that
- Jacob Carlborg (8/14) Jul 13 2017 Yeah, that would be nice. This feature request is related [1]. If that's...
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 2017
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 2017
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 2017
On Thursday, 13 July 2017 at 09:51:00 UTC, Jacob Carlborg wrote:On 2017-07-12 23:14, Damien Gibson wrote:I do this for interacting with Cython and it works well for me.[...]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
Jul 13 2017
On Thursday, 13 July 2017 at 13:02:23 UTC, John Colvin wrote: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?Array { size_t length; char* ptr; } [1] http://dlang.org/spec/abi.html#arraysI do this for interacting with Cython and it works well for me.
Jul 13 2017
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: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.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?Array { size_t length; char* ptr; } [1] http://dlang.org/spec/abi.html#arraysI do this for interacting with Cython and it works well for me.
Jul 13 2017
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 2017