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


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 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


 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 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


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


 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 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


 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


 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:
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




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

 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


 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 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




 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

 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


 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 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


tyring

 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