Chad J wrote:

>> Translating C++ headers is trickier, but can be done too if needed...
> 
> Is there a good tool for C plus plus to C to D translation?

Not really, and it's a two-step process.

First you need to export all the C++ methods as "C" functions.
Then you need to write at least an import module, and probably
a class wrapper too, for all those exported procedural functions ?

> I think I confused the term "linking" with... I don't even know what to call it then.  C plus plus integration maybe.

Sorry, the "dropping of the plusses" added some confusion there.

D does have linkage with C functions (minus vectors, and some other
advanced things that C extensions offers), but *not* for C++.

So the only way to link with C++ is to first: export "C" { }

> I'd like to see that perl hack.  Is it online somewhere?

http://www.algonet.se/~afb/d/h2d.pl

There is no parsing and no understanding, it just searches/replaces.
It does try to use the C #defines, but sometimes it gets really confused. The way I use it is that I run it on the C headers, and
then I run a "diff" to fix the parts where it screwed up.

Some parts, like tricky macros, need to be rewritten from scratch.
So it's not really an automated solution, just a little "crutch"
(see the SDL and GL/AL headers from that same URL, for more examples)

> I remember trying SWIG to get some C plus plus to D conversion going on, but that setup didn't work very well.  Required a lot of work just to use it.  Cure is worst than the disease sort of thing.

SWIG is nice (when it works), but it's a huge project in itself...

> I noticed an h2d project on dsource.  But I think that only worked on linux, or something.  For some reason I wasn't able to even try it.

It has some really nasty C++ dependencies. Tried to use it, but...

> I don't remember seeing any tools of this kind that were written in D. Kind of unfortunate, probably makes it difficult to pool effort out of D programmers for something that isn't written in D.

I think that such a tool would be a good "exercise" for D, and
could become highly useful too - just like Build has become ?

But I started out with the missing GUI and IDE instead, myself.

--anders

Lars Ivar Igesund wrote:
> 
> 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.
> 

Like I said, I wouldn't expect it to be part of the D spec.  It could be just some sort of temporary thing that serves its purpose while C plus plus gets phased out of existence.  I think D would win over C plus plus programmers much more quickly if it made the use of their old code as easy as possible.  D, After winning the same massive popularity as C plus plus has enjoyed, would then no longer need such a capability.

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

Don't include with dmd. Just put it on dsource, disguised as "yet another conversion tool project" ;)
or something like that.

ok, dsource is a bad idea, because the tool won't be open source.

Still, you can create a lame page on geocities and put the tool up for download.
Don't say it's Walter Bright, just pick a random nick name.

>> - Inability to access C/C include files...  Importance:   SHOW-STOPPER
>> --------------------------------------------
>> 
>> C can do this, D can not.
>> 
>> The size, scale, and prevalence of C and C libraries and code make writing wrappers for all of these libraries impractical.  That D can not just easily include C and C headers "as is" gives it a serious and I would suggest fatal disadvantage vs. C.
>> 
>> C out of the box could include C header files, meaning that even today I have access to the largest possible body of third party libraries and code.  Binary compatibility with C only is just not good enough.
>
>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.

Why not.  C and C++ compilers seem to be particularly common.  Digital Mars happens to have one, so does GCC, and it's even independently maintained.

It doesn't matter.  All proponents of marginal languages make similar arguments about the goalfor some sort of purity.  It seems like this is the common reason why marginal languages are created in the first place, but it's also the primary reason why they fail to become mainstream languages.

Think about this.. if C++ had followed the same path, it would also have failed. The utility of the "It just works" paradigm in C to C++ integration and conversion made the success of C++ possible.

I would generally say that any successful competitor to C++ and C would:

1. Need to directly parse C and C++ headers.
2. Need to integrate with C++ (ABI).
3. Need to be able to be used in a mixed project (C/C++/D) and arbitrarily mix
and match C, C++, and D objects.

My motivation for posting this critique is not to criticize D.. which I happen to really like, but to vent my frustration that as it stands I will never actually be able to use it.

In article <e4943e$hke$1@digitaldaemon.com>, Hasan Aljudy says...
>
>Technical alert: it seems that the (plus plus) disappears from your
>post. hence C++ (see plus plus) appears as C (see).

It did seem a bit strange.

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

In article <14fakmish13b0.1mid2engjqpes.dlg@40tude.net>, Derek Parnell says...
>
>On Sun, 14 May 2006 23:22:56 -0700, Walter Bright wrote:
>
>> Derek Parnell wrote:
>>> But all joking aside, it just occurred to me that Digitalmars already has a tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm wondering if Walter could provide a new utility that can help us automate translation of C/C++ headers into D source code?
>> 
>> There's no way to do that with C++ - just take a look at any Boost headers :-). It is possible to do a 90% automatic translation of C headers.
>
>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.

Well, what you have is both several full C/C++ parsers and full compilers out there (for example the Digital Mars Compiler or GCC), AND full control of the D language specification.

The incompatibility with C plus plus is a current design decision.  It really doesn't matter in the grand scheme of things.. C plus plus will be the language of choice simply because it integrates and can use exiting code, and is good enough at everything else.  D will continue neither being able to parse C and C++ header files or integrate with C++, and remain not widely used.

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.


>Kyle Furlong wrote:
>
>> First of all Ben:
>> 
>> Welcome to the D community!
>> 
>> I would like to apologize for the less than optimal welcome you have received so far; they should know better.
>
>Well, most people _do_ have a sore spot for ignorant rants masked as "gentle critique"s (although I hope the post wasn't meant as an ignorant rant).
>
>Ben, I think you're off the spot on most of your observations, and if you really care about D, you should also have taken the time to ask a few questions, not just assume that everything is the way it looks. When that is said, some of your observations are correct, and D need more contributors, so why not help D along. Most people on this newsgroup tend to respond positively to positive and constructive suggestions, and contributions.
>
>-- 
>Lars Ivar Igesund
>blog at http://larsivi.net
>DSource & #D: larsivi

Ben Cooley wrote:

>>> - Inability to access C/C include files...  Importance:   SHOW-STOPPER
>>> --------------------------------------------
>>> 
>>> C can do this, D can not.
>>> 
>>> The size, scale, and prevalence of C and C libraries and code make
>>> writing
>>> wrappers for all of these libraries impractical.  That D can not just
>>> easily include C and C headers "as is" gives it a serious and I would
>>> suggest fatal disadvantage vs. C.
>>> 
>>> C out of the box could include C header files, meaning that even today I
>>> have
>>> access to the largest possible body of third party libraries and code.
>>> Binary compatibility with C only is just not good enough.
>>
>>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.
> 
> Why not.  C and C++ compilers seem to be particularly common.  Digital Mars happens to have one, so does GCC, and it's even independently maintained.
> 
> It doesn't matter.  All proponents of marginal languages make similar
> arguments
> about the goalfor some sort of purity.  It seems like this is the common
> reason why marginal languages are created in the first place, but it's
> also the primary reason why they fail to become mainstream languages.

I don't see a single sign of D "failing", although a fairly low number of active developers lead to a somewhat slow development of libraries and such. And currently there is no single person in the D community feeling that the need for such a tool is so great that they prioritize developing it. If you feel different, I urge you to do something about the situation, since I am quite sure it would be heartily welcomed (no sarcasm here, really).

> 
> Think about this.. if C++ had followed the same path, it would also have failed. The utility of the "It just works" paradigm in C to C++ integration and conversion made the success of C++ possible.

And this is one of the reasons for C++ getting into the mud in the first place.

> 
> I would generally say that any successful competitor to C++ and C would:
> 
> 1. Need to directly parse C and C++ headers.

This would have been nice, but as is said is an almost impossible task unless you are willing to spend a huge amount of time.

> 2. Need to integrate with C++ (ABI).

I don't see how this should be possible, the different C++ compilers don't agree about the ABI!

> 3. Need to be able to be used in a mixed project (C/C++/D) and arbitrarily mix and match C, C++, and D objects.

This is possible as long as mangling and ABI otherwise match, but it requires everything to be compiled with the same toolchain, plus quite a lot of massaging for the C++ part.

> 
> My motivation for posting this critique is not to criticize D.. which I happen to really like, but to vent my frustration that as it stands I will never actually be able to use it.

Hmm, this must be the first time a critique was not meant to criticize ...

Seriously, have you tried to use D? What kind of libraries do you need? Are you aware of the fact that Java libraries actually might be possible convert to D with much less effort than whatever you try to do with C++?

And what about dynamic linking/loading? This is usually considered a good practice, and it is eminently possible (just like in C and C++) to do in D.

D have it's issues, and not being able to link in C++ (or understand C++ source) is not one of them, IMO. As I try to mention from time to time, D is already being used in several commercial projects, which in themselves will lead to more commercial D development. The spiral is going upwards, the speed it happens with is irrelevant.

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

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.

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.