www.digitalmars.com         C & C++   DMDScript  

D - What is the D runtime like?

reply Phil Brooks <phil_brooks mentor.com> writes:
What is D's runtime like?  Specifically, I am wondering what the requirements
are for a D module
that is to be linked into an application (written in D or C or C++ or another
version of D that
has different runtime).

Problems with the C++ Runtime
-----------------------------
It seems to me that the runtime is one of the biggest stumbling blocks out
there with C++ as 
opposed to C.  It means that you can't do pre-compiled components (a la COM
etc) in C++ without 
having some sort of guarantee about the characteristics of the runtime.  It
means that if you are 
writing a large C++ application with addins and reused libraries etc, you have
to get everyone to 
go to the new version of C++ in lock step (when the chain of providers spans
several companies, this
is a big problem).  

It seems that Java went even farther in the direction of controlling the
runtime.  The nicest thing
about C (and often a constraint that forces people to use C) is that the
runtime is generally 
compatible across different compiler versions and providers.  The runtime is
also scalable so that
it can be easily constrained when it needs to be (i.e. Kernel, driver, embedded
work constrain
the runtime most often by not using functions that aren't available).

If D can solve this problem by keeping its entire runtime inside a 'module' or
accessing it through
other defined 'module' interfaces that only rely on a C runtime (a la COM),
then D modules can run
inside any application that runs in a C runtime.  Certainly restriction on
various features would 
apply.  Things like explicitly loading and initializing modules rather than
having them just be
there come to mind.  I am sure that it would affect garbage collectors as well.

comments?
Sep 13 2001
parent reply "Walter" <walter digitalmars.com> writes:
D's runtime will not be a monolithic block like Java's is. It will be more a
collection of modules like C's is. -Walter


"Phil Brooks" <phil_brooks mentor.com> wrote in message
news:3BA0DDBE.33B0FC98 mentor.com...
 What is D's runtime like?  Specifically, I am wondering what the

 that is to be linked into an application (written in D or C or C++ or

 has different runtime).

 Problems with the C++ Runtime
 -----------------------------
 It seems to me that the runtime is one of the biggest stumbling blocks out

 opposed to C.  It means that you can't do pre-compiled components (a la

 having some sort of guarantee about the characteristics of the runtime.

 writing a large C++ application with addins and reused libraries etc, you

 go to the new version of C++ in lock step (when the chain of providers

 is a big problem).

 It seems that Java went even farther in the direction of controlling the

 about C (and often a constraint that forces people to use C) is that the

 compatible across different compiler versions and providers.  The runtime

 it can be easily constrained when it needs to be (i.e. Kernel, driver,

 the runtime most often by not using functions that aren't available).

 If D can solve this problem by keeping its entire runtime inside a

 other defined 'module' interfaces that only rely on a C runtime (a la

 inside any application that runs in a C runtime.  Certainly restriction on

 apply.  Things like explicitly loading and initializing modules rather

 there come to mind.  I am sure that it would affect garbage collectors as

 comments?

Sep 13 2001
parent reply Phil Brooks <phil_brooks mentor.com> writes:
What does that mean with regards to:

running programs that contain D modules from multiple versions/different
features
   especially if the object model changes between the two?  what about stuff
like
   GC?
running programs that have a C mainline and are linked with the C linker.
running programs that have a C++ mainline?
running a D module in a kernel?
running a D module as a COM inproc component?

Walter wrote:
 
 D's runtime will not be a monolithic block like Java's is. It will be more a
 collection of modules like C's is. -Walter
 
 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA0DDBE.33B0FC98 mentor.com...
 What is D's runtime like?  Specifically, I am wondering what the

 that is to be linked into an application (written in D or C or C++ or

 has different runtime).

 Problems with the C++ Runtime
 -----------------------------
 It seems to me that the runtime is one of the biggest stumbling blocks out

 opposed to C.  It means that you can't do pre-compiled components (a la

 having some sort of guarantee about the characteristics of the runtime.

 writing a large C++ application with addins and reused libraries etc, you

 go to the new version of C++ in lock step (when the chain of providers

 is a big problem).

 It seems that Java went even farther in the direction of controlling the

 about C (and often a constraint that forces people to use C) is that the

 compatible across different compiler versions and providers.  The runtime

 it can be easily constrained when it needs to be (i.e. Kernel, driver,

 the runtime most often by not using functions that aren't available).

 If D can solve this problem by keeping its entire runtime inside a

 other defined 'module' interfaces that only rely on a C runtime (a la

 inside any application that runs in a C runtime.  Certainly restriction on

 apply.  Things like explicitly loading and initializing modules rather

 there come to mind.  I am sure that it would affect garbage collectors as

 comments?


Sep 13 2001
parent reply "Walter" <walter digitalmars.com> writes:
D is meant to be lightweight in its runtime library. As for multiple
versions, different features, that will be a problem because it uses static
binding. A C linker is used with it, so that's no problem <g>. Having a C
main will likely be a problem due to the garbage collector. It is not
compatible with C++.

For D in a kernel, you'll likely have to write code that doesn't rely on a
garbage collector. D should be compatible with COM.

-Walter


"Phil Brooks" <phil_brooks mentor.com> wrote in message
news:3BA1307C.2F10FCC9 mentor.com...
 What does that mean with regards to:

 running programs that contain D modules from multiple versions/different

    especially if the object model changes between the two?  what about

    GC?
 running programs that have a C mainline and are linked with the C linker.
 running programs that have a C++ mainline?
 running a D module in a kernel?
 running a D module as a COM inproc component?

 Walter wrote:
 D's runtime will not be a monolithic block like Java's is. It will be


 collection of modules like C's is. -Walter

 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA0DDBE.33B0FC98 mentor.com...
 What is D's runtime like?  Specifically, I am wondering what the

 that is to be linked into an application (written in D or C or C++ or

 has different runtime).

 Problems with the C++ Runtime
 -----------------------------
 It seems to me that the runtime is one of the biggest stumbling blocks



 there with C++ as
 opposed to C.  It means that you can't do pre-compiled components (a



 COM etc) in C++ without
 having some sort of guarantee about the characteristics of the



 It means that if you are
 writing a large C++ application with addins and reused libraries etc,



 have to get everyone to
 go to the new version of C++ in lock step (when the chain of providers

 is a big problem).

 It seems that Java went even farther in the direction of controlling



 runtime.  The nicest thing
 about C (and often a constraint that forces people to use C) is that



 runtime is generally
 compatible across different compiler versions and providers.  The



 is also scalable so that
 it can be easily constrained when it needs to be (i.e. Kernel, driver,

 the runtime most often by not using functions that aren't available).

 If D can solve this problem by keeping its entire runtime inside a

 other defined 'module' interfaces that only rely on a C runtime (a la

 inside any application that runs in a C runtime.  Certainly



 various features would
 apply.  Things like explicitly loading and initializing modules rather

 there come to mind.  I am sure that it would affect garbage collectors



 well.
 comments?



Sep 13 2001
parent reply Phil Brooks <phil_brooks mentor.com> writes:
What does it mean that it is not compatible with C++?  

Won't interoperate with C++ objects (fine)
Can't interface a C++ object with a D object through C api's or something
like inproc COM (not so good)?

Walter wrote:
 
 D is meant to be lightweight in its runtime library. As for multiple
 versions, different features, that will be a problem because it uses static
 binding. A C linker is used with it, so that's no problem <g>. Having a C
 main will likely be a problem due to the garbage collector. It is not
 compatible with C++.
 
 For D in a kernel, you'll likely have to write code that doesn't rely on a
 garbage collector. D should be compatible with COM.
 
 -Walter
 
 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA1307C.2F10FCC9 mentor.com...
 What does that mean with regards to:

 running programs that contain D modules from multiple versions/different

    especially if the object model changes between the two?  what about

    GC?
 running programs that have a C mainline and are linked with the C linker.
 running programs that have a C++ mainline?
 running a D module in a kernel?
 running a D module as a COM inproc component?

 Walter wrote:
 D's runtime will not be a monolithic block like Java's is. It will be


 collection of modules like C's is. -Walter

 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA0DDBE.33B0FC98 mentor.com...
 What is D's runtime like?  Specifically, I am wondering what the

 that is to be linked into an application (written in D or C or C++ or

 has different runtime).

 Problems with the C++ Runtime
 -----------------------------
 It seems to me that the runtime is one of the biggest stumbling blocks



 there with C++ as
 opposed to C.  It means that you can't do pre-compiled components (a



 COM etc) in C++ without
 having some sort of guarantee about the characteristics of the



 It means that if you are
 writing a large C++ application with addins and reused libraries etc,



 have to get everyone to
 go to the new version of C++ in lock step (when the chain of providers

 is a big problem).

 It seems that Java went even farther in the direction of controlling



 runtime.  The nicest thing
 about C (and often a constraint that forces people to use C) is that



 runtime is generally
 compatible across different compiler versions and providers.  The



 is also scalable so that
 it can be easily constrained when it needs to be (i.e. Kernel, driver,

 the runtime most often by not using functions that aren't available).

 If D can solve this problem by keeping its entire runtime inside a

 other defined 'module' interfaces that only rely on a C runtime (a la

 inside any application that runs in a C runtime.  Certainly



 various features would
 apply.  Things like explicitly loading and initializing modules rather

 there come to mind.  I am sure that it would affect garbage collectors



 well.
 comments?




Sep 13 2001
parent reply "Walter" <walter digitalmars.com> writes:
It won't interoperate with C++ mangled names, nor with C++ objects. It will
interoperate with C++ functions with the "C" linkage. -Walter

Phil Brooks wrote in message <3BA14AC1.A147DC5E mentor.com>...
What does it mean that it is not compatible with C++?

Won't interoperate with C++ objects (fine)
Can't interface a C++ object with a D object through C api's or something
like inproc COM (not so good)?

Walter wrote:
 D is meant to be lightweight in its runtime library. As for multiple
 versions, different features, that will be a problem because it uses


 binding. A C linker is used with it, so that's no problem <g>. Having a C
 main will likely be a problem due to the garbage collector. It is not
 compatible with C++.

 For D in a kernel, you'll likely have to write code that doesn't rely on


 garbage collector. D should be compatible with COM.

 -Walter

 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA1307C.2F10FCC9 mentor.com...
 What does that mean with regards to:

 running programs that contain D modules from multiple



 features
    especially if the object model changes between the two?  what about

    GC?
 running programs that have a C mainline and are linked with the C



 running programs that have a C++ mainline?
 running a D module in a kernel?
 running a D module as a COM inproc component?

 Walter wrote:
 D's runtime will not be a monolithic block like Java's is. It will be


 collection of modules like C's is. -Walter

 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA0DDBE.33B0FC98 mentor.com...
 What is D's runtime like?  Specifically, I am wondering what the

 that is to be linked into an application (written in D or C or C++





 another version of D that
 has different runtime).

 Problems with the C++ Runtime
 -----------------------------
 It seems to me that the runtime is one of the biggest stumbling





 out
 there with C++ as
 opposed to C.  It means that you can't do pre-compiled components





 la
 COM etc) in C++ without
 having some sort of guarantee about the characteristics of the



 It means that if you are
 writing a large C++ application with addins and reused libraries





 you
 have to get everyone to
 go to the new version of C++ in lock step (when the chain of





 spans several companies, this
 is a big problem).

 It seems that Java went even farther in the direction of





 the
 runtime.  The nicest thing
 about C (and often a constraint that forces people to use C) is





 the
 runtime is generally
 compatible across different compiler versions and providers.  The



 is also scalable so that
 it can be easily constrained when it needs to be (i.e. Kernel,





 embedded work constrain
 the runtime most often by not using functions that aren't





 If D can solve this problem by keeping its entire runtime inside a

 other defined 'module' interfaces that only rely on a C runtime (a





 COM), then D modules can run
 inside any application that runs in a C runtime.  Certainly



 various features would
 apply.  Things like explicitly loading and initializing modules





 than having them just be
 there come to mind.  I am sure that it would affect garbage





 as
 well.
 comments?





Sep 13 2001
parent reply Phil Brooks <phil_brooks mentor.com> writes:
I would think you should make this explicit in your documentation.
The way it looks now, one could assume that you simply can't mix
C++ and D at all.  In reality you can and the way you do it is
pretty much the same way that you do it for python, ruby, etc.
You have to go through some sort of "C" least common denominator.

As for COM, if you can do inproc COM objects in D, you should be able to 
do a C mainline the same way right?  You might have to make sure you have
an explicit way of initializing the D object (probably through shared library
init functions) the same way COM does.

Walter wrote:
 
 It won't interoperate with C++ mangled names, nor with C++ objects. It will
 interoperate with C++ functions with the "C" linkage. -Walter
 
 Phil Brooks wrote in message <3BA14AC1.A147DC5E mentor.com>...
What does it mean that it is not compatible with C++?

Won't interoperate with C++ objects (fine)
Can't interface a C++ object with a D object through C api's or something
like inproc COM (not so good)?

Walter wrote:
 D is meant to be lightweight in its runtime library. As for multiple
 versions, different features, that will be a problem because it uses


 binding. A C linker is used with it, so that's no problem <g>. Having a C
 main will likely be a problem due to the garbage collector. It is not
 compatible with C++.

 For D in a kernel, you'll likely have to write code that doesn't rely on


 garbage collector. D should be compatible with COM.

 -Walter

 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA1307C.2F10FCC9 mentor.com...
 What does that mean with regards to:

 running programs that contain D modules from multiple



 features
    especially if the object model changes between the two?  what about

    GC?
 running programs that have a C mainline and are linked with the C



 running programs that have a C++ mainline?
 running a D module in a kernel?
 running a D module as a COM inproc component?

 Walter wrote:
 D's runtime will not be a monolithic block like Java's is. It will be


 collection of modules like C's is. -Walter

 "Phil Brooks" <phil_brooks mentor.com> wrote in message
 news:3BA0DDBE.33B0FC98 mentor.com...
 What is D's runtime like?  Specifically, I am wondering what the

 that is to be linked into an application (written in D or C or C++





 another version of D that
 has different runtime).

 Problems with the C++ Runtime
 -----------------------------
 It seems to me that the runtime is one of the biggest stumbling





 out
 there with C++ as
 opposed to C.  It means that you can't do pre-compiled components





 la
 COM etc) in C++ without
 having some sort of guarantee about the characteristics of the



 It means that if you are
 writing a large C++ application with addins and reused libraries





 you
 have to get everyone to
 go to the new version of C++ in lock step (when the chain of





 spans several companies, this
 is a big problem).

 It seems that Java went even farther in the direction of





 the
 runtime.  The nicest thing
 about C (and often a constraint that forces people to use C) is





 the
 runtime is generally
 compatible across different compiler versions and providers.  The



 is also scalable so that
 it can be easily constrained when it needs to be (i.e. Kernel,





 embedded work constrain
 the runtime most often by not using functions that aren't





 If D can solve this problem by keeping its entire runtime inside a

 other defined 'module' interfaces that only rely on a C runtime (a





 COM), then D modules can run
 inside any application that runs in a C runtime.  Certainly



 various features would
 apply.  Things like explicitly loading and initializing modules





 than having them just be
 there come to mind.  I am sure that it would affect garbage





 as
 well.
 comments?






Sep 14 2001
next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
Phil Brooks wrote:

 I would think you should make this explicit in your documentation.
 The way it looks now, one could assume that you simply can't mix
 C++ and D at all.  In reality you can and the way you do it is
 pretty much the same way that you do it for python, ruby, etc.
 You have to go through some sort of "C" least common denominator.

Phil, it's simply technically impossible to provide a general clean C++ interface. The difference between C and C++ is that there's a normed linker interface on C level spreading over all languages, while every C++ compiler out there are incompatible to each other. You can normally not use a C++ library from compiler A with an application from compiler B. So how can a new language be cleanly binary compatible with C++ if even not the existing C++ compilers amoung each other are? You theoretically make it compatible with one of the compilers, but still are incompatbile with each others. Some compilers have an more abstract definition of the binary beeing a little more compatible, especially beeing compatible with itself from different versions, it's called ABI. gcc did learn an ABI only recently 3.0. So you can't even mix C++ code generated by gcc 2.91, 2.95.x or 3.0. - Axel
Sep 14 2001
parent reply Phil Brooks <phil_brooks mentor.com> writes:
You missed something.  I am only talking about access through a
"C" api in the same way that one would access a C++ object from
python or ruby.  You have to use lots of twine, bailing wire, and
bring everything down to a "C" api a la SWIG.  Walter says that 
D will interact with C++ through a C api.  I am only saying that 
he should make that clear in the documentation if it is true.

Now, if D has link time requirements that are at odds with using a
C++ linker, it is another story, but Walter seemed to indicate that
this was not an issue.

from an earlier post:
 It won't interoperate with C++ mangled names, nor with C++ objects. It will
 interoperate with C++ functions with the "C" linkage. -Walter


Axel Kittenberger wrote:
 
 Phil Brooks wrote:
 
 I would think you should make this explicit in your documentation.
 The way it looks now, one could assume that you simply can't mix
 C++ and D at all.  In reality you can and the way you do it is
 pretty much the same way that you do it for python, ruby, etc.
 You have to go through some sort of "C" least common denominator.

Phil, it's simply technically impossible to provide a general clean C++ interface. The difference between C and C++ is that there's a normed linker interface on C level spreading over all languages, while every C++ compiler out there are incompatible to each other. You can normally not use a C++ library from compiler A with an application from compiler B. So how can a new language be cleanly binary compatible with C++ if even not the existing C++ compilers amoung each other are? You theoretically make it compatible with one of the compilers, but still are incompatbile with each others. Some compilers have an more abstract definition of the binary beeing a little more compatible, especially beeing compatible with itself from different versions, it's called ABI. gcc did learn an ABI only recently 3.0. So you can't even mix C++ code generated by gcc 2.91, 2.95.x or 3.0. - Axel

Sep 14 2001
next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 Walter says that
 D will interact with C++ through a C api.  I am only saying that
 he should make that clear in the documentation if it is true.

Well saying you support C linkage should be enough, beeing able to connect in C linkage means you can connect also to all other language which support also C linkage, C++ in example does with extern "C" {}- with this suggestion you should then also have to explitly count up all other languages that also support C linkage which includes also Assembler, I think Pascal supported it also, my language dtone, and even script languages like Python, etc. this could be an nearly infinity list if tyring to be complete. - Axel
Sep 14 2001
parent "Walter" <walter digitalmars.com> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9nurbp$icv$1 digitaldaemon.com...
 with this suggestion you should then also have to explitly count up all
 other languages that also support C linkage which includes also Assembler,
 I think Pascal supported it also, my language dtone, and even script
 languages like Python, etc. this could be an nearly infinity list if

 to be complete.

It should be possible to hook D functions up to Python by specifying C linkage: extern (C) { void my_interface_to_python(int arg) { ... } }
Nov 28 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Phil Brooks" <phil_brooks mentor.com> wrote in message
news:3BA2585B.291B02ED mentor.com...
 Now, if D has link time requirements that are at odds with using a
 C++ linker, it is another story, but Walter seemed to indicate that
 this was not an issue.

While it's certainly possible to write a D-aware linker that will provide cool optimizations, I've been careful to specify the language so that an ordinary C linker will work. This goes back to the principle of making it easy to implement the language <g>.
Nov 28 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Phil Brooks" <phil_brooks mentor.com> wrote in message
news:3BA21CE1.E49B18B2 mentor.com...
 I would think you should make this explicit in your documentation.
 The way it looks now, one could assume that you simply can't mix
 C++ and D at all.  In reality you can and the way you do it is
 pretty much the same way that you do it for python, ruby, etc.
 You have to go through some sort of "C" least common denominator.

The D runtime, in its likely incarnation, will be layered on top of the C runtime. This ensures that you can link in C modules. In addition, at least in my implementation, the C++ runtime is also supported. So, while D cannot call C++ functions directly, you can mix the two by writing C wrappers around the C++ functions. This, of course, is necessary since the initial bootstrap garbage collector is written in C++ <g>. I just finished making the static constructors/destructors work in D in a manner that does not conflict with C or C++, so they should all work together in one program without stomping each other. One nice fallout of D's static constructor/destructor implementation is no more worries about the order dependency - it's taken care of automatically.
Nov 28 2001