I want to sum up some issues that would have to be resolved in order for
D code to call some arbitrary C++ code that is presumed to be
unmodifiable. This list certainly isn't complete, I just write it to
show the scope of the difficulties involved.
1) D source code is unicode, C++'s is ascii with code pages. Or not.
It's unspecified. This impacts the contents of string literals.
2) std::string cannot deal with multibyte UTF.
3) C++ has a tag name space. D does not. Some sort of renaming would
have to happen.
4) C++ code often relies on compiler specific extensions.
5) C++ has namespaces. D has modules. There is no obvious mapping
between the two.
6) C++ views source code as one gigantic file (after preprocessing). D
sees source code as a hierarchy of modules and packages.
7) Enum name scoping rules behave differently.
8) C++ code, despite decades of attempts to replace macro features with
inbuilt ones, relies more heavily than ever on layer after layer of
arbitrary macros. There is no D analog for token pasting or stringizing.
9) Macro names have global scope across #include files, but are local to
the gigantic source files.
10) C++ has arbitrary multiple inheritance and virtual base classes. D
does not.
11) C++ does not distinguish between in, out and inout parameters.
12) The C++ name mangling varies from compiler to compiler.
13) C++ throws exceptions of arbitrary type, not just descendents of Object.
14) C++ overloads based on const and volatile. D does not.
15) C++ overloads operators in significantly different ways - for
example, operator[]() overloading for lvalue and rvalue is based on
const overloading and a proxy class.
16) C++ overloads operators like < completely independently of >.
17) C++ overloads indirection (operator*).
18) C++ does not distinguish between a class and a struct object.
19) The vtbl[] location and layout is different between C++ and D.
20) The way RTTI is done is completely different. C++ has no classinfo.
21) D does not allow overloading of assignment.
22) D does not have constructors or destructors for struct objects.
23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
24) C++ relates classes with the 'friend' system, D uses packages and
modules.
25) C++ class design tends to revolve around explicit memory allocation
issues, D's do not.
26) D's template system is very different.
27) C++ has 'exception specifications'.
28) C++ has global operator overloading.
The bottom line is the language features affect the design of the code.
C++ designs just don't fit with D. Even if you could find a way to
automatically adapt between the two, the result will be about as
enticing as the left side of a honda welded to the right side of a camaro.

I want to sum up some issues that would have to be resolved in order for
D code to call some arbitrary C++ code that is presumed to be
unmodifiable. This list certainly isn't complete, I just write it to
show the scope of the difficulties involved.
1) D source code is unicode, C++'s is ascii with code pages. Or not.
It's unspecified. This impacts the contents of string literals.
2) std::string cannot deal with multibyte UTF.
3) C++ has a tag name space. D does not. Some sort of renaming would
have to happen.
4) C++ code often relies on compiler specific extensions.
5) C++ has namespaces. D has modules. There is no obvious mapping
between the two.
6) C++ views source code as one gigantic file (after preprocessing). D
sees source code as a hierarchy of modules and packages.
7) Enum name scoping rules behave differently.
8) C++ code, despite decades of attempts to replace macro features with
inbuilt ones, relies more heavily than ever on layer after layer of
arbitrary macros. There is no D analog for token pasting or stringizing.
9) Macro names have global scope across #include files, but are local to
the gigantic source files.
10) C++ has arbitrary multiple inheritance and virtual base classes. D
does not.
11) C++ does not distinguish between in, out and inout parameters.
12) The C++ name mangling varies from compiler to compiler.
13) C++ throws exceptions of arbitrary type, not just descendents of
Object.
14) C++ overloads based on const and volatile. D does not.
15) C++ overloads operators in significantly different ways - for
example, operator[]() overloading for lvalue and rvalue is based on
const overloading and a proxy class.
16) C++ overloads operators like < completely independently of >.
17) C++ overloads indirection (operator*).
18) C++ does not distinguish between a class and a struct object.
19) The vtbl[] location and layout is different between C++ and D.
20) The way RTTI is done is completely different. C++ has no classinfo.
21) D does not allow overloading of assignment.
22) D does not have constructors or destructors for struct objects.
23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
24) C++ relates classes with the 'friend' system, D uses packages and
modules.
25) C++ class design tends to revolve around explicit memory allocation
issues, D's do not.
26) D's template system is very different.
27) C++ has 'exception specifications'.
28) C++ has global operator overloading.
The bottom line is the language features affect the design of the code.
C++ designs just don't fit with D. Even if you could find a way to
automatically adapt between the two, the result will be about as
enticing as the left side of a honda welded to the right side of a camaro.

Good points, I totally agree.
But .. I still think something can be done.
Yes, it's practically impossible to automatically convert C++ to D.
However, practically, do we need all of C++, or just a subset?
I claim that there are a lot of great C++ projects out there that don't
rely too much on templates or operator overloading.
Can C++ classes be converted to D classes? even if not fully?
For starters, the following pattern:
class Foo
{
type bar( params );
};
type Foo::bar( params )
{
body;
}
should be easy to convert to:
class Foo
{
type bar( params )
{
body;
}
}
assuming that no complex C++ features are used in the definitions.
I don't want dmd to implement that. I'm thinking more of a
conversion-tool that automates these simple things. This can probably
cut down the effort of manual translation by %50. Although I can't say,
because I haven't tried a manual translation of C++ code.
I'm thinking of the OGRE project. http://www.ogre3d.org/
It's very well designed and written. I think it uses a good Object
Oriented style. I would love to see it converted to D.
Walter Bright wrote:

I want to sum up some issues that would have to be resolved in order for
D code to call some arbitrary C++ code that is presumed to be
unmodifiable. This list certainly isn't complete, I just write it to
show the scope of the difficulties involved.
1) D source code is unicode, C++'s is ascii with code pages. Or not.
It's unspecified. This impacts the contents of string literals.
2) std::string cannot deal with multibyte UTF.
3) C++ has a tag name space. D does not. Some sort of renaming would
have to happen.
4) C++ code often relies on compiler specific extensions.
5) C++ has namespaces. D has modules. There is no obvious mapping
between the two.
6) C++ views source code as one gigantic file (after preprocessing). D
sees source code as a hierarchy of modules and packages.
7) Enum name scoping rules behave differently.
8) C++ code, despite decades of attempts to replace macro features with
inbuilt ones, relies more heavily than ever on layer after layer of
arbitrary macros. There is no D analog for token pasting or stringizing.
9) Macro names have global scope across #include files, but are local to
the gigantic source files.
10) C++ has arbitrary multiple inheritance and virtual base classes. D
does not.
11) C++ does not distinguish between in, out and inout parameters.
12) The C++ name mangling varies from compiler to compiler.
13) C++ throws exceptions of arbitrary type, not just descendents of
Object.
14) C++ overloads based on const and volatile. D does not.
15) C++ overloads operators in significantly different ways - for
example, operator[]() overloading for lvalue and rvalue is based on
const overloading and a proxy class.
16) C++ overloads operators like < completely independently of >.
17) C++ overloads indirection (operator*).
18) C++ does not distinguish between a class and a struct object.
19) The vtbl[] location and layout is different between C++ and D.
20) The way RTTI is done is completely different. C++ has no classinfo.
21) D does not allow overloading of assignment.
22) D does not have constructors or destructors for struct objects.
23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
24) C++ relates classes with the 'friend' system, D uses packages and
modules.
25) C++ class design tends to revolve around explicit memory allocation
issues, D's do not.
26) D's template system is very different.
27) C++ has 'exception specifications'.
28) C++ has global operator overloading.
The bottom line is the language features affect the design of the code.
C++ designs just don't fit with D. Even if you could find a way to
automatically adapt between the two, the result will be about as
enticing as the left side of a honda welded to the right side of a camaro.

The trouble is, they always are. I once looked at automated translation
of wxWindows, and that's written in a pre-STL pre-template style. No way.
The only C++ code I've been able to convert without much difficulty is
my own, and that's because I use a gc with my C++ projects, and I
deliberately write it in a D style. You can see that in the DMD front
end source.

my own, and that's because I use a gc with my C++ projects, and I
deliberately write it in a D style. You can see that in the DMD

end source.

Are there guidelines for writing C/C plus plus in D style?
I'm involved in several freeware projects that I've considered
converting to D when 1.0 is released. Are there things I could be
doing (and not doing) now to facilitate that?

my own, and that's because I use a gc with my C++ projects, and I
deliberately write it in a D style. You can see that in the DMD

end source.

Are there guidelines for writing C/C plus plus in D style?
I'm involved in several freeware projects that I've considered
converting to D when 1.0 is released. Are there things I could be
doing (and not doing) now to facilitate that?

No, there are no guidelines. But you can look at the dmd source and get
a feel for it.

I'm thinking of the OGRE project. http://www.ogre3d.org/
It's very well designed and written. I think it uses a good Object
Oriented style. I would love to see it converted to D.

Yes, the Sinbad project at DSource was supposed to be an implementation of
OGRE in D. Even if OGRE is fairly clean, it use quite a bit of MI which
isn't easily solvable in D without changing how things should work. Also,
OGRE is heavily relying upon plugins, which currently are somewhat
difficult to do in D, although DDL is getting there. It is also using a bit
of STL, so all in all I suspect it is a typical C++ library that is
typically difficult to convert to D without huge manual efforts.
--
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

I'm thinking of the OGRE project. http://www.ogre3d.org/
It's very well designed and written. I think it uses a good Object
Oriented style. I would love to see it converted to D.

Yes, the Sinbad project at DSource was supposed to be an implementation of
OGRE in D. Even if OGRE is fairly clean, it use quite a bit of MI which
isn't easily solvable in D without changing how things should work. Also,
OGRE is heavily relying upon plugins, which currently are somewhat
difficult to do in D, although DDL is getting there. It is also using a bit
of STL, so all in all I suspect it is a typical C++ library that is
typically difficult to convert to D without huge manual efforts.

sigh :(
oh well, maybe a better and faster engine can be done in D, from scratch!

sigh :(
oh well, maybe a better and faster engine can be done in D, from scratch!

I'm working on it, I'm working on it! ;)
I was surprised to look at the OGRE page and see so many features that it
has that nonagon has as well.. of course, OGRE is much more mature,
API-independent, and therefore cross-platform, but.. I'm working on it!

sigh :(
oh well, maybe a better and faster engine can be done in D, from scratch!

I'm working on it, I'm working on it! ;)
I was surprised to look at the OGRE page and see so many features that it
has that nonagon has as well.. of course, OGRE is much more mature,
API-independent, and therefore cross-platform, but.. I'm working on it!

Do you have plans to abstract away from DirectX?
--
Kyle Furlong // Physics Undergrad, UCSB
"D is going wherever the D community wants it to go." - Walter Bright

Perhaps once I've become truly comfortable with DirectX ;)
Though the engine design itself is kind of.. automatically moving itself
away from platform-dependence. I'm not consciously doing it, but as I
reorganize the engine, it just ends up that way. For example, so far
working on R5, I've abstracted mesh data and loading, I've abstracted some
of the OS interfaces, and I've clearly delineated the two pipelines, so all
the common code would be pretty much implementation-independent. So, with
maybe one more major release of nonagon (R6, one after the next), it might
be abstracted enough that making a platform-independent version of it
wouldn't be too hard.

sigh :(
oh well, maybe a better and faster engine can be done in D, from scratch!

I'm working on it, I'm working on it! ;)
I was surprised to look at the OGRE page and see so many features that it
has that nonagon has as well.. of course, OGRE is much more mature,
API-independent, and therefore cross-platform, but.. I'm working on it!

Good to know. :)
I would love to participate in such a project, but my knowledge of
graphics APIs is next to nothing.
Do you have a website for the project? can you possibly put it on dsource?

Good to know. :)
I would love to participate in such a project, but my knowledge of
graphics APIs is next to nothing.

Pah, it's not hard to pick up.. just set a couple states, load some data,
and draw ;)

Do you have a website for the project? can you possibly put it on dsource?

I have a download thing, at
http://jamesdunne.no-ip.org/nonagon/projects.php, but no real project page.
I've been planning on making it open-source as of late, since I can't seem
to find the time/drive to work on it for long periods of time. Right now,
it's in a very transitional state, as I've been reworking a lot of the
internals of the engine, splitting apart the two pipelines, cleaning up
dependencies, refactoring some code, and working on getting model animation
working (which it is, for the most part, at least in the fixed-function
pipeline). But I'd still like to make a page for it on dsource or
something.

Good to know. :)
I would love to participate in such a project, but my knowledge of
graphics APIs is next to nothing.

Pah, it's not hard to pick up.. just set a couple states, load some data,
and draw ;)

Do you have a website for the project? can you possibly put it on dsource?

I have a download thing, at
http://jamesdunne.no-ip.org/nonagon/projects.php, but no real project page.
I've been planning on making it open-source as of late, since I can't seem
to find the time/drive to work on it for long periods of time. Right now,
it's in a very transitional state, as I've been reworking a lot of the
internals of the engine, splitting apart the two pipelines, cleaning up
dependencies, refactoring some code, and working on getting model animation
working (which it is, for the most part, at least in the fixed-function
pipeline). But I'd still like to make a page for it on dsource or
something.

I would be interested in making this a premier game solution in D with
you. Dsource would be the way to go to collaborate.
--
Kyle Furlong // Physics Undergrad, UCSB
"D is going wherever the D community wants it to go." - Walter Bright

I have a download thing, at
http://jamesdunne.no-ip.org/nonagon/projects.php, but no real project page.
I've been planning on making it open-source as of late, since I can't seem
to find the time/drive to work on it for long periods of time. Right now,
it's in a very transitional state, as I've been reworking a lot of the
internals of the engine, splitting apart the two pipelines, cleaning up
dependencies, refactoring some code, and working on getting model animation
working (which it is, for the most part, at least in the fixed-function
pipeline). But I'd still like to make a page for it on dsource or
something.

D3DX9 currently has a version of 28. It's a wonderful thing if you can upgrade
newer version of nonagon.

This should go into the FAQ to avoid lengthy discussions in the future.
After reading these groups for a couple of months I find it already hard
enough to follow up with all the traffic. And I'm a bit confused that
people keep popping up making bold requests on a language below version
1.0. Healthy growth is slow and steady, just what I observe with D. I'm
looking forward to the next couple of months...
op

explain the c++ linkage problem a litte bit more detailed:
for example:
"have you ever tried to link your visualc++, borlandc++ and other (c++
compilers) produced libs together - do it and you will see how (realy)
well the c++ abi is standarized :-)"
ciao dennis

explain the c++ linkage problem a litte bit more detailed:
for example:
"have you ever tried to link your visualc++, borlandc++ and other (c++
compilers) produced libs together - do it and you will see how (realy)
well the c++ abi is standarized :-)"

DMC++ (in a former life) was designed to be ABI compatible with
Microsoft C++, and it was for a while, until Microsoft changed their
ABI. Sigh.

I want to sum up some issues that would have to be resolved in order for
D code to call some arbitrary C++ code that is presumed to be
unmodifiable. This list certainly isn't complete, I just write it to
show the scope of the difficulties involved.
1) D source code is unicode, C++'s is ascii with code pages. Or not.
It's unspecified. This impacts the contents of string literals.
2) std::string cannot deal with multibyte UTF.
3) C++ has a tag name space. D does not. Some sort of renaming would
have to happen.
4) C++ code often relies on compiler specific extensions.
5) C++ has namespaces. D has modules. There is no obvious mapping
between the two.
6) C++ views source code as one gigantic file (after preprocessing). D
sees source code as a hierarchy of modules and packages.
7) Enum name scoping rules behave differently.
8) C++ code, despite decades of attempts to replace macro features with
inbuilt ones, relies more heavily than ever on layer after layer of
arbitrary macros. There is no D analog for token pasting or stringizing.
9) Macro names have global scope across #include files, but are local to
the gigantic source files.
10) C++ has arbitrary multiple inheritance and virtual base classes. D
does not.
11) C++ does not distinguish between in, out and inout parameters.
12) The C++ name mangling varies from compiler to compiler.
13) C++ throws exceptions of arbitrary type, not just descendents of
Object.
14) C++ overloads based on const and volatile. D does not.
15) C++ overloads operators in significantly different ways - for
example, operator[]() overloading for lvalue and rvalue is based on
const overloading and a proxy class.
16) C++ overloads operators like < completely independently of >.
17) C++ overloads indirection (operator*).
18) C++ does not distinguish between a class and a struct object.
19) The vtbl[] location and layout is different between C++ and D.
20) The way RTTI is done is completely different. C++ has no classinfo.
21) D does not allow overloading of assignment.
22) D does not have constructors or destructors for struct objects.
23) D does not have two phase lookup, nor does it have Koenig (ADL) lookup.
24) C++ relates classes with the 'friend' system, D uses packages and
modules.
25) C++ class design tends to revolve around explicit memory allocation
issues, D's do not.
26) D's template system is very different.
27) C++ has 'exception specifications'.
28) C++ has global operator overloading.
The bottom line is the language features affect the design of the code.
C++ designs just don't fit with D. Even if you could find a way to
automatically adapt between the two, the result will be about as
enticing as the left side of a honda welded to the right side of a camaro.

And if that wasn't enough to turn you off to the idea, then you could
try to use Lightweight C++
<http://students.ceid.upatras.gr/~sxanth/lwc/> to translate your
extremely-dumbed-down C++ code into C code. For best interoperability
with DMD, you'd have to compile the C code with DMC.
Slight caveat: "To compile the generated C you need gcc or another
compiler with support for: C99 designators, compound statements in
expressions and typeof." Does DMC fit this bill?
Disclaimer: I realize this is to the point of absurdity, but I would
try to make the point that it is no more absurd than to expect any more
out of a language (C++) that has designed itself into a corner.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O
M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------
James Dunne

Disclaimer: I realize this is to the point of absurdity, but I would
try to make the point that it is no more absurd than to expect any more
out of a language (C++) that has designed itself into a corner.

That's right. I wouldn't be surprised if automatic conversion of C++
code to Java/C#/Eiffel/Ruby/... weren't any easier than this. On the
other hand converting all these to D seems to be almost trivial,
although creating such a tool for the task is admittedly a bit time
consuming.
--
Jari-Matti

Disclaimer: I realize this is to the point of absurdity, but I would
try to make the point that it is no more absurd than to expect any more
out of a language (C++) that has designed itself into a corner.

That's right. I wouldn't be surprised if automatic conversion of C++
code to Java/C#/Eiffel/Ruby/... weren't any easier than this. On the
other hand converting all these to D seems to be almost trivial,
although creating such a tool for the task is admittedly a bit time
consuming.

Automated conversion of Java/C# to D would be reasonable, maybe Eiffel.
Ruby definitely not, as Ruby relies on dynamic typing and dynamic code
modification.
I do agree, however, that C++ has rather thoroughly wedged itself into a
corner. One only has to look at the proposals for C++0x to see that.

IMO, Accessing C++ code from D is not a feature that should be supported by the
D compiler.
There has been some attempts to build C++ wrapper generators for D: swig, a
macro system and I even made one myself (but the memory management is ugly). We
just need C void * pointers. There are (and will be) brilliant people who
(will) make great tools for D. The impatients (like me) can try to link with the
ones they used in C++. We need time.
I also tried to make a C++ to D translator by modifying Peri's Hankey d2d
language machine script. It can handle small sized code and output quite
syntactically correct D code but the semantic is incorrect, especially for
templates because of the overwhelming "template <T>" syntax. I've given up for
the moment. A translator is not enough: a C++ compiler to D could eventually do
it but sounds like nonsense.
Being a successor of C++ doesn't means that D should support it. Java does not
support C++ and this lack has not prevent it to spread.

IMO, Accessing C++ code from D is not a feature that should be supported by the
compiler.
There has been some attempts to build C++ wrapper generators for D: swig, a
macro system and I even made one myself (but the memory management is ugly). We
just need C void * pointers. There are (and will be) brilliant people who
(will) make great tools for D. The impatients (like me) can try to link with
the ones they used in C++. We need time.

Swig works well for what it does. Generally however you have to devote quite a
bit of time to a swig wrapper to keep it in sync as well.

I also tried to make a C++ to D translator by modifying Peri's Hankey d2d
language machine script. It can handle small sized code and output quite
syntactically correct D code but the semantic is incorrect, especially for
templates because of the overwhelming "template <T>" syntax. I've given up for
the moment. A translator is not enough: a C++ compiler to D could eventually
>do it but sounds like nonsense.

I don't think a C++ to D translator is possible or even a good idea. Cpp simply
would not translate into equivalent D idioms except in trivial instances. That
being said, Cpp/D interop is a completely different animal. With interop,
you're not trying to translate one idiom into another, instead you're just
making it easier for each to co-exist, and to be able to easily access the
functionality of one from within the other without rewriting.
Microsoft's Cpp/CLI is an excellent example of how interop can work. Cpp is not
C#, but it allows you to work with C# objects, members, enums, and GC from
within a traditional Cpp program in a reasonably effective manner, and without
having to rewrite your C# code in Cpp, or vicsa versa.
Cpp interop is not "translation". It would be limited to being able to access
members of a cpp class, call cpp member functions, use C and Cpp macros, and
inline C or Cpp code. Parsing of Cpp headers would be handled by the Cpp
compiler's parser using GCC-XML. And compiling of Cpp interop code for
templates, macros, and other complex Cpp elements would be handled by the Cpp
compiler, and accessed in D through C functions.
For example, with this system, the issues you had with templates simply don't
arise because templates are not converted into D template code, they are
specialized nto standard Cpp classes and compiled with the Cpp compiler, and
those classes are called from the D/Cpp interop system.

Being a successor of C++ doesn't means that D should support it. Java does not
support C++ and this lack has not prevent it to spread.

Yes, and yes.
Yes it certainly should support interop if there is any real intention of being
a successor to Cpp.
And Yes, interop issues are part of the reason why the new .NET system is
gaining ground against Java. Both microsoft C# and Cpp have interop with
eachother. C# has unsafe code, which is completely compatible with C and Cpp,
and Cpp has complete interop with the .NET world, including C#.
Outside of the D forums in the general programming world these issues are not
really controversial. They are considered self evident and obvious. This is
why D is not a real alternative to Cpp or C for most programmers. The successor
to Cpp will not be D, it will be Cpp 0x.

Yes it certainly should support interop if there is any real intention of being
a successor to Cpp.

No it shouldn't. D is trying to break away from C++, not extend it.

And Yes, interop issues are part of the reason why the new .NET system is
gaining ground against Java. Both microsoft C# and Cpp have interop with
eachother. C# has unsafe code, which is completely compatible with C and Cpp,
and Cpp has complete interop with the .NET world, including C#.

C# was designed from the beginning to run on CLI. CLI was designed so
that multiple languages could share the same resources and talk to each
other. D had no such design goals.

Outside of the D forums in the general programming world these issues are not
really controversial. They are considered self evident and obvious. This is
why D is not a real alternative to Cpp or C for most programmers.

All of the D community comes from /outside/ of the D community, and most
of us still live and work there. In my world, what you are saying just
isn't true. You focus too much on C++, your circumstances, and the
circumstances of people you know. The general programming world is much
larger than that. I don't give a rat's ass about C++ interoperability.
Most people I know wouldn't give a rat's ass about it either. I know C++
programmers who would happily switch over and use D for all of their new
projects once their bosses approve it.
But why should would you stop with C++ interoperability? What all of the
Java code bases out there? Surely they would be more likely to come to D
if they could use their existing code. What about the C# programmers? Or
the VB programmers? Why not just develop our own Common Language
Interface? Because that's not the design goal behind D.
D isn't meant to just be a replacement for C++. It melds the features of
several languages, along with new ideas, into something that is an
excellent /alternative/ to many existing languages, not just C++. C++
interoperability would only be useful to a small subset of potential D
users, not the masses to whom you claim it is self evident.
Obviously, D isn't going to be suited to every project. If you rely on a
few million lines of C++, Java, or other code (besides C), then D isn't
the best solution for leveraging that code base. But I just don't see
how that is going to be a deal breaker for D's acceptance. I think the
problem is much smaller than you let on.

[snip]
And Yes, interop issues are part of the reason why the new .NET system is
gaining ground against Java. Both microsoft C# and Cpp have interop with
eachother. C# has unsafe code, which is completely compatible with C and Cpp,
and Cpp has complete interop with the .NET world, including C#.

C#'s unsafe code is not native or unmanaged code - it is managed code
that allows the use of pointers into the GC heap. C# only interops with
C code through runtime marshalling. It does not interop with native C++
code - such code has to be recompiled through Microsoft's "Managed
Extensions for C++" compiler, after much tinkering albeit.
I'll bet that if you were to take the time to convert your existing C++
library over to .NET you'd find you'd spend the same amount of time as
you would creating a C API wrapper around such code for D to use.
--
Regards,
James Dunne