lint for D

Markus Koskimies markus at reaaliaika.net
Thu Jul 10 02:01:11 PDT 2008


On Thu, 10 Jul 2008 09:26:19 +0100, Bruce Adams wrote:

> I am in the camp that would have more warnings in dmd too but I can't
> see that happening.

That's a little bit sad. IMO there are two different things in the 
compiler; (1) if it can or cannot generate code, i.e. if the source 
follows language spec or not (giving error, if it cannot), and (2) being 
able to generate code, but it thinks it may not be what it was meant to 
be (giving warning).

But I'm patient and I can live with most of the D compiler/language 
design decisions :) There is just not currently any better alternatives 
for those purposes I use D. In my work, I of course use the language the 
employer says (that is, C, C++ and assemblers), and at my freetime I 
regularly use Python, Java and D (each for different purposes).

> gcc is an example of both the good and bad of this. It has
> 10,000
> options making it non trivial to understand the API let alone test it.
> The options have to reworked for each target OS by configure command
> otherwise treat warnings as errors makes code
> fail to compile. The warnings changing with each version of gcc is a bit
> like
> minor language specification changes (as Walter noted).

So true :D

> With all the warnings switched on your need for a lint is vastly
> reduced. 

Absolutely true. That's why I generally like to use gcc/g++. I have 
experience of setting up & maintaining lint for an embedded C compiler, 
and that was quite horrible. That's why I like that the compiler has the 
basic checkings built in.

> I believe the gain from lint is still
> significant but its harder to demonstrate.

I'm not sure about that, of course it's very much up to the effort for 
configuring lint for the project and maintaining it. But yes, sure, 
probably generic Win/Linux projects are much easier than a specialized C 
compiler with bunch of hardware related extensions and non-standard 
"standard" library & OS.

[Ddoc/doxygen]
> In the case of thing you integrate into your
> build process at least. This is not true for IDEs (which are more
> subjective anyway).

I'm not using IDE not in my work and neither at home. That's why I 
implicitly assume that a tool is integrated to a build process, not to an 
IDE.

>> I know that the UNIX way of thinking is to put everything in to
>> separate programs, but that was just my thought.
> 
> It is and it isn't. Anyway you can still have one program as the driver
> that invokes multiple programs. gcc does this under the bonnet.

Yes it does and even though the gcc can be criticized to be complex, it's 
IMO still good to have HLL compiler(s), assembler / machine code 
generator and linker in the same package.



More information about the Digitalmars-d mailing list