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.

 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

 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

 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

 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

 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

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

 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


 bit patient with me.

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

 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

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

 parallel threads?

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

 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

 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

 a integrator of different COM objects.

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


 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.

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

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

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

 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.

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

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

 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