Compiled dmd2.032 in VC++ 2009!

[Jeremie Pelletier]

bearophile Wrote:

> Jeremie Pelletier:
> > I also made a simple D script to rename all c files to cpp:
> 
> Generally I suggest to use a scripting language to do a similar task (or a simper linux shell script, probably one or two lines), but I agree that doing this I can't see possible faults/troubles of the same D code. So in the end writing it in D is a good experiment.

D can be used as a scripting language too, and it's cross platform, plus it was a good test for my newly compiled dmd.

> You are probably an expert programmer, yet in your script I see some things that in my opinion are better done in other ways:
> - Don't init things to void unless your performance experiment tells you to, and do it with care. This is explained in D documentation too. The speed gain is very limited and the risk of giving false pointers to the conservative GC is present, because currently it's not very precise.

I am well aware of what =void implies, I had this habit ever since my first steps into D. The only times I don't use =void on variable declarations is when i want them to be initialized to their default values.

> - Gotos aren't evil, but it's better to use them only as performance optimization or for tricky flows of the code. Generally in D there are better ways to solve such problems. For example you can just throw an exception if args.length!=2, and the uncaught exception will show an error message to the user and the code will stop.

I generally don't use them a lot except to move error handling to the footer of a function or replace for(;;) loops. The dmd and druntime sources (I think phobos too) are full of such gotos anyways!

> - try ... catch(FileException) {} looks not nice.

Agreed, but it does what I want it to; redirect the exception to the Error label.

> - if(de.name[$-2 .. $] == ".c") is a bit unsafe, because unlike Python D slices aren't saturating (and in the meantime I have asked to the Python developers, they have told me that this design is desired in Python, it's not a design mistake left for backward compatibility as someone here told me. And it's a very handy thing. The only advantage of the way D slices are done is that D ones are a bit faster. But their unsafety unnerves me and forces me to write uglier and longer code). Generally it's better to use string functions, that are safer. Python has endswith() and startwith() string methods that in D (as functions) are even more important.

I don't see how unsafe that is in this context. I know it can be unsafe sometimes to send a slice to be saved somewhere, and later modify the original array. I only use slices to pass data around. As soon as a slice leaves the scope it is in (ie, assigning it to a property) or the original array is shared between threads, I use copies.

Besides, with the upcoming T[new] arrays, we're gonna see a major change in how arrays are used in D which should solve a lot of the current issues with slices. And once the shared qualifier is fully operational, its gonna solve even more issues.

> - In D the main doesn't need to return an int in an explicit way. If your program stops because you have thrown and exception, I think the return value is not zero.

Oh yeah, forgot about that one. Old habits again :)

> - Generally don't use this: printf("Usage: %.*s <path>", args[0]); printf() is good mostly to speed up output if you have to print tons of things, or in debugging write* functions, or for a simple compatibility with Tango. Generally use writeln or writefln.

printf isn't that fast, in fact it is quite slow, anything that has to parse the format string on every call is gonna be slow. In this case, writefln caused an unresolved toUTF8 reference which I was too lazy to look into.

> - Unless performance is critical, it's generally better to write script-like D programs in a high-level style, because in such kind of programs the purpose is to write the code quickly, to have readable code, and most of all to have the most reliable code as possible. In such small programs saving microseconds is usually not positive.

I also agree here, however I'm not all that familiar with higher level concepts, even the PHP code I do at work looks a lot more like systems programming than web scripting, but it runs fast.

> - Note for D developers, listdir() desiged like that isn't good. Python too used to have something similar (os.path.walk()), but it's better to invent its design, and give an interable that instead yields the nodes of the tree (os.walk() from Python 2.3).
>
> Bye,
> bearophile

Thanks for the comments though, I may argue a lot but I will remember what you said :)

J