Oh, I think it also doesn't turn #ifdefs into version()s so you potentially lose another big chunk of information.

Am 19.09.2011, 03:06 Uhr, schrieb dsimcha <dsimcha@yahoo.com>:
> how hard can it possibly be to translate **non-preprocessor-abusing** C code to D?  D is almost a superset of C.  The only incompatibilities I can think of are the preprocessor/module system, bitfields, and some minor syntactic differences.  Am I missing anything important?

Yep, but C code does abuse the preprocessor.
Static arrays are another incompatibility, I'm not sure though if extern(C) automatically makes int[3] being passed by ref.

On 9/18/2011 9:18 PM, Walter Bright wrote:
> On 9/18/2011 6:06 PM, dsimcha wrote:
>> I imagine C++ would be virtually impossible, but how hard can it
>> possibly be to
>> translate **non-preprocessor-abusing** C code to D? D is almost a
>> superset of C.
>> The only incompatibilities I can think of are the preprocessor/module
>> system,
>> bitfields, and some minor syntactic differences. Am I missing anything
>> important?
>
> http://www.digitalmars.com/d/2.0/htod.html


Right, but htod only translates headers.  I was talking about translating full **source code**.

> Python is a great Python but an awful C++, not to mention the
converse. D, on the other hand, is arguably a much better C++ and also a pretty good Python.

"Pretty good" as in pretty bad for integer operations where Python3 use "big int" and D silently corrupt your data in case of overflow like C/C++ if memory serves.

BR,
renoX

On 2011-09-19 03:00, Trass3r wrote:
>> 3. Depending on what the project was, I would probably be worried
>> about available libraries. If, for example, the project required the
>> use of DirectX, I'd just use C++.
>
> That's a major problem.
> With D you spend way too much time creating bindings or even wrappers to
> access external libraries rather than doing actual work.
>
> We really need a proper tool to convert C/C++ headers, probably based on
> Clang.

It's in the works: https://github.com/jacob-carlborg/clang
It's currently most focused on porting Objective-C headers. Don't count on it in the near future.

-- 
/Jacob Carlborg

Am 19.09.2011, 18:43 Uhr, schrieb Jacob Carlborg <doob@me.com>:
>> We really need a proper tool to convert C/C++ headers, probably based on
>> Clang.
>
> It's in the works: https://github.com/jacob-carlborg/clang
> It's currently most focused on porting Objective-C headers. Don't count on it in the near future.

I know, but didn't you say it's more of a patch/hack rather than using the rewrite facilities or whatever?

On 2011-09-19 18:56, Trass3r wrote:
> Am 19.09.2011, 18:43 Uhr, schrieb Jacob Carlborg <doob@me.com>:
>>> We really need a proper tool to convert C/C++ headers, probably based on
>>> Clang.
>>
>> It's in the works: https://github.com/jacob-carlborg/clang
>> It's currently most focused on porting Objective-C headers. Don't
>> count on it in the near future.
>
> I know, but didn't you say it's more of a patch/hack rather than using
> the rewrite facilities or whatever?

It does use the rewrite facilities. Maybe I said it was a hack how it's incorporated with clang. It's not built as a plugin and it doesn't use clang as a library. The repository contains the whole clang source code and I've added a new rewriter. It works just as the existing Objective-C rewriter that rewrite Objective-C to C or C++.

-- 
/Jacob Carlborg

> It does use the rewrite facilities. Maybe I said it was a hack how it's incorporated with clang. It's not built as a plugin and it doesn't use clang as a library. The repository contains the whole clang source code and I've added a new rewriter. It works just as the existing Objective-C rewriter that rewrite Objective-C to C or C++.

Ah ok. Sounds good then :)

On 17.09.2011 19:58, Peter Alexander wrote:
> On 17/09/11 4:32 PM, Adam D. Ruppe wrote:
>> Peter Alexander wrote:
>>> In contrast, my D hobby project at only a few thousand lines of code
>>> already takes 11s to build and doesn't do any fancy metaprogramming
>>> or use CTFE.
>>
>> Curious, did you use a library like QtD?
>
> Nope.
>
> I use some parts of the standard library, not much of it though. I also
> use Derelict, but again, not much of it.
>
> I'm talking about a -release -inline -O build btw.
>
> For a normal build it's only 1.7 seconds.

I have a suspicion about what's causing this. The main loop of the optimiser has a O(n^^2) behaviour with consecutive comma expressions. -release -inline makes a large number of comma expressions (there doesn't need to be any in your code). I've seen n reach 200; maybe it gets even higher in your case.
This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to fix, I think.

On 19/09/11 11:27 PM, Don wrote:
> On 17.09.2011 19:58, Peter Alexander wrote:
>> On 17/09/11 4:32 PM, Adam D. Ruppe wrote:
>>> Peter Alexander wrote:
>>>> In contrast, my D hobby project at only a few thousand lines of code
>>>> already takes 11s to build and doesn't do any fancy metaprogramming
>>>> or use CTFE.
>>>
>>> Curious, did you use a library like QtD?
>>
>> Nope.
>>
>> I use some parts of the standard library, not much of it though. I also
>> use Derelict, but again, not much of it.
>>
>> I'm talking about a -release -inline -O build btw.
>>
>> For a normal build it's only 1.7 seconds.
>
> I have a suspicion about what's causing this. The main loop of the
> optimiser has a O(n^^2) behaviour with consecutive comma expressions.
> -release -inline makes a large number of comma expressions (there
> doesn't need to be any in your code). I've seen n reach 200; maybe it
> gets even higher in your case.
> This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to
> fix, I think.

Ah ok, that makes sense.

In the meantime, any tips for avoiding this? Would splitting up large functions help?