In article <e49cu3$13gk$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>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.
>
>This isn't a "just because", C++ is known to be excessively hard to compile right, and one of the goals of D is to be easy to compile, to make sure you actually get compilers that are standard compliant and produce correct code within a sensible timeframe.

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.

In article <e4a4q4$27d3$1@digitaldaemon.com>, Ben Cooley says...
>
>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.

It just seems like your "gentle critique" of D is that it needs to inherit the whole of monster full C/C++ compatibility. And add more meta-programming capabilities. And add more safety. And finalize the standard (which I guess is an imaginary that exists only in your mind since D is already so far away from what you want). And create more libraries (but why would more libraries be needed if it were so compatible to C/C++?).

So in short, I can't tell that you actually like anything about what D currently is, so you might as well design your dream language from scratch because I don't think that D has anything to offer you. (So why are you here anyway?)

jcc7

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.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

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.

Nick.

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.

I guess that Walter would know if it was technically feasible, having developed the current D reference compiler, and the first native commercial C++ compiler. If he don't want to do it, I don't see how that would hinder you from trying to get this working with the GDC and G++ sources, though.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

My problem, maybe not related to this topic, is that the D programs written in maybe 2002 2003 2004 is not compatible with the current D compiler, and the library is not compatible too. I got a error using the optlink.

Those authors I don't know why but they might lose interest of D, they just don't release newer version of their D program, and the old programs cannot be used and I need to re-write them if I want to use.

In article <e4a7kv$2aq9$1@digitaldaemon.com>, sailormoontw says...
>
>
>My problem, maybe not related to this topic, is that the D programs written in maybe 2002 2003 2004 is not compatible with the current D compiler, and the library is not compatible too. I got a error using the optlink.
>
>Those authors I don't know why but they might lose interest of D, they just don't release newer version of their D program, and the old programs cannot be used and I need to re-write them if I want to use.

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

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

Ben Cooley wrote:
> In article <e494td$jvc$1@digitaldaemon.com>, Hasan Aljudy says...
>> I only agree with 2 points: the lack of a rich library, and the lack (so far) of an IDE, but the lattar is not part of the language per se.
>>
>> Guess what, I came to D because I hated C++.
>> C++ has the worst set of libraries ever. If you compare what C++ has vs. what Java has, the Java libraries would win anyday!
>> Even if the same library was written for both Java and C++, the Java version would always win. (look at the ICU library for example).
> 
> I don't disagree.  However it's simply not possible to do any sort of practical
> programming without using these libraries, and it's extremely tedious to have to

I strongly disagree; at least in the environments that I've been working in over the past 5 years using C and C++, I could have done a lot of the work with D and phobos as-is. What I've been doing in those languages is a lot of small "script-like" utilities that need high-performance, and a couple of larger server-side projects that use parts of the STL (that can be replaced for the most part with D built-ins like first class arrays, char[] instead of std::string and AA's). The other DB and web-related stuff I've been doing, I wouldn't use C or C++ for anyhow.

D won't take over the world in 'one fell swoop', it's primary initial use will be things like the above, and it will be new development and not porting of C or C++ code that's already been debugged and in operation.

That said, Walter has taken his ECMAScript implementation and ported that from C++ to D. It was done with about 1/2 the source code (including non-std libs) and runs about 25% faster. What Walter describes here coincides with what I claim above (built-ins obviate the need for a lot of C++ library functionality):

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28938

Your OP sounds a lot like what I would have said a year and a half ago before I started to experiment w/ D in earnest. Now, I see little utility in complex "D to X" conversion projects. A conversion utility for the most widely used C++ libs. (template based) isn't practical, and headers converted using a C to D conversion program would probably require as much time to verify as just doing by hand and verifying as you go. Besides, with a conversion tool, an opportunity to "refactor" old C headers and libs. is lost.

About the only thing I agree with the OP about is that the library is a bit sparse. I agree that some more could be added to the std. lib. and at the very least the std.c.linux.* (DMD) vs. std.c.unix.* (GDC) issue needs to be resolved quickly for portability between the compilers.

And what I see as the most important missing parts of the std. lib. have been addressed with mango (IO) and DWT (GUI) once DWT is available for Linux. Oh, and probably XML support needs to be added, and there are projects addressing that as well.

I see in another post that your OP was predicated on your experience with a specific large C++ project in mind. You need to include details like that before you post "show stopper" issues for D... In your current world they may be show stoppers, but for most of the rest, what you list as a show-stopper really isn't.

> wrap each library.  C plus plus is not as clean or as nice to program in as D,
> but at least I don't have to wrap all of the external code that I need to use..
> and the code I write will also be useful to other C/C++ programmers.  That's
> what you're up against here.
> 
> 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.  It really doesn't have to be that way
> though.
> 
>> Java and C# succeeded without dealing with any of the C++ crap; C++ wasn't a show stopper for them.
>> Infact, I bet C++'s stupidity was a recruitment tool for Java and C#. It can also be a recruitment tool for D.
> 
> It can be.. but I think it's wishful thinking to compare D to C# or java for a
> number of reasons.
> 
> 

sailormoontw wrote:

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

But this is nothing to be surprised over? The D compiler is still in beta, and D the language don't have a perfectly stable specification yet. I dare say you shouldn't be frustrated with beta software, it is almost by definition not compatible with it's own earlier versions, and is neither expected to work flawlessly.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi