On 9/18/2011 2:49 AM, Peter Alexander wrote:
> Unity builds help a lot with link time.

dmd does something similar if you build an executable by putting multiple modules on the command line. It will create one big object file, instead of one per module.

On 9/18/2011 3:27 AM, "Jérôme M. Berger" wrote:
> 	Note that you can also use partial linking to help with link times
> while iterating development on large projects. At least on Linux
> (with the -r or -i options to ld), I do not know about optlink.

Optlink does not do incremental linking.

On 18/09/11 7:59 PM, Walter Bright wrote:
> On 9/18/2011 2:49 AM, Peter Alexander wrote:
>> Unity builds help a lot with link time.
>
> dmd does something similar if you build an executable by putting
> multiple modules on the command line. It will create one big object
> file, instead of one per module.

This is good.

Does dmd also cache commonly imported modules in this case?

e.g.

// foo.d
/+ lots of code +/

// bar.d
import foo;

// baz.d
import foo;

dmd foo.d bar.d baz.d

How many times is foo parsed? Once?

On 9/18/2011 3:33 PM, Peter Alexander wrote:
> Does dmd also cache commonly imported modules in this case?
>
> e.g.
>
> // foo.d
> /+ lots of code +/
>
> // bar.d
> import foo;
>
> // baz.d
> import foo;
>
> dmd foo.d bar.d baz.d
>
> How many times is foo parsed? Once?

Once.

> 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.
That way one could even add partial conversion support for source files afterwards to ease porting.

And C++ interoperability needs to be improved.
It's just insane to wrap a monster like Qt in C code and then recreating the whole class hierarchy at the D site - both performance and executable file size wise.

On 9/18/2011 9:00 PM, Trass3r wrote:
>
> We really need a proper tool to convert C/C++ headers, probably based on
> Clang.
> That way one could even add partial conversion support for source files
> afterwards to ease porting.
>
> And C++ interoperability needs to be improved.
> It's just insane to wrap a monster like Qt in C code and then recreating
> the whole class hierarchy at the D site - both performance and
> executable file size wise.

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?

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

Peter Alexander Wrote:
Yes

> I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html
> 
> In summary, the author asks if you were offered $100,000,000 for some big software project, would you use your pet programming language?
> 
> This is interesting, because if we answer "no" then it forces us to think about the reasons why we would *not* use D, and perhaps those concerns are what we should be focusing on?
> 
> ---
> 
> To get the ball rolling, here are the reasons I would not use D for a big project with high stakes:
> 
> 1. If I had to port to ARM, or PowerPC, or some other architecture then I would very likely have trouble finding a compiler and other tools up to the task. I wouldn't have that problem with (say) Java or C.
> 
> 2. I'm not convinced that any of the available compilers would cope with a very large code base. I don't know what the largest D2 project is, but I think I would be right in saying that it has less than 1 MLOC.
> 
> 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++.
> 
> 4. I'd be worried about garbage collector performance, although this is less of a concern than the others because it's not too difficult to work around if you know you need performance up ahead.
> 
> 5. If I did use D, I would (and do) force myself to use only simple features. I would be too scared of the type system blowing up, or obscure template errors causing pain. One error I always seem to get when using Phobos is that it can't find a match for a function because the types somehow didn't pass the template constraints for some obscure reason. When there are multiple constraints, you don't know which is failing. Often it is due to the complicated const/immutable/shared parts of the type system.
> 
> ---
> 
> Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this.

Am 19.09.2011, 03:06 Uhr, schrieb dsimcha <dsimcha@yahoo.com>:
> On 9/18/2011 9:00 PM, Trass3r wrote:
>> And C++ interoperability needs to be improved.
>> It's just insane to wrap a monster like Qt in C code and then recreating
>> the whole class hierarchy at the D site - both performance and
>> executable file size wise.
>
> I imagine C++ would be virtually impossible

Of course you can't support everything, but there sure is room for improvement:
http://d.puremagic.com/issues/show_bug.cgi?id=4620

> http://www.digitalmars.com/d/2.0/htod.html

It's windows-only, discards const, doesn't turn static arrays into pointers IIRC and it depends on the dmc toolchain and system includes, so the library you want to use basically needs to be compatible with dmc.
All in all I'm much faster with a manual, maybe regex-supported conversion.