This is just a random musing, but curious if anyone had any comments.

I work mostly in C++ but recently I've been doing more with farming out tricky bits to Python so I can develop those parts more rapidly.  That works pretty well, but for some things Python is just not fast enough. But still, while prototyping at least, I'd rather use a language that's easier to develop in than C++.

That's where the question comes in... How about D as an extension language?  For the time being, using C++ is a fact of life for a lot of people due to extensive dependence on piles of C++ legacy code.  But if I'm writing a new module or new functionality, it doesn't matter how it does it's thing under the hood as long as it presents a C++ interface to the rest of the system.

So how hard is it to do this sort of thing?
What tools are out there to help?
What tools would really be ideal to have but are missing?

It seems like it should be easier than the Python<->C++ connection because D understands C ABI.  But most of what I've seen is about how D can call C code, not how C++ can call D code.

I think it's worth thinking about.  It is one more way that D could make some inroads in a C++ entrenched world.

--bb

Bill Baxter wrote:
> This is just a random musing, but curious if anyone had any comments.
> 
> I work mostly in C++ but recently I've been doing more with farming out tricky bits to Python so I can develop those parts more rapidly.  That works pretty well, but for some things Python is just not fast enough. But still, while prototyping at least, I'd rather use a language that's easier to develop in than C++.
> 
> That's where the question comes in... How about D as an extension language?  For the time being, using C++ is a fact of life for a lot of people due to extensive dependence on piles of C++ legacy code.  But if I'm writing a new module or new functionality, it doesn't matter how it does it's thing under the hood as long as it presents a C++ interface to the rest of the system.
> 
> So how hard is it to do this sort of thing?
> What tools are out there to help?
> What tools would really be ideal to have but are missing?
> 
> It seems like it should be easier than the Python<->C++ connection because D understands C ABI.  But most of what I've seen is about how D can call C code, not how C++ can call D code.
> 
> I think it's worth thinking about.  It is one more way that D could make some inroads in a C++ entrenched world.
> 
> --bb

For what it's worth, I think that D and Python go together quite nicely. This is the whole point of Pyd, which hopes to do for D what Boost.Python does for C++. (http://pyd.dsource.org) The concept of prototyping with Python and dropping into D when speed is needed is a sort of end-goal of Pyd's.

As for calling D code from C++, you should be able to call any D functions that are declared extern(C). Analogous to calling C code from D, you'll have to provide a header for C++ to #include, then just link as needed. The two languages can't talk to each other directly, of course, so you always have to go through this C layer.

There do exist tools to streamline this process to an extent, I believe, but I can't say as I'm familiar with them. Sorry.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Bill Baxter wrote:
> This is just a random musing, but curious if anyone had any comments.
> 
> I work mostly in C++ but recently I've been doing more with farming out tricky bits to Python so I can develop those parts more rapidly.  That works pretty well, but for some things Python is just not fast enough. But still, while prototyping at least, I'd rather use a language that's easier to develop in than C++.
> 
> That's where the question comes in... How about D as an extension language?  For the time being, using C++ is a fact of life for a lot of people due to extensive dependence on piles of C++ legacy code.  But if I'm writing a new module or new functionality, it doesn't matter how it does it's thing under the hood as long as it presents a C++ interface to the rest of the system.
> 
> So how hard is it to do this sort of thing?
> What tools are out there to help?
> What tools would really be ideal to have but are missing?
> 
> It seems like it should be easier than the Python<->C++ connection because D understands C ABI.  But most of what I've seen is about how D can call C code, not how C++ can call D code.

I'm doing a lot of Windows stuff in C++, calling DLLs written in D. It's not hard. You just need to use extern(C) wrappers on the D functions, catch all the D exceptions before returning to C++, and make sure C++ doesn't hang onto any D pointers that could be gc-ed.
Otherwise, it's exactly the same as calling a C DLL.

I have some C++ code to simplify dynamic loading of D DLLs in Windows, if you're interested (it does the name mangling for you). Useless for Linux, of course.

> I think it's worth thinking about.  It is one more way that D could make some inroads in a C++ entrenched world.

Absolutely.

Kirk McDonald wrote:
> For what it's worth, I think that D and Python go together quite nicely. This is the whole point of Pyd, which hopes to do for D what Boost.Python does for C++. (http://pyd.dsource.org) The concept of prototyping with Python and dropping into D when speed is needed is a sort of end-goal of Pyd's.

Yeh, that does sound like a very nice concept.  Except I seem to be the only one who's not so wild about Boost.Python.  Heavy dependencies, not so scalable to big projects from what I understand, and kind of odd syntax.  Browsing through the docs, PyD does look somehow a little more appealing though.  Maybe the lack of mystery macros like BOOST_PYTHON_MODULE, lack of ugly c++ member-pointer syntax (&Class::method), and using a more normal D style in your examples rather than trying to pretend you're writing a class declaration by naming the wrapper generator class "class_" and chaining .def's one after the other.  Also the second page of Boost.Python's tutorial being "let's learn how to use bjam so we can compile Hello World!" is kind of a turn off.  Celerid looks like a much nicer way to handle building simple extension modules.

> As for calling D code from C++, you should be able to call any D functions that are declared extern(C). Analogous to calling C code from D, you'll have to provide a header for C++ to #include, then just link as needed. The two languages can't talk to each other directly, of course, so you always have to go through this C layer.
> 
> There do exist tools to streamline this process to an extent, I believe, but I can't say as I'm familiar with them. Sorry.

Would some sort of D-API for C be useful there?  For instance Python has its C-API from which you can create and manipulate basic python datatypes, muck with reference counts, etc.  How do you manipulate a D string from C, for example?

--bb

Don Clugston wrote:
> I'm doing a lot of Windows stuff in C++, calling DLLs written in D. It's not hard. You just need to use extern(C) wrappers on the D functions, catch all the D exceptions before returning to C++, and make sure C++ doesn't hang onto any D pointers that could be gc-ed.
> Otherwise, it's exactly the same as calling a C DLL.
> 
> I have some C++ code to simplify dynamic loading of D DLLs in Windows, if you're interested (it does the name mangling for you). Useless for Linux, of course.

If you could write up a brief page/article/tutorial on that, I think that would be helpful to a lot of people.