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?

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?

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?

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?

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?

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?

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?

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

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

> 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