www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Development environment (WAS: generative programming and debugging)

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I've yet to see a single worthwhile IDE for D.
I think it would be a great idea to have a standard reference IDE
(just as DMD is the standard reference compiler).
These things would be so useful:
Inline compile-time ddoc and mixin views would make development
process so much easier.
Inline compile-time non-ctfe-able code highliting.
Automatic import detector, based on visible import paths.

On Wed, Oct 19, 2011 at 3:32 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-19 13:21, Gor Gyolchanyan wrote:

 This is cool. Unfortunately, descent is a big pain to use for everything
 else.


 Well, it might be worth to just start up eclipse once in a while for case=


s

 like these.


 On Wed, Oct 19, 2011 at 3:12 PM, Jacob Carlborg<doob me.com> =A0wrote:

 On 2011-10-19 11:07, Gor Gyolchanyan wrote:

 Do anybody know a good way to (statically) debug a generated code?
 Currently it takes lots of effort to determine the place, where the
 code is being incorrectly generated.


 The Eclipse plugin Descent has support for compile time debugging. It
 also
 have a compile time view which shows the result of string mixins and
 template mixins.

 --
 /Jacob Carlborg






 --
 /Jacob Carlborg
Oct 19 2011
next sibling parent reply Mirko Pilger <pilger cymotec.de> writes:
 I've yet to see a single worthwhile IDE for D.


http://dsource.org/projects/visuald
Oct 19 2011
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Mirko Pilger wrote:

 I've yet to see a single worthwhile IDE for D.


 http://dsource.org/projects/visuald


I'm using it too. I wish the author would move the source repository to 
github. I think it may then attract more contributors.
Oct 19 2011
parent reply Jude Young <10equals2 gmail.com> writes:
Is Geany not a viable alternative?

It seems to support everything that I need out of the box.

what do you need that it doesn't do?
half asking to see if geany would be useful, half to see what tools other
people use.


Mirko Pilger wrote:

 I've yet to see a single worthwhile IDE for D.









 Oct 19 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-10-20 02:34, Jude Young wrote:

 Is Geany not a viable alternative?

 It seems to support everything that I need out of the box.

 what do you need that it doesn't do?
 half asking to see if geany would be useful, half to see what tools
 other people use.


     Mirko Pilger wrote:

             I've yet to see a single worthwhile IDE for D.


Not exactly sure what it does but:

* show syntax errors
* show semantic errors
* show formatted/generated ddoc on hover
* go to definition
* show result of auto, string and template mixins
* autocompletion, something intelligent
* generate ddocs
* code formatting
* building
* outline

-- 
/Jacob Carlborg



 Oct 19 2011



  parent reply Jude Young <10equals2 gmail.com>  writes:


Well, I guess I'm just not used to all the fancy features.
=P
it does not show syntax errors. I did the lazy mans version, set a button
set to compile the current file without outputting anything.
It just shows errors.
no semantic errors, same as above
It doesn't handle ddoc, I wish it did.
It does handle go to definition
no mixin support that I know of
I know it does autocompletion, probably not as smart as you want though.
it'll autocomplete any declared or used var or function, if you type the
first four letters, but it seems to be only for things in the current file.
it other words it won't suggest things in files that you import.
it handles building through makefiles (ie, write the file yourself and
there's a nice button you can push)
It does have an 'scribble' pane, but it's more like a scratchpad you can
write notes on, so thats far less than optimal.

It also integrates with gdb, but it doesn't let you specify which version.
(personal irk I had to work around)


I tried DDT, but that was... just not for me.
...And now I'm checking out Code::Blocks again 'cause I can't remember why I
disliked it..
No terminal.  That was the reason.


Not exactly sure what it does but:

 * show syntax errors
 * show semantic errors
 * show formatted/generated ddoc on hover
 * go to definition
 * show result of auto, string and template mixins
 * autocompletion, something intelligent
 * generate ddocs
 * code formatting
 * building
 * outline

 --
 /Jacob Carlborg





 Oct 20 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-10-20 09:18, Jude Young wrote:

 Well, I guess I'm just not used to all the fancy features.
 =P
 it does not show syntax errors. I did the lazy mans version, set a
 button set to compile the current file without outputting anything.
 It just shows errors.
 no semantic errors, same as above
 It doesn't handle ddoc, I wish it did.
 It does handle go to definition
 no mixin support that I know of
 I know it does autocompletion, probably not as smart as you want though.
 it'll autocomplete any declared or used var or function, if you type the
 first four letters, but it seems to be only for things in the current
 file. it other words it won't suggest things in files that you import.
 it handles building through makefiles (ie, write the file yourself and
 there's a nice button you can push)
 It does have an 'scribble' pane, but it's more like a scratchpad you can
 write notes on, so thats far less than optimal.


That's basically what I can do now with TextMate.

-- 
/Jacob Carlborg



 Oct 20 2011



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-10-19 13:40, Gor Gyolchanyan wrote:

 I've yet to see a single worthwhile IDE for D.
 I think it would be a great idea to have a standard reference IDE
 (just as DMD is the standard reference compiler).
 These things would be so useful:
 Inline compile-time ddoc and mixin views would make development
 process so much easier.
 Inline compile-time non-ctfe-able code highliting.
 Automatic import detector, based on visible import paths.


Yeah, that would be really nice.

-- 
/Jacob Carlborg



 Oct 19 2011



prev sibling  parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com>:


 I've yet to see a single worthwhile IDE for D.
 I think it would be a great idea to have a standard reference IDE
 (just as DMD is the standard reference compiler).
 These things would be so useful:
 Inline compile-time ddoc and mixin views would make development
 process so much easier.
 Inline compile-time non-ctfe-able code highliting.
 Automatic import detector, based on visible import paths.


Seems like I'm not the only one who thought of an IDE recently that is  
fast and can give hints on functions. Except I thought of highlighting  
pureness, safeness and the like by changing the background color slightly.
The next thing is all the features of Eclipse that have to do with the  
code you write or running / debugging. Like regex search and replace,  
finding references to methods/fields, refactoring, code templates, class  
outlines, type search, jump to declaration etc.
A difficulty for IDEs seems to be the complexity of D's CTFE and return  
type inference. DDT for example cannot give auto-completion hints on auto  
variables. That needs to be addressed.
I'd also like very much a way to set up multiple targets for a project:
- typical debug build
- typical release build
- unit test build
- external launcher (i.e. dump MySQL table structure and generate D import)
- run another program that uses my program (through IPC, as a debuggee)
- run a DLL host using my library (also debuggable)
- cross-compiling (currently x86-32/-64 for DMD)

Especially a D frontend written in D would be a good start for a  
cross-platform IDE and other derived work. Ideally I think it should not  
be an external program or parse everything in one step. It could be a lot  
faster if it worked closely together with the editor itself and only  
updated the syntax tree where the user edited code. Changes in  
templates/functions/classes have to be propagated to the users of that  
code.



 Oct 19 2011



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


yeah. that sounds great.

On Wed, Oct 19, 2011 at 11:35 PM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I've yet to see a single worthwhile IDE for D.
 I think it would be a great idea to have a standard reference IDE
 (just as DMD is the standard reference compiler).
 These things would be so useful:
 Inline compile-time ddoc and mixin views would make development
 process so much easier.
 Inline compile-time non-ctfe-able code highliting.
 Automatic import detector, based on visible import paths.


 Seems like I'm not the only one who thought of an IDE recently that is fast
 and can give hints on functions. Except I thought of highlighting pureness,
 safeness and the like by changing the background color slightly.
 The next thing is all the features of Eclipse that have to do with the code
 you write or running / debugging. Like regex search and replace, finding
 references to methods/fields, refactoring, code templates, class outlines,
 type search, jump to declaration etc.
 A difficulty for IDEs seems to be the complexity of D's CTFE and return type
 inference. DDT for example cannot give auto-completion hints on auto
 variables. That needs to be addressed.
 I'd also like very much a way to set up multiple targets for a project:
 - typical debug build
 - typical release build
 - unit test build
 - external launcher (i.e. dump MySQL table structure and generate D import)
 - run another program that uses my program (through IPC, as a debuggee)
 - run a DLL host using my library (also debuggable)
 - cross-compiling (currently x86-32/-64 for DMD)

 Especially a D frontend written in D would be a good start for a
 cross-platform IDE and other derived work. Ideally I think it should not be
 an external program or parse everything in one step. It could be a lot
 faster if it worked closely together with the editor itself and only updated
 the syntax tree where the user edited code. Changes in
 templates/functions/classes have to be propagated to the users of that code.





 Oct 19 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-10-19 21:35, Marco Leise wrote:

 Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I've yet to see a single worthwhile IDE for D.
 I think it would be a great idea to have a standard reference IDE
 (just as DMD is the standard reference compiler).
 These things would be so useful:
 Inline compile-time ddoc and mixin views would make development
 process so much easier.
 Inline compile-time non-ctfe-able code highliting.
 Automatic import detector, based on visible import paths.


 Seems like I'm not the only one who thought of an IDE recently that is
 fast and can give hints on functions. Except I thought of highlighting
 pureness, safeness and the like by changing the background color slightly.
 The next thing is all the features of Eclipse that have to do with the
 code you write or running / debugging. Like regex search and replace,
 finding references to methods/fields, refactoring, code templates, class
 outlines, type search, jump to declaration etc.
 A difficulty for IDEs seems to be the complexity of D's CTFE and return
 type inference. DDT for example cannot give auto-completion hints on
 auto variables. That needs to be addressed.
 I'd also like very much a way to set up multiple targets for a project:
 - typical debug build
 - typical release build
 - unit test build
 - external launcher (i.e. dump MySQL table structure and generate D import)
 - run another program that uses my program (through IPC, as a debuggee)
 - run a DLL host using my library (also debuggable)
 - cross-compiling (currently x86-32/-64 for DMD)

 Especially a D frontend written in D would be a good start for a
 cross-platform IDE and other derived work. Ideally I think it should not
 be an external program or parse everything in one step. It could be a
 lot faster if it worked closely together with the editor itself and only
 updated the syntax tree where the user edited code. Changes in
 templates/functions/classes have to be propagated to the users of that
 code.


Yet again, what's needed is a D compiler (or at least a front end) that 
can be used as a library.

-- 
/Jacob Carlborg



 Oct 19 2011



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Not a compiler (we have 3), only a front-end. Preferably in D itself
and preferably as modular as possible (e.g. not everyone needs the
semantic parser).
Provided a good D front-end in D it'll be very easy to make a great
IDE, even if it's GUI is bad.

On Thu, Oct 20, 2011 at 10:20 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-19 21:35, Marco Leise wrote:

 Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I've yet to see a single worthwhile IDE for D.
 I think it would be a great idea to have a standard reference IDE
 (just as DMD is the standard reference compiler).
 These things would be so useful:
 Inline compile-time ddoc and mixin views would make development
 process so much easier.
 Inline compile-time non-ctfe-able code highliting.
 Automatic import detector, based on visible import paths.


 Seems like I'm not the only one who thought of an IDE recently that is
 fast and can give hints on functions. Except I thought of highlighting
 pureness, safeness and the like by changing the background color slightly.
 The next thing is all the features of Eclipse that have to do with the
 code you write or running / debugging. Like regex search and replace,
 finding references to methods/fields, refactoring, code templates, class
 outlines, type search, jump to declaration etc.
 A difficulty for IDEs seems to be the complexity of D's CTFE and return
 type inference. DDT for example cannot give auto-completion hints on
 auto variables. That needs to be addressed.
 I'd also like very much a way to set up multiple targets for a project:
 - typical debug build
 - typical release build
 - unit test build
 - external launcher (i.e. dump MySQL table structure and generate D
 import)
 - run another program that uses my program (through IPC, as a debuggee)
 - run a DLL host using my library (also debuggable)
 - cross-compiling (currently x86-32/-64 for DMD)

 Especially a D frontend written in D would be a good start for a
 cross-platform IDE and other derived work. Ideally I think it should not
 be an external program or parse everything in one step. It could be a
 lot faster if it worked closely together with the editor itself and only
 updated the syntax tree where the user edited code. Changes in
 templates/functions/classes have to be propagated to the users of that
 code.


 Yet again, what's needed is a D compiler (or at least a front end) that can
 be used as a library.

 --
 /Jacob Carlborg





 Oct 20 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


Preferably, at least one of, these compilers should use the front end as 
well.

-- 
/Jacob Carlborg



 Oct 20 2011



 next sibling parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


Definitely. It would be a standardized good-practice advice for all
compilers to use the standard D front-end.
This will ensure absence of non-standard shenanigans with the
front-end, preventing D from inheriting one of the biggest mistakes of
C/C++: non-standard extensions.
The pragma statements will provide a way to specify compiler-specific
features. Note, that compiler-specific features are not the same as
non-standard extensions, at least because they all follow the same
syntactic rules.

On Thu, Oct 20, 2011 at 3:11 PM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front end as
 well.

 --
 /Jacob Carlborg





 Oct 20 2011



prev sibling  parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front end as  
 well.


I don't see that happening: A D front end and a C++ backend. Perhaps GCC  
becomes the stadard D compiler and DMD is translated to D using that ;)



 Oct 20 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-10-20 22:29, Marco Leise wrote:

 Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front end
 as well.


 I don't see that happening: A D front end and a C++ backend. Perhaps GCC
 becomes the stadard D compiler and DMD is translated to D using that ;)


It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd

-- 
/Jacob Carlborg



 Oct 20 2011



  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


I wouldn't call it D. It looks like C, which smells like D. But the
point is good. It's possible to make a C facade to use a C back-end.

On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-20 22:29, Marco Leise wrote:

 Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front end
 as well.


 I don't see that happening: A D front end and a C++ backend. Perhaps GCC
 becomes the stadard D compiler and DMD is translated to D using that ;)


 It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd

 --
 /Jacob Carlborg





 Oct 21 2011



 next sibling parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com>:


 I wouldn't call it D. It looks like C, which smells like D. But the
 point is good. It's possible to make a C facade to use a C back-end.

 On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-20 22:29, Marco Leise wrote:

 Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front end
 as well.


 I don't see that happening: A D front end and a C++ backend. Perhaps  
 GCC
 becomes the stadard D compiler and DMD is translated to D using that ;)


 It is possible, have a look at DDMD:  
 http://www.dsource.org/projects/ddmd

 --
 /Jacob Carlborg




I said "D frontend" and "C++ backend", not "D backend". And "one of these  
[3] compilers" clearly referred to the C++ ones DMD, LDC and GDC. But the  
point is, that a frontend exists, that compiles as D code and can be the  
base for a library. Either for continued development on DDMD or an IDE or  
other tools that need to understand D code, like a online source code  
browser.



 Oct 21 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-10-21 10:07, Marco Leise wrote:

 Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I wouldn't call it D. It looks like C, which smells like D. But the
 point is good. It's possible to make a C facade to use a C back-end.

 On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-20 22:29, Marco Leise wrote:

 Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front end
 as well.


 I don't see that happening: A D front end and a C++ backend. Perhaps
 GCC
 becomes the stadard D compiler and DMD is translated to D using that ;)


 It is possible, have a look at DDMD:
 http://www.dsource.org/projects/ddmd

 --
 /Jacob Carlborg




 I said "D frontend" and "C++ backend", not "D backend". And "one of
 these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC.
 But the point is, that a frontend exists, that compiles as D code and
 can be the base for a library. Either for continued development on DDMD
 or an IDE or other tools that need to understand D code, like a online
 source code browser.


DDMD uses the C++ DMD backend.

-- 
/Jacob Carlborg



 Oct 21 2011



  parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 21.10.2011, 13:50 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-21 10:07, Marco Leise wrote:

 Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I wouldn't call it D. It looks like C, which smells like D. But the
 point is good. It's possible to make a C facade to use a C back-end.

 On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-20 22:29, Marco Leise wrote:

 Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D  
 itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front  
 end
 as well.


 I don't see that happening: A D front end and a C++ backend. Perhaps
 GCC
 becomes the stadard D compiler and DMD is translated to D using that  
 ;)


 It is possible, have a look at DDMD:
 http://www.dsource.org/projects/ddmd

 --
 /Jacob Carlborg




 I said "D frontend" and "C++ backend", not "D backend". And "one of
 these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC.
 But the point is, that a frontend exists, that compiles as D code and
 can be the base for a library. Either for continued development on DDMD
 or an IDE or other tools that need to understand D code, like a online
 source code browser.


 DDMD uses the C++ DMD backend.


Oh ok, when I clicked on "backend" I saw a long list of *.d files. I  
didn't know the compatibility between D and C++ was that good :)



 Oct 21 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-10-21 20:56, Marco Leise wrote:

 Am 21.10.2011, 13:50 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-21 10:07, Marco Leise wrote:

 Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I wouldn't call it D. It looks like C, which smells like D. But the
 point is good. It's possible to make a C facade to use a C back-end.

 On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:

 On 2011-10-20 22:29, Marco Leise wrote:

 Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2011-10-20 11:38, Gor Gyolchanyan wrote:

 Not a compiler (we have 3), only a front-end. Preferably in D
 itself
 and preferably as modular as possible (e.g. not everyone needs the
 semantic parser).
 Provided a good D front-end in D it'll be very easy to make a great
 IDE, even if it's GUI is bad.


 Preferably, at least one of, these compilers should use the front
 end
 as well.


 I don't see that happening: A D front end and a C++ backend. Perhaps
 GCC
 becomes the stadard D compiler and DMD is translated to D using
 that ;)


 It is possible, have a look at DDMD:
 http://www.dsource.org/projects/ddmd

 --
 /Jacob Carlborg




 I said "D frontend" and "C++ backend", not "D backend". And "one of
 these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC.
 But the point is, that a frontend exists, that compiles as D code and
 can be the base for a library. Either for continued development on DDMD
 or an IDE or other tools that need to understand D code, like a online
 source code browser.


 DDMD uses the C++ DMD backend.


 Oh ok, when I clicked on "backend" I saw a long list of *.d files. I
 didn't know the compatibility between D and C++ was that good :)


I think it's bindings to the C++ backend and other stuff. Have a look at 
the C++ backend and you can see it's not the C++ backend ported to D: 
https://github.com/D-Programming-Language/dmd/tree/master/src/backend

-- 
/Jacob Carlborg



 Oct 22 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-10-21 09:22, Gor Gyolchanyan wrote:

 I wouldn't call it D. It looks like C, which smells like D. But the
 point is good. It's possible to make a C facade to use a C back-end.


As a fist step DDMD is only converted to D with minimal changes. The 
next step is to make it more D-like when you know everything is working.

-- 
/Jacob Carlborg



 Oct 21 2011