Re: Using C++ with D / returning a templated type from C++
On 2018-07-04 18:04:25 +, Steven Schveighoffer said:
On 7/4/18 1:32 PM, Robert M. Münch wrote:
I have the following C++ code and want to give the D/C++ integration a new try:
template class Array {...}
class myClass {...}
typedef Array myClassArray;
myClassArray classA::getArray() noexcept {...}
How does the D binding for this look like? I tried something like this:
extern (C++) {
You need class myClass somewhere, no?
Yes, it's the input to an other function:
extern (C++, myUtils) {
final int readFromFile(Destination dst, Array!myClass input,
const char* filename);
}
class Array(T){};
class Array(myClass) {};
Not sure what this is? ^^
Beside the wrong syntax, I was not sure if I need to instantiate the
specific template.
Note, I would say you need: alias myClassArray = Array!myClass
Yes, might help.
class classA {
final Array(myClass) getArray(); <== COMPILER ERRORS
Array!myClass, not Array(myClass)
Ah... this is always catching me... because the declaration syntax is
different. Thanks, helped a bit.
This is the C++ signature: public: static class Array
__cdecl builtinCodecs(void)
And this is now the D version: public: class Array
__cdecl builtinCodecs(void) __ptr64
So, the only difference left is the C++ static and the additional
__ptr64 (whatever this is) on the D side. Any further ideas?
BTW: IMO the docs should show very complex examples taking classes,
typedefs, templates etc. into account and not only show for simple
basic types. That's OK to get the concept but this C++ interface thing
needs a ton of examples how to do things to be really useable. So, how
or where could such a collection be done?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Cleanup class after method?
On Wednesday, 4 July 2018 at 16:02:25 UTC, Jonathan M Davis wrote: -dip1000 fully implements scope so that it verifies that no reference escapes, but it's not ready yet, let alone the default behavior. - Jonathan M Davis I read the proposal about -dip1000 ( not all, some ) and there is also a scoped! template in std.typecons, so...is it better to use the scope keyword, or scoped! template
how to import file from another path in dub ?
I have a dub project, and I put the importPath to the path of the file I want to import and the source file to the source folder, and it appears that I have succeeded at importing the module, but there's one problem, it appears like I need to define some sort of thing, because the error says " Error 42: Symbol Undefined __D9animation12__ModuleInfoZ" ( I am using coedit ), do I need to compile the file into .lib ?
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 14:39:34 UTC, ag0aep6g wrote: Looks like forum.dlang.org has a problem when they appear side by-side. Works (in the preview): 👩👩👦👦 🏳️🌈 Doesn't work: 👩👩👦👦🏳️🌈 For me, it looks as the used font has ligatures for these faces. Mozilla under Linux, I guess it's 'EmojiOne Mozilla' font.
Re: Issues with undefined symbols when using Vibe on Windows
On Wednesday, 4 July 2018 at 20:36:55 UTC, Chris M. wrote: On Tuesday, 3 July 2018 at 18:35:43 UTC, kinke wrote: On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote: [...] AFAICT, the issue is that MinGW is used, as opposed to MinGW-w64 (a confusingly separate project unfortunately AFAIK). There's no SetWindowLongPtr for Win32, it's #defined as SetWindowLong. The 64-bit user32.def of MinGW-w64 contains it [1], while it's missing in the MinGW .def file [3] and the 32-bit MinGW-w64 one [2]. [1] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib64/user32.def [2] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib32/user32.def [3] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/w32api/lib/user32.def What are next steps then? Probably something along the lines of 1) cloning the repo 2) preparing the environment so that build_mingw.bat works locally 3) downloading MinGW-w64 archive in build_mingw.bat 4) adapting paths in buildsdk.d 5) fix until working 6) check if other scripts need to be adapted too (packaging etc.) 7) open GitHub PR
Re: Issues with undefined symbols when using Vibe on Windows
On Tuesday, 3 July 2018 at 18:35:43 UTC, kinke wrote: On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote: [...] AFAICT, the issue is that MinGW is used, as opposed to MinGW-w64 (a confusingly separate project unfortunately AFAIK). There's no SetWindowLongPtr for Win32, it's #defined as SetWindowLong. The 64-bit user32.def of MinGW-w64 contains it [1], while it's missing in the MinGW .def file [3] and the 32-bit MinGW-w64 one [2]. [1] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib64/user32.def [2] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib32/user32.def [3] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/w32api/lib/user32.def What are next steps then?
Re: Using C++ with D / returning a templated type from C++
On 7/4/18 1:32 PM, Robert M. Münch wrote:
I have the following C++ code and want to give the D/C++ integration a
new try:
template class Array {...}
class myClass {...}
typedef Array myClassArray;
myClassArray classA::getArray() noexcept {...}
How does the D binding for this look like? I tried something like this:
extern (C++) {
You need class myClass somewhere, no?
class Array(T){};
class Array(myClass) {};
Not sure what this is? ^^
Note, I would say you need:
alias myClassArray = Array!myClass
class classA {
final Array(myClass) getArray(); <== COMPILER ERRORS
Array!myClass, not Array(myClass)
-Steve
Re: Using C++ with D / returning a templated type from C++
On Wednesday, 4 July 2018 at 17:32:49 UTC, Robert M. Münch wrote:
I have the following C++ code and want to give the D/C++
integration a new try:
template class Array {...}
class myClass {...}
typedef Array myClassArray;
myClassArray classA::getArray() noexcept {...}
How does the D binding for this look like? I tried something
like this:
extern (C++) {
class Array(T){};
class Array(myClass) {};
class classA {
final Array(myClass) getArray(); <== COMPILER ERRORS
};
}
But this doesn't work at all and give a bunch of comiler errors:
Error: function declaration without return type. (Note that
constructors are always named this)
Error: no identifier for declarator extern (C++) Array(myClass)
Error: semicolon expected following function declaration
Error: function declaration without return type. (Note that
constructors are always named this)
Error: no identifier for declarator extern (C++) getArray()
Any ideas?
final Array!myClass getArray(); <== !
Using C++ with D / returning a templated type from C++
I have the following C++ code and want to give the D/C++ integration a new try:
template class Array {...}
class myClass {...}
typedef Array myClassArray;
myClassArray classA::getArray() noexcept {...}
How does the D binding for this look like? I tried something like this:
extern (C++) {
class Array(T){};
class Array(myClass) {};
class classA {
final Array(myClass) getArray(); <== COMPILER ERRORS
};
}
But this doesn't work at all and give a bunch of comiler errors:
Error: function declaration without return type. (Note that
constructors are always named this)
Error: no identifier for declarator extern (C++) Array(myClass)
Error: semicolon expected following function declaration
Error: function declaration without return type. (Note that
constructors are always named this)
Error: no identifier for declarator extern (C++) getArray()
Any ideas?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Inference of auto storage classes for interface function return type
On 07/04/2018 05:59 PM, Timoses wrote: There's an empty 19.10.10 point without content[3] : D. Maybe a placeholder? [...] [3]: https://dlang.org/spec/function.html#inout-functions Just a bug. https://github.com/dlang/dlang.org/pull/2407
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On 07/04/2018 05:12 PM, aliak wrote: Is updating unicode stuff to the latest a matter of some config file somewhere with the code point configurations that result in specific graphemes? I don't know. [...] Also, any reason (technical or otherwise) that we have to slice a grapheme to get it printed? Or just no one implemented something like toString or the like? I don't know. [...] I can't really imagine anyone figuring out that they have to slice a grapheme to get it to print 🤔 You can figure it out by reading the documentation for `Grapheme`. However, the documentation doesn't make it clear that `byGrapheme` is a range of `Grapheme`s. That's an easy fix, though: https://github.com/dlang/phobos/pull/6627
Re: Cleanup class after method?
On Wednesday, July 04, 2018 15:47:25 JN via Digitalmars-d-learn wrote:
> Imagine I have a very short-lived class:
>
> void print(File f)
> {
> PrinterManager pm = new PrinterManager();
> pm.print(f);
> }
>
> My understanding is that PrinterManager will be GC allocated, and
> when it goes out of scope, the GC will possibly clean it up at
> some point in the future. But I know that this class won't be
> used anywhere, I want to clean it up right now so that GC doesn't
> waste time later. In C++ it'd be handled by RAII, pm would be a
> unique_ptr. How to do it in D?
The typical thing to do in that case is to use a struct, not a class, since
structs have RAII, and they don't need to be allocated on the heap. However,
if you're stuck with a class, you can use scope. e.g.
scope pm = new PrintManager;
In that case, the class will actually be allocated on the stack instead.
However, I would point out that until -dip1000 becomes the normal behavior,
using scope like this is unsafe, because you have serious problems if any
reference to the class object escapes, since it's stack-allocated instead of
heap-allocated, and if any reference to it escapes, then it's referring to
an invalid object. If you're careful, it's fine, but it is a risk, and
regardless, using a struct is preferable if it's possible.
-dip1000 fully implements scope so that it verifies that no reference
escapes, but it's not ready yet, let alone the default behavior.
- Jonathan M Davis
Re: Inference of auto storage classes for interface function return type
On Wednesday, 4 July 2018 at 15:12:15 UTC, Jonathan M Davis wrote: You can make opIndex inout instead of const. That way, inout applies to the invisible this reference, just like it would with const. Awww, thanks! I was kinda hovering around this[1] section and didn't quite see the MemberFunctionAttribute list[2]. Is there no further description of the behaviour with the inout attribute other than for parameters[1] in the spec? There's an empty 19.10.10 point without content[3] : D. Maybe a placeholder? [1]: https://dlang.org/spec/function.html#inout-functions [2]: https://dlang.org/spec/function.html#MemberFunctionAttribute [3]: https://dlang.org/spec/function.html#inout-functions
Re: Cleanup class after method?
On Wednesday, 4 July 2018 at 15:47:25 UTC, JN wrote:
Imagine I have a very short-lived class:
void print(File f)
{
PrinterManager pm = new PrinterManager();
pm.print(f);
}
My understanding is that PrinterManager will be GC allocated,
and when it goes out of scope, the GC will possibly clean it up
at some point in the future. But I know that this class won't
be used anywhere, I want to clean it up right now so that GC
doesn't waste time later. In C++ it'd be handled by RAII, pm
would be a unique_ptr. How to do it in D?
https://dlang.org/phobos/std_typecons.html#scoped
Cleanup class after method?
Imagine I have a very short-lived class:
void print(File f)
{
PrinterManager pm = new PrinterManager();
pm.print(f);
}
My understanding is that PrinterManager will be GC allocated, and
when it goes out of scope, the GC will possibly clean it up at
some point in the future. But I know that this class won't be
used anywhere, I want to clean it up right now so that GC doesn't
waste time later. In C++ it'd be handled by RAII, pm would be a
unique_ptr. How to do it in D?
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 14:37:32 UTC, Adam D. Ruppe wrote: On Tuesday, 3 July 2018 at 13:32:52 UTC, aliak wrote: [...] What system are you on? Successfully printing this stuff depends on a lot of display details too, like writeln goes to a terminal/console and they are rarely configured to support such characters by default. You might actually be better off printing it to a file instead of to a display, then opening that file in your browser or something, just to confirm the code printed is correctly displayed by the other program. [...] prolly just printing `c` itself would work and if not try `c[]` but then again it might see it as multiple graphemes, idk if it is even implemented. Just 'c' didn't but 'c[]' seems like the thing to do! Thankies! Terminal on osx, and yeah you're right. Seems like just trying to paste rainbow flag right in to terminal results in the 3 separate code points
Re: what's the correct way to handle unicode? - trying to print out graphemes here.
On Tuesday, 3 July 2018 at 14:43:37 UTC, Steven Schveighoffer
wrote:
On 7/3/18 10:37 AM, ag0aep6g wrote:
On Tuesday, 3 July 2018 at 13:32:52 UTC, aliak wrote:
foreach (c; "👩👩👦👦🏳️🌈") {
writeln(c);
}
So basically the above just doesn't work. Prints gibberish.
Because you're printing one UTF-8 code unit (`char`) per line.
So I figured, std.uni.byGrapheme would help, since that's
what they are, but I can't get it to print them back out? Is
there a way?
foreach (c; "👩👩👦👦🏳️🌈".byGrapheme) {
writeln(c.);
}
You're looking for `c[]`. But that won't work, because std.uni
apparently doesn't recognize those as grapheme clusters. The
emojis may be too new. std.uni is based on Unicode version
6.2, which is a couple years old.
Oops! I didn't realize this, ignore my message about reporting
a bug.
I still think it's very odd for printing a grapheme to print
the data structure.
-Steve
Aha, ok I see. Many gracias!
Though, seems by a couple years old you mean 6 years! :) Is
updating unicode stuff to the latest a matter of some config file
somewhere with the code point configurations that result in
specific graphemes? Feels kinda ... quite bad that we're 6 years
behind the current standard.
Also, any reason (technical or otherwise) that we have to slice a
grapheme to get it printed? Or just no one implemented something
like toString or the like? It's quite non intuitive as it is
right now IMO. I can't really imagine anyone figuring out that
they have to slice a grapheme to get it to print 🤔
Cheers,
- Ali
Re: Inference of auto storage classes for interface function return type
On Wednesday, July 04, 2018 14:07:35 Timoses via Digitalmars-d-learn wrote:
> How can I return inferred storage class from interface functions?
> I can't use auto as return value in interface. Neither can I use
> "inout" as I don't pass a parameter.
>
> // Ref Type
> interface IRef
> {
> Ref opIndex(size_t idx) const;
> }
> class CRef : IRef
> {
> Ref[] a;
> this() immutable
> { this.a = [new Ref()]; }
> Ref opIndex(size_t idx) const
> { return a[idx]; } // Error: cannot implicitly convert
> expression this.a[idx] of type const(Ref) to app.Ref
> }
> class Ref{}
>
> void main()
> {
> auto a = new immutable(CRef)();
> auto s = a[3];
> }
>
> For value types it works, I presume since they are passed by
> value, so the instance returned is an actual copy of the stored
> value.
>
> // Value Type
> interface IValue
> {
> Value opIndex(size_t idx) const;
> }
> class CValue : IValue
> {
> this() immutable { i = [Value()]; }
> Value[] i;
> Value opIndex(size_t idx) const
> { return i[idx]; }
> }
> struct Value{}
>
> However, for ref types this doesn't work.
>
> Do I have to define two `opIndex` in the interface? One mutable,
> one for immutable type instances?
You can make opIndex inout instead of const. That way, inout applies to the
invisible this reference, just like it would with const.
- Jonathan M Davis
Re: Inference of auto storage classes for interface function return type
On Wednesday, 4 July 2018 at 14:07:35 UTC, Timoses wrote:
How can I return inferred storage class from interface
functions?
I can't use auto as return value in interface. Neither can I
use "inout" as I don't pass a parameter.
// Ref Type
interface IRef
{
Ref opIndex(size_t idx) const;
}
class CRef : IRef
{
Ref[] a;
this() immutable
{ this.a = [new Ref()]; }
Ref opIndex(size_t idx) const
{ return a[idx]; } // Error: cannot implicitly convert
expression this.a[idx] of type const(Ref) to app.Ref
}
class Ref{}
void main()
{
auto a = new immutable(CRef)();
auto s = a[3];
}
For value types it works, I presume since they are passed by
value, so the instance returned is an actual copy of the stored
value.
// Value Type
interface IValue
{
Value opIndex(size_t idx) const;
}
class CValue : IValue
{
this() immutable { i = [Value()]; }
Value[] i;
Value opIndex(size_t idx) const
{ return i[idx]; }
}
struct Value{}
However, for ref types this doesn't work.
Do I have to define two `opIndex` in the interface? One
mutable, one for immutable type instances?
IIRC to apply inout to the this pointer:
Ref opIndex(size_t idx) inout;
or
inout(Ref) opIndex(size_t idx) inout;
not sure off the top of my head,
Inference of auto storage classes for interface function return type
How can I return inferred storage class from interface functions?
I can't use auto as return value in interface. Neither can I use
"inout" as I don't pass a parameter.
// Ref Type
interface IRef
{
Ref opIndex(size_t idx) const;
}
class CRef : IRef
{
Ref[] a;
this() immutable
{ this.a = [new Ref()]; }
Ref opIndex(size_t idx) const
{ return a[idx]; } // Error: cannot implicitly convert
expression this.a[idx] of type const(Ref) to app.Ref
}
class Ref{}
void main()
{
auto a = new immutable(CRef)();
auto s = a[3];
}
For value types it works, I presume since they are passed by
value, so the instance returned is an actual copy of the stored
value.
// Value Type
interface IValue
{
Value opIndex(size_t idx) const;
}
class CValue : IValue
{
this() immutable { i = [Value()]; }
Value[] i;
Value opIndex(size_t idx) const
{ return i[idx]; }
}
struct Value{}
However, for ref types this doesn't work.
Do I have to define two `opIndex` in the interface? One mutable,
one for immutable type instances?
Re: How to call a C function from D that takes a FILE * as an argument?
On Wednesday, 4 July 2018 at 02:54:47 UTC, Joe wrote:
On Wednesday, 4 July 2018 at 02:16:00 UTC, Seb wrote:
Hmm, calling e.g. fprintf with stdout should just work:
---
void main()
{
import core.stdc.stdio;
fprintf(stdout, "Hello %s", "world".ptr);
}
---
Could you maybe provide your whole code?
This short test program shows the error:
---
import std.stdio;
void main()
{
extern (C) void list(FILE *fd);
list(stdout);
}
---
Now I fixed this by changing the import to core.stdc.stdio. I
guess the problem is if you import std.stdio (which brings in
the other one), there are two slightly incompatible stdout's
and the D takes precedence.
`stdout.getFP` (stdout is of the D std.stdio.File struct type and
with getFP you get the underlying FILE*)
