Chad J wrote:
> James Pelcis wrote:
> 
>>True.  This has been discussed before, but has been rejected intentionally.  We don't want every D compiler to end up being a C compiler, too.
>>
> 
[...]
> 
> That said, the two known D compilers are also C compilers (or at least share backends with C compilers).

dmd under windows has a "header generation" feature that will make D's
replacement to a .h file. Further more it shares the backend ()and thus
the frontend/backend interface with dmc (Walter's c/c++ compiler). I'm
wondering, where is the "header generation" going on? Is it close enough
to the front/back interface that the C compiler could be stacked on top
of it? This would allow automatic generation of headers from .c or .h files.

Walter Bright wrote:
> Derek Parnell wrote:
> 
>> May I repeat a portion of my post please ...
>>
>>     "a new utility that can **help** us automate
>>      translation of C/C++ headers into D source code"
>>
>> I know that 100% automated translation is not practical. However, as
>> DigitalMars already has a C/C++ parser that works, I was thinking that a
>> tool based on that parser to created a best-effort translation and
>> highlighted that which needs human effort might be a useful addition to the
>> D tool set. Whatever you have now as a C/C++ parser has got to be better
>> than writing a new one from scratch. I'm not asking for the source code for
>> that parser, just a tool that would output something that could be tweaked
>> into D code by either (or both) another tool or person.
> 
> 
> One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image.
> 
> The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.


What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.

Jarrett Billingsley escribió:
> The libraries that come with the DX SDK are not compatible with D, as jcc alluded to in his post.  You must instead (as nonagon does) use the libraries created for Borland compilers, as that's the format that the D linker understands.  The libs included with nonagon are those Borland-style libs. 
> 
> 

Is it so? I remember trying to use Delphi and Borland C++ libs with optlink and I never got anywhere. And viceversa. I wander what went wrong...

-- 
Carlos Santander Bernal

Lars Ivar Igesund wrote:
> Ben Cooley wrote:
> 
>> Hi Lars,
>>
>> I'm rooting around for a more practical language that can be integrated
>> into a
>> very large mixed C/C++ codebase.  D just can't do what I need it to do,
>> and it's really too bad because I have followed D and really actually do
>> like it.
>>
>> The code base we work with has several problems, one being the inclusion
>> of more than 20 external C and C plus plus third party libraries, as well
>> as utilization
>> of the linux and windows api's.  And more importantly occasional
>> instability due to the use of C unsafe programming practices.
>>
>> I'm posting this because I suspect that the quiet majority of C plus plus
>> programmers out there agree with me.  We simply aren't interested in
>> participating in a crusade to make D popular.  We just want something that
>> can do what we really need, and there are an awful lot of C and C plus
>> plus projects out there that depend on being able to parse C and C plus
>> plus headers and likely always will be.
>>
>> I'm not trying to offend anyone, and I really don't expect anyone to agree
>> necessarily.  Just want to put forward my opinion as to what made a
>> language like C plus plus with its radical new programming paradigm
>> popular.. and how D deviates from this path.
> 
> Yeah, I see that you have an immediate need, see my other answer to you on
> how I think you should fix it ;) IMHO, you shouldn't mix C and C++ in this
> discussion, they are two different kind of problems (or C's problems in
> this regard is a subset to those of C++).
> 
> You can link C object files directly, you only need the API declared in D,
> and in many cases this conversion is trivial. This is because C at the
> bottom is a simple language.
> 
> C++ is not a simple language, and neither is D. Both has a common stem in C,
> but they wildly diverge in design goals, and in many places in
> functionality. This makes it difficult, no matter what, to make them play
> nice together. The brute force solution is to make wrappers, which usually
> involves exposing the C++ lib as C functions, and then wrap it back in D
> objects. wxD do this.
> 
> But you make one faulty assumption regarding the life of D and it's growth,
> and that is that all D fans actually comes from C/C++ land. Equally many
> come from Java and C#, people that often like the language, but is
> dissatisfied with the speed options. And I think quite a few from the
> scripting camp might take an interest too, when projects such as DSP get
> into release. D is a different language (although it is perfect for C++
> users), and it's possible uses range much further.
> 

This last paragraph is so true. I am one of these people who come from C# because of the need for a compiled people. D is not just c++ 2006.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

Jarrett Billingsley wrote:
> "sailormoontw" <sailormoontw_member@pathlink.com> wrote in message news:e4aac7$2dm3$1@digitaldaemon.com...
>> 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. I know it must be the version
>> imcompatible, and then, I try to recompile the source. Not only did I find some
>> codes need to rewrite but after all the codes seemed fixed to get a successful
>> compilation, some the samples still cannot run at all. I find its for the
>> mqoreader.d, but should I spend time to debug it??
>>
>> Nope, it's hard to debug other's code, and I can feel the frustration of the
>> author of hdk for the frequent changing of D. I think that's the reason he or
>> she stopped upgrading. And if I want to upgrade the codes, I think I will face
>> the same problem, and not to say there isn't a good debugger to help.
>>
>> Well, maybe I should not choose DirectX, SDL with derelict library seems more
>> stable and ready. I still hope there is a good DirectX wrapper to use...
> 
> I wrote/am writing a DirectX9 engine called nonagon, you can download it here:  http://jamesdunne.no-ip.org/nonagon/projects.php.  It has, among other things (like an engine ;) ), a fairly up-to-date, if somewhat incomplete, conversion of the D3D9 and D3DX9 headers, as well as the DInput headers.  It's based on the June 2005 release of the DX9 SDK, so it's a little behind, but not much has changed in the SDK since then.
> 
> The libraries that come with the DX SDK are not compatible with D, as jcc alluded to in his post.  You must instead (as nonagon does) use the libraries created for Borland compilers, as that's the format that the D linker understands.  The libs included with nonagon are those Borland-style libs. 
> 
> 

Cool project Jarrett!

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright

"Ben Cooley" <Ben_member@pathlink.com> wrote in message news:e48h8g$pk$1@digitaldaemon.com...
> There are a few major problems with D that still prevent it from being
> practical
> for use in the real world.
>
> I'll just list them and note their importance.  Anything witha
>
> - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
> --------------------------------------------

[snip]

Do you mind if I email you? I'd like to talk about these issues you raise wrt something slightly off-topic for D. If you don't feel like posting your email my address is ben dot hinkle at gmail dot com.

thanks!
-Ben

"Carlos Santander" <csantander619@gmail.com> wrote in message news:e4b6vm$21c$1@digitaldaemon.com...
> Is it so? I remember trying to use Delphi and Borland C++ libs with optlink and I never got anywhere. And viceversa. I wander what went wrong...

Maybe it was because they used some Delphi/C++ specific things.  The DirectX libraries, at least, are mostly import libraries to DLLs, and as such, don't do much incompatible stuff.

Chad J wrote:
> 
> No.  I wouldn't know.
> 
> If the objection to this sort of thing is technical, then I'm fine. What bugs me is that the objection seems to be based on some kind of fear that DMD's support of C plus plus would imply that other compilers must support it.  I disagree.
> 
> It's like saying that if I were to make an external tool to translate C plus plus headers to D, that it would automagically become part of the language spec and everyone would have to use it forever.

It's safe to say that it's technically infeasible to do. But the other argument also has merit. Anything Walter builds into the compiler, or distributes with it, will be perceived as part of D whether it is in the spec or not. It doesn't matter that the perception is wrong. If people believe it, that's all it takes. Having a tool hosted by a third party on another site is altogether different. But because of the complexity, don't expect Walter to do it anonymously or otherwise. It's a horrid misapplication of resources.

BCS wrote:
> What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.

There is always something in each header that is not translatable :-(

In article <e4baj5$aut$1@digitaldaemon.com>, Walter Bright says...
>
>BCS wrote:
>> What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.
>
>There is always something in each header that is not translatable :-(

Could the language be extended to allow the non-translatable elements to simply be used "as is" by wrapping them with intrinsics as needed?

In other words:

import std.cpp;
import msvc.cpp;

include "mylib.h"


..
..
..

// Intrinsic cpp new class function
my_cpp_class = NewCppClass("MyClass", 100, "Parameter");

// Intrinsic cpp macro value
const int MY_MACRO = CMacroValue("MY_MACRO");

// Intrinsic template instantiation
my_cpp_template = NewTemplateClass("std::vector", "MyClass");

etc.

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.

If you want, you can build your wrapper using intrinsics instead of having to rewrite a header.  But more importantly you can just use what you need, and directly call c functions and instantiate, call, and delete c classes and templates or access C or Cpp macros.