www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D as an extension language

reply Bill Baxter <wbaxter gmail.com> writes:
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
Aug 30 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
Aug 31 2006
parent Bill Baxter <wbaxter gmail.com> writes:
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
Aug 31 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Aug 31 2006
parent Walter Bright <newshound digitalmars.com> writes:
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.
Aug 31 2006