In article <e4aohg$2st8$1@digitaldaemon.com>, Dave says...
>
>Chad J wrote:
>> Walter Bright wrote:
>>> Chad J wrote:
>>>
>>>> I have even more trouble believing that current D compilers shouldn't support C plus plus integration just because it might make C plus plus compilation a required capability of a D compiler.
>>>
>>> Take a look inside one of the STL header files - how can one access it without being a C compiler?
>> 
>> Agreed.  You need C plus plus compilation ability to use C plus plus headers as they are.
>> 
>> What I'm talking about though is this notion that DMD supporting C plus
>> plus compilation somehow implies that every D compiler created from then
>> on will also support C plus plus compilation.  I don't agree with that.
>>  I think it reeks of fallacy.
>> 
>> I'd say that C plus plus support for the first couple D compilers would make D more likely to become mainstream or become mainstream faster. The objective is no different than that of an external tool that translates C headers into D headers, but it may be easier to do since it puts a fully functional C plus plus parser at your disposal (at least I think it does).  Just make sure to clearly mark the C plus plus capabilities as something DMD specific, a bundled tool really, and everything should be dandy.  Same goes for GDC if it were to add such a faculty.
>>
>
>There seems to be an assumption that converting C++ to D is a straight-forward thing to do, even if you have a C++ front-end at your disposal. Heck, IIRC CFront was eventualy abandoned in part because C++ became complicated enough that a C++ to C converter was barely feasible any longer (beside the obvious other advantages of native C++ compilers).
>
>My point is that really what your suggesting is another whole compiler here...
>
>And if you don't have a compiler handy, there are quite a few open source and commercial "compiler-compilers" out there, but I've never heard of a commercial compiler that has been developed with one of them. And, I've rarely heard of any other tools like syntax high-lighters, class browsers and such that are developed that way, either. There has been quit a few D parser projects started using tools like Antlr, and they seem to get 90% there, but then I suspect the developer runs into cases where those tools aren't quite flexible enough and/or create very bloated and slow compilers.
>
>All this leads me to conclude that what you're asking for would require another hand-made compiler to do properly, and for dubious gain since the code created would just be C++ disguised as D and wouldn't take advantage of a host of D's other features.

There are several full parsers out there available today.  The GCC frontend for C++ is one.. it's used in GCC-XML.   Another would be the elsa parser, which seems to do a fairly good job on our massive codebase, though we do have to macro define several linux and microsoft specific additions.

Parsing is not the most difficult aspect, it's actually providing in-language facilities in D to utilize the constructs in Cpp.  For this facility, you would generally need to integrate a Cpp compiler into the D compiler.  Sure this would be an ugly hack, but such is life.  The advantage would be that the D compiler could call the Cpp compiler to instantiate cpp code it needed to integrate Cpp constructs.

The syntax in D for accessing Cpp classes, macros, and templates need not be particularly elegant, just not needlessly difficult.  You wouldn't need to have D pretend that a C++ class was a D class, or have D conform to C++ syntax... merely make it possible to instantiate classes, templates, use macros, and do what you need to do with an external library without having to re-code it or spend weeks creating wrappers.

If you would like to see how such a convergence would work, take a look at "managed C++".  With .NET, microsoft faced the same problem.  How do you get people to migrate to .NET when they have large quantities of code written in C and C++?  Microsofts answer was the "IJW" philosophy.  You can take any C/C++ code and simply compile it in .NET, then add .NET specific constructs to make the C++ code play nice in the .NET world.  You do not need to recode your existing C++ libraries in C#.  This is not really an apples to apples comparison, because Microsoft didn't extend C# to parse C or Cpp headers (which it should have in my opinion), but it did make Cpp play nice with .NET and that was very important for the adoption of .NET.

In article <e4an5r$2reb$1@digitaldaemon.com>, Walter Bright says...
>
>Ben Cooley wrote:
>> I would suggest that a standard C and C plus plus compiler and parser be integrated into D, and that it not "convert" files, but just parse them directly without modification.  If the equivalent C or C plus plus construct is not available in D, D should provide a way of accessing that construct as a foreign object.
>
>That is a good idea, and I've toyed with it. The problem with it is that it pulls the rug out from other implementations of D. People won't want to use them because they'll expect the dmd 'extension' of being able to parse .h files directly.

Hmmm... well I can certainly sympathize because I don't want to use DMD without that capability either. ;-)  Truth is I can't.

But my advice to those other implementations would be to just get cracking.  The GCC implementation wouldn't have too much trouble  For the others there are a variety of free versions of full CPP compilers out there.

An alternative would be to compile C and CPP headers to a C/CPP pcode format which could be accessed by the D cpp interface.  Part of the D compiler would comprehend certain foreign cpp constructs as part of the basic D compiler, while a simpler external parsing tool would actually generate a cpp pcode file.

In article <e4adug$2h9k$1@digitaldaemon.com>, jcc7 says...
>In article <e4aac7$2dm3$1@digitaldaemon.com>, sailormoontw says...
>>For example, about the DirectX Wrapper what I can find the latest one is one >in a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, I've
>>searched the D Forum and there seems no newer version of DirectX wrapper. I
>>downloaded the hdk library, and when I linked the library with its sample >codes, the optlink fails with a runtime exception.
>Does it provide an error message? Please include that information.
>Are you trying to use a Microsoft-style .lib file? You'd probably need to
>convert the MS (COFF format) .lib to the OMF format that Digital Mars tools
>need. Fortunately, there's a tool that can help.
I See, but what I mentioned abou the imcompatible library isn't the DirectX one that for C/C++ to use, it's http://hp.vector.co.jp/authors/VA031566/hdklib.zip, a D DirectX Wrapper Library, which was generated in 2005 Jan, and now even I fixed some codes, it still cannot be used. I think I need to spend more time if I want to use the code.

Ben Cooley wrote:
> In article <e4an5r$2reb$1@digitaldaemon.com>, Walter Bright says...
>> Ben Cooley wrote:
>>> I would suggest that a standard C and C plus plus compiler and parser be
>>> integrated into D, and that it not "convert" files, but just parse them directly
>>> without modification.  If the equivalent C or C plus plus construct is not
>>> available in D, D should provide a way of accessing that construct as a foreign
>>> object.  
>> That is a good idea, and I've toyed with it. The problem with it is that it pulls the rug out from other implementations of D. People won't want to use them because they'll expect the dmd 'extension' of being able to parse .h files directly.
> 
> Hmmm... well I can certainly sympathize because I don't want to use DMD without
> that capability either. ;-)  Truth is I can't. 
> 
> But my advice to those other implementations would be to just get cracking.  The
> GCC implementation wouldn't have too much trouble  For the others there are a
> variety of free versions of full CPP compilers out there.

g++ is the only free full C++ compiler out there.

> An alternative would be to compile C and CPP headers to a C/CPP pcode format
> which could be accessed by the D cpp interface.  Part of the D compiler would
> comprehend certain foreign cpp constructs as part of the basic D compiler, while
> a simpler external parsing tool would actually generate a cpp pcode file.

There is no such thing as a simple C++ parsing tool. That's one of the huge problems C++ has - you need a full compiler just to parse it. It took 10 years for the various vendors just to get the preprocessor to be standard compliant.

Ben Cooley wrote:
> If you would like to see how such a convergence would work, take a look at
> "managed C++".  With .NET, microsoft faced the same problem.  How do you get
> people to migrate to .NET when they have large quantities of code written in C
> and C++?  Microsofts answer was the "IJW" philosophy.  You can take any C/C++
> code and simply compile it in .NET, then add .NET specific constructs to make
> the C++ code play nice in the .NET world.  You do not need to recode your
> existing C++ libraries in C#.  This is not really an apples to apples
> comparison, because Microsoft didn't extend C# to parse C or Cpp headers (which
> it should have in my opinion), but it did make Cpp play nice with .NET and that
> was very important for the adoption of .NET.

What managed C++ is is a bunch of extensions added to Microsoft's existing C++ compiler. That's what enables it to compile C++ - it already is a C++ compiler.

What they didn't do is make C++ code accessible to C#. They made C# code accessible from C++. That's good for enticing people to migrate to .net, but does nothing to migrate them to C#.

In article <e4bjhk$tr8$1@digitaldaemon.com>, Walter Bright says...
>
>Ben Cooley wrote:
>> In article <e4an5r$2reb$1@digitaldaemon.com>, Walter Bright says...
>>> Ben Cooley wrote:
>>>> I would suggest that a standard C and C plus plus compiler and parser be integrated into D, and that it not "convert" files, but just parse them directly without modification.  If the equivalent C or C plus plus construct is not available in D, D should provide a way of accessing that construct as a foreign object.
>>> That is a good idea, and I've toyed with it. The problem with it is that it pulls the rug out from other implementations of D. People won't want to use them because they'll expect the dmd 'extension' of being able to parse .h files directly.
>> 
>> Hmmm... well I can certainly sympathize because I don't want to use DMD without that capability either. ;-)  Truth is I can't.
>> 
>> But my advice to those other implementations would be to just get cracking.  The GCC implementation wouldn't have too much trouble  For the others there are a variety of free versions of full CPP compilers out there.
>
>g++ is the only free full C++ compiler out there.
>
>> An alternative would be to compile C and CPP headers to a C/CPP pcode format which could be accessed by the D cpp interface.  Part of the D compiler would comprehend certain foreign cpp constructs as part of the basic D compiler, while a simpler external parsing tool would actually generate a cpp pcode file.
>
>There is no such thing as a simple C++ parsing tool. That's one of the huge problems C++ has - you need a full compiler just to parse it. It took 10 years for the various vendors just to get the preprocessor to be standard compliant.

Elsa seems to do a pretty good job for us.. and we've got some pretty complicated template usage.  But you really need little more than the sort of parser used to create documentation, or to view the class hierarchy.  You don't need to parse any actual code, just definitions.  Swig is a good example.

As for the preprocessor, all C compilers come with their own already, so that's really not a major problem.  A D pass to extract macros first, then a preprocessing pass by the real Cpp compiler, then a declaration parsing pass.

In article <e4aoo6$2st8$2@digitaldaemon.com>, Dave says...
>
>Dave wrote:
>> Chad J wrote:
>>> Walter Bright wrote:
>>>> Chad J wrote:
>>>>
>>>>> I have even more trouble believing that current D compilers shouldn't support C plus plus integration just because it might make C plus plus compilation a required capability of a D compiler.
>>>> Take a look inside one of the STL header files - how can one access it without being a C compiler?
>>> Agreed.  You need C plus plus compilation ability to use C plus plus headers as they are.
>>>
>>> What I'm talking about though is this notion that DMD supporting C plus
>>> plus compilation somehow implies that every D compiler created from then
>>> on will also support C plus plus compilation.  I don't agree with that.
>>>  I think it reeks of fallacy.
>>>
>>> I'd say that C plus plus support for the first couple D compilers would make D more likely to become mainstream or become mainstream faster. The objective is no different than that of an external tool that translates C headers into D headers, but it may be easier to do since it puts a fully functional C plus plus parser at your disposal (at least I think it does).  Just make sure to clearly mark the C plus plus capabilities as something DMD specific, a bundled tool really, and everything should be dandy.  Same goes for GDC if it were to add such a faculty.
>>>
>>
>
>All those "C"'s should read "C plus plus" (what the heck is stripping the "plus plus"'s for this NG?).
>

BTW - This doesn't seem to have anything to do with the NG server, but SeaMonkey's incarnation of Thunderbird is apparently 'hiding' the '++' in C++ (I noticed other posts with the same problem so assumed it was something to do with the NG server)...

>> There seems to be an assumption that converting C to D is a straight-forward thing to do, even if you have a C front-end at your disposal. Heck, IIRC CFront was eventualy abandoned in part because C became complicated enough that a C to C converter was barely feasible any longer (beside the obvious other advantages of native C compilers).
>> 
>> My point is that really what your suggesting is another whole compiler here...
>> 
>> And if you don't have a compiler handy, there are quite a few open source and commercial "compiler-compilers" out there, but I've never heard of a commercial compiler that has been developed with one of them. And, I've rarely heard of any other tools like syntax high-lighters, class browsers and such that are developed that way, either. There has been quit a few D parser projects started using tools like Antlr, and they seem to get 90% there, but then I suspect the developer runs into cases where those tools aren't quite flexible enough and/or create very bloated and slow compilers.
>> 
>> All this leads me to conclude that what you're asking for would require another hand-made compiler to do properly, and for dubious gain since the code created would just be C disguised as D and wouldn't take advantage of a host of D's other features.
>> 
>>> Don't make it part of the spec, but make it part of the toolset.  At least while C plus plus is still popular.

> In other words:
> 
> import std.cpp;
> import msvc.cpp;
> 
> include "mylib.h"

please stop talking about such ugly things... the discussion is long enough (i think) - we don't want an real c++ compiler in D (and for your ideas some is needed - if you understand it or not) or in an standart toolset around D - because the D syntax is near enough to C/C++

> The advantage of this is that, though it may not be pretty.. it's simple and it
> doesn't require you to wrap what could literally be thousands of headers.  It
> also means that your links to the original code will not break unless the api
> breaks.

all your handy and pretty ideas are nice to use but very hard (due to the mud code which is needed - its not an technical problem - its an phylosophical...) to implement

Walter don't want to mutate the clean/simple/nice/fast D front/backend code into an C++ understanding between-the-worlds-compiler ... it is possible but only simple of your extension ideas will kill the clean (technical/phylosiphical) situation - and you will only understand the problem if you get more in contact with compiler development and language development

and please - walter is one of the first full c++ compiler developers on the world ... try to understand his problems with your ideas
"a flood of ideas don't help you to understand"

btw: i think all your saying is just blabla - do you realy want to use D? - i don't think so (not only because of the cpp linkage problems)
(if Cpp were linkable with D) - what are the other your other reasons to use D?

ciao dennis

In article <e4bk4o$va0$1@digitaldaemon.com>, Walter Bright says...
>What managed C++ is is a bunch of extensions added to Microsoft's existing C++ compiler. That's what enables it to compile C++ - it already is a C++ compiler.
>
>What they didn't do is make C++ code accessible to C#. They made C# code accessible from C++. That's good for enticing people to migrate to .net, but does nothing to migrate them to C#.
You can make DMC++ works like the managed C++, and then the relation of DMC++ and DMD would be just like Managed C++ and C#; that is, you can call the C++ code with DMC++ in the middle.

sailormoontw wrote:
> In article <e4bk4o$va0$1@digitaldaemon.com>, Walter Bright says...
>> What managed C++ is is a bunch of extensions added to Microsoft's existing C++ compiler. That's what enables it to compile C++ - it already is a C++ compiler.
>>
>> What they didn't do is make C++ code accessible to C#. They made C# code accessible from C++. That's good for enticing people to migrate to .net, but does nothing to migrate them to C#.
> You can make DMC++ works like the managed C++, and then the relation of DMC++
> and DMD would be just like Managed C++ and C#; that is, you can call the C++
> code with DMC++ in the middle.

It's technically possible, but it's just not very exciting :-(