www.digitalmars.com         C & C++   DMDScript  

D - D's development roadmap and production usage?

reply "Robert M. Münch" <robert.muench robertmuench.de> writes:
Hi, I'm following the D story only for some weeks but I really like it. It's
c-ish enough and has some real nice features. But hey, why I'm telling you
all know this. My questions are:

- When could I start using D in a realy (customer) project not having a big
risk on the compiler side?
- What's the roadmap for the development of D?
- What's mostly missing for real project use?
- What's the best way to introduce D to projects? IMO one of the best things
is that it can be used with C (C++?) compiled code. Is this correct?
- How hard is the learning curve for D? Is it still a heavy moving target or
mostly stable?

If I would start to code a DLL (btw: can D create a DLL?) today, I would use
D to do it and no longer C/C++ but I'm not sure how big the risk is in using
D and not a long-known C/C++ compiler.

--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax   : +49 (0)721 8408 9112
Web   : http://www.robertmuench.de
Jan 26 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Robert M. Münch" <robert.muench robertmuench.de> wrote in message
news:a2ub6f$bnc$1 digitaldaemon.com...

 Hi, I'm following the D story only for some weeks but I really like it.


It's

 c-ish enough and has some real nice features. But hey, why I'm telling you
 all know this. My questions are:

 - When could I start using D in a realy (customer) project not having a


big

 risk on the compiler side?


You can start now if you're willing to be tolerant of compiler bugs and a
bit patient with me.


 - What's the roadmap for the development of D?


Finish the win32 version, then start working on dfront (D to C translator).


 - What's mostly missing for real project use?


Polish <g>. The alpha notes list the major issues.


 - What's the best way to introduce D to projects? IMO one of the best


things

 is that it can be used with C (C++?) compiled code. Is this correct?


It's directly linkable to C code, not C++. I have gotten COM to work, so you
can hook it up with COM objects written in any language.


 - How hard is the learning curve for D? Is it still a heavy moving target


or

 mostly stable?


I think it's pretty stable.



 If I would start to code a DLL (btw: can D create a DLL?)


Yes. I'll be uploading an update soon with some instructions on how to do
it.



 today, I would use
 D to do it and no longer C/C++ but I'm not sure how big the risk is in


using

 D and not a long-known C/C++ compiler.


Worst case, D is similar enough to C++ that it can be hand translated to C++
with some swearing, but you won't lose your project. I've converted major
Java code projects to C++, so I can attest that such things are doable (and
D would be much easier than Java to convert).
Jan 26 2002
parent reply "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:a2uhbo$fiq$2 digitaldaemon.com...


 You can start now if you're willing to be tolerant of compiler bugs and a
 bit patient with me.


Hi, well no problem ;-) Just wanted to know if those bugs will hit one early
or even big D projects are possible and only the fanciest features are
dangerous...


 Finish the win32 version, then start working on dfront (D to C


translator).

Ok, by finishing I assume language/feature completness, right? So things
like templates etc. are done before starting Dfront or will these become two
parallel threads?


 It's directly linkable to C code, not C++. I have gotten COM to work, so


you

 can hook it up with COM objects written in any language.


Ok, linking to C code is good! I have done all my C++ stuff where I used
VC++ in a way that the external interface was C callable and the rest could
use VC++ name mangeling. The COM stuff is interesting. Is it released? If
not when can we expect to see it? IMO it's a good way to start and use D as
a integrator of different COM objects.


 Yes. I'll be uploading an update soon with some instructions on how to do
 it.


Great! Same as with COM. If I can develop a simple stand alone DLL with D
and use it somewhere else, this gives a great opportunity to try doing a
task with D. Thanks for the information.

--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax   : +49 (0)721 8408 9112
Web   : http://www.robertmuench.de
Jan 27 2002
parent reply "Walter" <walter digitalmars.com> writes:
The COM support is now uploaded.

www.digitalmars.com/d/windows.html



"Robert M. Münch" <robert.muench robertmuench.de> wrote in message
news:a30nl6$1rjj$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> schrieb im Newsbeitrag
 news:a2uhbo$fiq$2 digitaldaemon.com...


 You can start now if you're willing to be tolerant of compiler bugs and




a

 bit patient with me.


 Hi, well no problem ;-) Just wanted to know if those bugs will hit one


early

 or even big D projects are possible and only the fanciest features are
 dangerous...


 Finish the win32 version, then start working on dfront (D to C


 translator).

 Ok, by finishing I assume language/feature completness, right? So things
 like templates etc. are done before starting Dfront or will these become


two

 parallel threads?


 It's directly linkable to C code, not C++. I have gotten COM to work, so


 you

 can hook it up with COM objects written in any language.


 Ok, linking to C code is good! I have done all my C++ stuff where I used
 VC++ in a way that the external interface was C callable and the rest


could

 use VC++ name mangeling. The COM stuff is interesting. Is it released? If
 not when can we expect to see it? IMO it's a good way to start and use D


as

 a integrator of different COM objects.


 Yes. I'll be uploading an update soon with some instructions on how to




do

 it.


 Great! Same as with COM. If I can develop a simple stand alone DLL with D
 and use it somewhere else, this gives a great opportunity to try doing a
 task with D. Thanks for the information.

 --
 Robert M. Münch
 IT & Management Freelancer
 Mobile: +49 (0)177 2452 802
 Fax   : +49 (0)721 8408 9112
 Web   : http://www.robertmuench.de
Jan 27 2002
parent reply "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:a31ir4$2caf$4 digitaldaemon.com...

 The COM support is now uploaded.
 www.digitalmars.com/d/windows.html


Hi, great I'm going to try it out! Just read the page I have one comment:

Calling Conventions/export: "If no function body is given, it's imported. If
a function body is given, it's exported."

Isn't this a bit strange? Using export without a function body results in an
import? Howabout using a more generic word for this like: extern? This would
be OK to be used for import and exports.

Is the DEF file really needed? IMO the exports can be recognized from the
source code, so no need to specify them twice.

--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax   : +49 (0)721 8408 9112
Web   : http://www.robertmuench.de
Jan 28 2002
next sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
 Calling Conventions/export: "If no function body is given, it's imported.


If

 a function body is given, it's exported."

 Isn't this a bit strange? Using export without a function body results in


an

 import? Howabout using a more generic word for this like: extern? This


would

 be OK to be used for import and exports.


I'm with you on this.


 Is the DEF file really needed? IMO the exports can be recognized from the
 source code, so no need to specify them twice.



DEF files are (somewhat) useful for a few other things, such as specifying
the ordinal index of the function (for when callers access DLL functions by
ordinal).

I'd like to get rid of them too, but if you do, I'm sure somebody will
scream.  Better make sure you have all the functionality covered first, but
then D will be very Windows-centric.  It's a no win situation when you dance
with the devil.

Sean
Jan 28 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Robert M. Münch" <robert.muench robertmuench.de> wrote in message
news:a33hrp$lig$1 digitaldaemon.com...

 Calling Conventions/export: "If no function body is given, it's imported.


If

 a function body is given, it's exported."
 Isn't this a bit strange? Using export without a function body results in


an

 import? Howabout using a more generic word for this like: extern? This


would

 be OK to be used for import and exports.


Consider:

    void foo(int x);

There's no definition for it, so it's implicitly extern. Given:

    export void foo(int x);

there's no ambiguity about dllimport'ing it. Given:

    export void foo(int x)
    {
        ...
    }

That's clearly a definition, and so is dllexport'ed.


 Is the DEF file really needed? IMO the exports can be recognized from the
 source code, so no need to specify them twice.


The DEF file isn't needed for exported functions, but can be useful for
specifying ordinals, changing the name of exports, special things with
segments, etc.
Jan 28 2002