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

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

"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

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

"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

> 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

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