• Phil Brooks <phil_brooks mentor.com> Sep 13 2001
• "Walter" <walter digitalmars.com> Sep 13 2001
• Phil Brooks <phil_brooks mentor.com> Sep 13 2001
• "Walter" <walter digitalmars.com> Sep 13 2001
• Phil Brooks <phil_brooks mentor.com> Sep 13 2001
• "Walter" <walter digitalmars.com> Sep 13 2001
• Phil Brooks <phil_brooks mentor.com> Sep 14 2001
• Axel Kittenberger <axel dtone.org> Sep 14 2001
• Phil Brooks <phil_brooks mentor.com> Sep 14 2001
• Axel Kittenberger <axel dtone.org> Sep 14 2001
• "Walter" <walter digitalmars.com> Nov 28 2001
• "Walter" <walter digitalmars.com> Nov 28 2001
• "Walter" <walter digitalmars.com> Nov 28 2001

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?

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

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?

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

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?

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

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?

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

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

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

"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)
        {
            ...
        }
    }

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

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