On Thursday, 18 April 2024 at 11:05:07 UTC, yabobay wrote:
On Wednesday, 17 April 2024 at 15:24:07 UTC, Ferhat Kurtulmuş
wrote:
On Wednesday, 17 April 2024 at 11:03:22 UTC, yabobay wrote:
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of
On Wednesday, 17 April 2024 at 15:24:07 UTC, Ferhat Kurtulmuş
wrote:
On Wednesday, 17 April 2024 at 11:03:22 UTC, yabobay wrote:
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of the dub.json:
[...]
İt seems your issue is related to t
On Wednesday, 17 April 2024 at 11:03:22 UTC, yabobay wrote:
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of the dub.json:
[...]
İt seems your issue is related to the raylib itself, neither the
binding you use nor the d programming l
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of the dub.json:
```json
"dependencies" : {"dray": "~>4.2.0-r3"},
"dflags-ldc": ["--static"],
"lflags": ["-static"]
```
In my regular setup with Debian, i can compile and run my
On Friday, 5 February 2021 at 21:40:29 UTC, wolfiesnotfine wrote:
In any case, I'm unsure how I would runtime init from C++. Is
there a specific function I should call?
https://dlang.org/phobos/core_runtime.html#.rt_init
Could this be done at compile time in a consteval or constexpr
function?
On Friday, 5 February 2021 at 21:11:20 UTC, Adam D. Ruppe wrote:
tbh I'd say just don't use betterC, you can still runtime init
from C++ and be judicious in what features you use to keep it
more minimal.
Hmm. I'm mostly concerned about issues or slowdowns in mixing the
manual memory managemen
On Friday, 5 February 2021 at 21:04:00 UTC, wolfiesnotfine wrote:
however sse() from core.cpuid is incorrectly reporting as
false. The function properly returns true if it's not called
from C++ but instead a D main function.
That makes me think it is a static constructor, and indeed there
is
Hello, I'm currently working on a primarily C++ project but I
wanted to leverage some of D's language features and library for
a few parts. I'm using the betterC subset and here's the code
snippet in D: https://run.dlang.io/is/XOXF06
It's quite a simple test, and the code just gets called from
Here is a debugger view of the passed IAllocator&
https://i.imgur.com/p04Tj4a.png
Hmm, something seems to be very wrong, here what i got so far
``` D
struct IAllocator
{ }
struct DefaultAllocator
{
// BASE --
IAllocator base = IAllocator();
alias base this;
//
ubyte
On Monday, 28 December 2020 at 16:42:19 UTC, Paul Backus wrote:
On Monday, 28 December 2020 at 15:42:26 UTC, RSY wrote:
``IAllocator`` is an abstract struct, (a struct with virtual
functions)
But the problem is D doesn't allow that, so apparently i need
to use an abstract class and wrap it us
On Monday, 28 December 2020 at 15:42:26 UTC, RSY wrote:
``IAllocator`` is an abstract struct, (a struct with virtual
functions)
But the problem is D doesn't allow that, so apparently i need
to use an abstract class and wrap it using: ``extern (C++,
struct)``
You could try using one of the t
IAllocator struct:
https://github.com/nem0/LumixEngine/blob/master/src/engine/allocator.h#L18
function:
https://github.com/nem0/LumixEngine/blob/master/src/renderer/gpu/gpu.h#L208
Hello
I try to use a C++ lib
So far so good, i managed to use that lib and get started
The problem however is this:
C++ API:
```
void preinit(IAllocator& allocator, bool load_renderdoc);
```
``IAllocator`` is an abstract struct, (a struct with virtual
functions)
But the problem is D does
On Sunday, 29 March 2020 at 17:32:59 UTC, kinke wrote:
On Sunday, 29 March 2020 at 15:20:52 UTC, YD wrote:
So what do I need to declare in the D file for it to match the
library entry? Thanks!
This is similar to
https://issues.dlang.org/show_bug.cgi?id=19260, and can be
worked around the sam
On Sunday, 29 March 2020 at 15:20:52 UTC, YD wrote:
So what do I need to declare in the D file for it to match the
library entry? Thanks!
This is similar to
https://issues.dlang.org/show_bug.cgi?id=19260, and can be worked
around the same way by messing manually with the mangled name, if
you
On Sunday, 29 March 2020 at 15:20:52 UTC, YD wrote:
On Sunday, 29 March 2020 at 01:50:24 UTC, evilrat wrote:
[...]
Thanks, dummy placeholder works. But there is a new problem on
Windows, let's say there are two classes in C++:
[...]
Actually I found that if I create a C wrapper like
On Sunday, 29 March 2020 at 01:50:24 UTC, evilrat wrote:
...
Same here, STL bindings is not yet finished. If you don't need
that method specifically, just replace it with a dummy. Or make
your own bindings.
Thanks, dummy placeholder works. But there is a new problem on
Windows, let's say th
On Saturday, 28 March 2020 at 19:14:38 UTC, YD wrote:
Hi, now I have a further question: when the C++ class A
actually has a method that looks like
virtual void get_info(std::string &s) const = 0;
in order to preserve the virtual function table layout (I found
that if I omit this functi
On Saturday, 28 March 2020 at 07:33:38 UTC, Jacob Carlborg wrote:
On 2020-03-27 20:17, YD wrote:
Hi, I have a C++ header file which looks like
class A {
public:
static A *create();
virtual int f() const = 0;
};
And there is a C++ library file which provides the
On Saturday, 28 March 2020 at 07:33:38 UTC, Jacob Carlborg wrote:
On 2020-03-27 20:17, YD wrote:
[...]
Classes in D are always passed by reference. Try dropping the
pointer in the `create` method:
static A create();
Thanks! I got it to work for now.
On 2020-03-27 20:17, YD wrote:
Hi, I have a C++ header file which looks like
class A {
public:
static A *create();
virtual int f() const = 0;
};
And there is a C++ library file which provides the implementation, so
that if I write a C++ program and call
Hi, I have a C++ header file which looks like
class A {
public:
static A *create();
virtual int f() const = 0;
};
And there is a C++ library file which provides the
implementation, so that if I write a C++ program and call
auto *p = A::create();
std::cout <
On Saturday, 6 January 2018 at 11:17:56 UTC, Seb wrote:
On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote:
I'm exploring [0] C++ interop after watching Walter's
presentation [1].
[...]
I know about this:
https://github.com/Remedy-Entertainment/binderoo
https://github
On Saturday, 6 January 2018 at 13:51:54 UTC, qznc wrote:
It would be great to have std::vector and std::string out of
the box in D, but putting it into druntime? Druntime is
supposed to be shared among all frontends, isn't it? GCC and
Clang probably do not have equivalent vector/string classes
On Saturday, 6 January 2018 at 11:20:01 UTC, Seb wrote:
On Saturday, 6 January 2018 at 11:17:56 UTC, Seb wrote:
On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote:
I'm exploring [0] C++ interop after watching Walter's
presentation [1].
[...]
I know about this:
https://github.
On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote:
I'm exploring [0] C++ interop after watching Walter's
presentation [1].
I hit a block with classes as template parameters. This means
vector works, but vector does not. D seems to map
vector!Foo to vector. Likewise share
On Saturday, 6 January 2018 at 11:17:56 UTC, Seb wrote:
On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote:
I'm exploring [0] C++ interop after watching Walter's
presentation [1].
[...]
I know about this:
https://github.com/Remedy-Entertainment/binderoo
https://github
On Friday, 5 January 2018 at 13:02:12 UTC, qznc wrote:
I'm exploring [0] C++ interop after watching Walter's
presentation [1].
[...]
I know about this:
https://github.com/Remedy-Entertainment/binderoo
https://github.com/dlang/druntime/pull/1802
see also https://github.com/Syniurge/Calypso/ although I'm having lots
of issues using it on OSX
On Fri, Jan 5, 2018 at 9:02 AM, qznc via Digitalmars-d-learn
wrote:
> I'm exploring [0] C++ interop after watching Walter's presentation [1].
>
> I hit a block with classe
I'm exploring [0] C++ interop after watching Walter's
presentation [1].
I hit a block with classes as template parameters. This means
vector works, but vector does not. D seems to map
vector!Foo to vector. Likewise shared_ptr is a
problem. Any way to fix that on the D side
On Tuesday, 8 September 2015 at 12:56:00 UTC, Laeeth Isharc wrote:
This is really very clear and helpful, and I appreciate your
taking the time. I will place it on the wiki if that's okay.
Thats ok.
Library support is surely one of the largest impediments to the
adoption of D, and we ou
On Wednesday, 9 September 2015 at 13:17:53 UTC, Mike Parker wrote:
Yes, I get that. But how does that work when you're linking to
a C++ library and the translation of the C++ class to D is an
interface? Or is it possible now to link D classes directly
with C classes?
Classes and templates exc
On Wednesday, 9 September 2015 at 11:49:33 UTC, Kagamin wrote:
Static functions are declared with `static` storage class. This
looks so basic, it's even not documented in language spec, lol.
Yes, I get that. But how does that work when you're linking to a
C++ library and the translation of t
Static functions are declared with `static` storage class. This
looks so basic, it's even not documented in language spec, lol.
In D classes are reference types by default.
On 2015-09-09 11:55, Mike Parker wrote:
Given a C++ class that looks like this:
class Foo {
static void Initialize(const SomeObject&);
virtual void func1();
}
The documentation at [1] doesn't say anything about how to handle static
member functions like Initialize, nor do I see anythin
Given a C++ class that looks like this:
class Foo {
static void Initialize(const SomeObject&);
virtual void func1();
}
The documentation at [1] doesn't say anything about how to handle
static member functions like Initialize, nor do I see anything
about references. I assume I can declar
On Wednesday, 9 September 2015 at 09:55:21 UTC, Mike Parker wrote:
The documentation at [1] doesn't say anything about how to
[1] http://dlang.org/cpp_interface.html
On Tuesday, 8 September 2015 at 12:56:00 UTC, Laeeth Isharc wrote:
How does it work when external APIs expect objects from the C++
standard library? strings, and so on? How about funny pointer
types? shared_ptr etc? std::vector, std::list?
No, in current state nothing smart is supported.
On Monday, 7 September 2015 at 18:37:49 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 16:19:49 UTC, Laeeth Isharc
wrote:
Hi Benjamin
Would you be able to give a little more colour on what the
limits are of interoperability for C++ with DMD master or
release ? As I understand it d
On 08.09.2015 11:45, Benjamin Thaut wrote:
On Monday, 7 September 2015 at 19:30:44 UTC, drug wrote:
07.09.2015 21:37, Benjamin Thaut пишет:
snip
So far I haven't found a situation where I couldn't make it work the way
I wanted. Its just some work to write the D headers for the C++ classes
and
On Monday, 7 September 2015 at 19:30:44 UTC, drug wrote:
07.09.2015 21:37, Benjamin Thaut пишет:
snip
So far I haven't found a situation where I couldn't make it
work the way
I wanted. Its just some work to write the D headers for the
C++ classes
and vise versa, because you have to duplicate
07.09.2015 21:37, Benjamin Thaut пишет:
snip
So far I haven't found a situation where I couldn't make it work the way
I wanted. Its just some work to write the D headers for the C++ classes
and vise versa, because you have to duplicate everything once more. An
automated tool for this would be n
On Friday, 4 September 2015 at 16:19:49 UTC, Laeeth Isharc wrote:
Hi Benjamin
Would you be able to give a little more colour on what the
limits are of interoperability for C++ with DMD master or
release ? As I understand it destructors and constructors
don't work, and obviously it will get t
On Friday, 4 September 2015 at 16:26:51 UTC, Kagamin wrote:
On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner
wrote:
but now using phobos64.lib from 2.068 distribution does not
even link properly with VC2015.
That's https://issues.dlang.org/show_bug.cgi?id=14849
yup, that looks like
On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner wrote:
but now using phobos64.lib from 2.068 distribution does not
even link properly with VC2015.
That's https://issues.dlang.org/show_bug.cgi?id=14849
On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner
wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? La
On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner
wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? La
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to c
See https://issues.dlang.org/show_bug.cgi?id=13889
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to compile it yourself. Use the win64 makefile and
replace the arch=64
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to compile it yourself. Use the win64 makefile and
replace the arch=64 with
arch=32mscoff.
For more details see here:
http://www.digital
On Friday, 4 September 2015 at 08:58:41 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner
wrote:
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to
come with 2.068
If
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote:
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to
come with 2.068
If you use either the -m64 or -mscoff32 interop should be pretty
good
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to come
with 2.068
would someone care to work on updating this? I understand from
Daniel's post in main list that the only thing that doesn't work
is special member functions. that's different from what the
documents say, and it is surely something important for D that
people are aware of this.
I don't really
Given that I explicitly stated my interest in to the
metal programming, I dont think the .NET implementation
will do me any good, no matter how perfectly implemented
it is.
As Simen said, there was an attempt to create an IL backend but it hasn't
been updated since Aug 2009 and even it compiled you probably wouldn't
have much fun with it.
You could try to use a C bridge. But even then, I don't see the benefit.
Eelco Hoogendoorn wrote:
Hi,
I am trying to combine C# and D, to get what is to me the best of both
worlds; large libraries and excellent toolchain, with to the
metal programming.
Currently, I am doing this by means of C#/CLI/C++ interop, but I got
reminded as to why I hate C++ so much
Hi,
I am trying to combine C# and D, to get what is to me the best of both worlds;
large libraries and excellent toolchain, with to the
metal programming.
Currently, I am doing this by means of C#/CLI/C++ interop, but I got reminded
as to why I hate C++ so much after spending a few days
trying
60 matches
Mail list logo
