In article <e4a9sl$2d83$1@digitaldaemon.com>, jcc7 says...
>I think you should name some names of these older programs that you're trying to get to work. Some of the older work has been abandoned, but some of it might exist somewhere else in an updated form. Or someone might be able to quickly help you update it.
>
>(By the way, it's probably a good idea to actually start a new thread if your post isn't really related to the previous thread.)
>
>jcc7
Thanks for the reply, but another post of mine is sent before I read this message so I didn't change the subject of that post. I apologize for that.

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.

From http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce/2405:

"I've written a small utility that will convert import libraries in Microsoft COFF format to the OMF format used by the Digital Mars linker. This should make it much easier to keep import libraries updated with whatever the latest from Microsoft is.

"ftp://ftp.digitalmars.com/coffimplib.zip

"Consider it a beta. Let me know about any problems with it."


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

I think it's actually some kind of .lib file in the wrong format instead, but I could be wrong.

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

Eventually, we'll have a D 1.0 release, and that'll fix some of these problems of outdated source.

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

Maybe. I don't really have any experience with DirectX or SDL, so I don't know anything about this topic. But I know that others do have experience with these issues, so I think you can find various suitable libraries and bindings. You might just stumble into some old files first. But updated file are often available. If you ask us, we'll help you locate them.

jcc7

"Ben Cooley" <Ben_member@pathlink.com> wrote in message news:e4a3rm$25v9$1@digitaldaemon.com...
> Again.. Java and C# have their own advatages which tend to outweigh some
> of the
> disadvantages of not having direct and immediate access to system level
> libraries written in C and C++.  Yet D is intended as a system level
> programming
> languages.  The fact that it can't understand the entire body of system
> level
> code in C and C plus plus, and it doesn't play nice with C plus plus is a
> serious.. probably fatal.. drawback.

Most truly system-level code is written in C, with which D can already interface on a binary level.  So why bother making D compile C, when there are tons of C compilers out there already, and if D can already link with C code?

As for C++, name _one other language besides C++_ that can natively link with C++.  IT CANNOT BE DONE, for the reasons already explained: there is no unified C++ ABI, and as such, C++ libraries generated by different C++ compilers are often binary-incompatible.  Making D binary compatible with C++ would mean nothing; it'd be binary compatible with one small segment of C++ code and nothing else.

> It can be.. but I think it's wishful thinking to compare D to C# or java
> for a
> number of reasons.

If you mean they can't be compared because C# and Java had large, multinational companies backing their development, then yes, I agree that they can't be compared with D in terms of the "star power" that they have been given by their deep-pocketed creators.  However, in terms of simplicity, orthogonality, and expressiveness, D just seems like a system-level version of C# and Java.

Ben Cooley wrote:
> In article <e49b0t$11f0$1@digitaldaemon.com>, Walter Bright says...
> 
>>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 ****.
> 
> 
> Hi Walter,
> 
> Great work on D, by the way!  I guess this post is just frustration that I will
> never actually be able to use it except in some smaller projects.
> 
> About parsing headers.. I'm sure people would feel the same way about any C or C
> plus plus compiler. If it couldn't parse headers, it wouldn't be particularly
> useful.  It's a tough row to hoe.. but well there you are when you decide to
> write an alternative to C and C plus plus.  The ability to  integrate easily
> with all the existing code out there is crtitically important.

please note, one of the original motivations and explicit goals of D is to break the never ending backwards compatibility issue.
D is intentionally not compatible with C++. It's not a side effect of developing a new language, it's an explicitly stated goal!!

Tough ..

Don't try to convert millions of lines of C++ code to D, that's just not practical.



> 
> Speaking from personal scenario, the requirement that I wrap several hundred
> thousands of lines of existing code is a non-starter.  It was difficult enough
> the first time I did it.. having to place extern "C" { } around all my C headers
> transitioning over to C plus plus in the 80's and 90's and fix various
> ideosyncracies between the C and C plus plus parsers.  It's just completely
> impossible now.
> 
> 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.  
> 
> If this were possible, I could simply begin to add D modules to my code base and
> start the gradual transition.. as I once did long ago with my C plus plus code.
> 
> I would also like to add that the ability to clearly define certain regions of
> code as pointer or type safe is very nice in languages like C#.  Programmers
> discretion and code policies help in large projects.
> 
> 

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

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?

Ben Cooley wrote:
> That's certainly a good reason.  However, it doesn't help me or any other
> programmer out in the real world which have to deal with very large quantities
> of frequently updated c and c plus plus third party libraries.
> 
> D's role right now is as an enthusiast language for closed world small scale
> projects which can be written by hand converting existing c headers.  Is this
> the ultimate intent of this language?
> 
> I would say that a "header compiler" that just compiles both C and C plus plus
> headers into a format directly useable by D, and modifications to D such that it
> can easily use foreign C plus plus object types would be all that I would need..
> along with the ability for the D compiler to produce output that could be linked
> and debugged with existing C and C plus plus compilers on linux and windows.

D, right now, *can* link with existing C and C++ compiler generated code on linux and windows. It can also access C++ generated code that conforms to "COM" programming conventions.

For an example of how D connects with C code, see the std.zlib support in the phobos standard library.

nick wrote:
> Ben Cooley wrote:
>> There are a few major problems with D that still prevent it from being practical
>> for use in the real world.
> [SNIP]
> 
> 
> It seems like these complaints come up often, and they are mostly
> unjustified. Walter, perhaps you should address all of these in a
> FAQ-like section on the D site. If you already have a section like that,
> give it more visibility.
> 
> Just a thought.

There is www.digitalmars.com/d/faq.html. If you want to add to it by paraphrasing what's going on in this thread, I'll be very happy to accept the improvements!

Ben Cooley wrote:
> 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.

I understand where you're coming from. I agree that if D could parse C and C++ header files out of the box, that would increase the rate of D's acceptance.

The trouble is that if we were to do it, then we'd have to give up what D is and what makes D so cool. C++ has reached the end of the road in what can be done while maintaining C compatibility and compatibility with older C++ code.

That said, D can be (and is) compatible with the C abi, which is a lot more than can be said for other languages like Java, C#, etc. You *can* link to C object files. You *can* access C objects and C functions directly. You *can* access C++ objects directly if they adhere to the COM interface. You *can* hook up with any C++ code that exposes an extern "C" interface.

Chad J wrote:
> Walter Bright wrote:
>> D can link against C code right now, it just will not compile C code.
> 
> Sorry I didn't mean link.  Oh and I said C plus plus a lot, but I think the ng cut out the plus plus.  Basically I just want to be able to import .h  files and have it just work.

Please be specific.  There's a huge differencec between C and C++ insofar as D support is concerned.

> If it is actually easier to convert all of the C plus plus headers to D "headers" by hand than by creating some automated mechanism in the compiler, then OK, no full automated conversion.  I find that hard to believe though.

To properly convert C headers to D you really need a partial C compiler that generates D code, which is non-trivial.  C++ header conversion is another thing entirely, and it simply isn't possible in any reasonable or portable manner.

If you're truly interested in auto-conversion of D headers, why not create the tool yourself?  There are open source C front ends available which should make for a good starting point.

> I am thinking game creation middleware for myself.  This would involve hand translating a whole bunch of stuff, just to try it out.  I may not even use the results for very long.  I suppose I could code in C plus plus to try stuff out, but then I'm doing C plus plus coding and not D coding, and that's just about as bad as the header conversion (for me anyways).  Then if the maintainers of a C plus plus library change the library, the D wrappers become outdated and need fixing.

For what it's worth, you only need to translate the things you need direct access to from D.  And in my experience, this is substantially less than what's typically in the header file.  I very much recommend working from the spec as an indicator of what should be available rather than simply opening the header file and going for it.  Assuming a decent spec exists, conversion should go pretty fast.  If no such spec exists, simply follow the dependencies of any functions you wish to call and do the conversion on an as-needed basis.  Maintaining such headers should typically be fairly simple as declarations rarely change across versions.  Simply diff between the old and new set of headers and see if any changes are necessary.  Often there aren't.

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

*cough*  Are you truly suggesting that it would be trivial to have the D compiler also compile C++ code?


Sean