On Wed, 02 Mar 2005 11:35:18 +1300, <brad@domain.invalid> wrote:
>>  Ok, but what if it's a warning about x, and you do want to know about x,  because it might be a bug, but in this one instance you've already decided  it's not. Basically it seems to me you want to be able to ignore x in this  instance only.
>>  Or does that never occur for some reason?
>
> I think that this would be a hard problem in general.

That was my impression also.

>   - You could use a pragma to suppress the warning, but that results in ugly code

And ties the code to the lint, not something I think is a good idea.

>   - You could use a config file to suppress specific warnings on specific lines, but that will break when the code moves

Yep.. I thought about this also.

>   - You could use a config file to suppress specific warnings within a function and happening on a particular symbol, but that may be too coarse

Possibly, but it's not as bad as the other options.

>   - You could do as above, and specify the count, if the counts don't match, warn.  Ie - "suppress narrow cast : foo.d : main : counter : 2" could perhaps mean, suppress the narrowing cast warnings for the foo.d file, within the function main, happening on the symbol counter - and suppress 2 of them.  If you change the code so that lint doesn't see exactly 2 narrowing casts on that symbol in that function, then it warns again.

Sounds like A useful, optional addition to the idea.

> Hand editing config files sucks, but presumably if you are super paranoid and have lint set to super-paranoid, then you won't mind suppressing the genuine occasions that you know better.

Or the lint program could manage the config, i.e. you run
  lint -s W10254 foo.d main 2

(meaning "suppress narrow cast : foo.d : main : counter : 2")
once, and it writes the config.

Regan

"Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:d02i4u$lsk$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> skrev i en meddelelse news:d00oun$1frg$1@digitaldaemon.com...
> > I noticed that you're using memory mapped files! Cheater! <g> Trying the
D
> > version with std.mmfile, I get about a 10% speedup. It adds one line of
> > code
> > and an import.
> > Anyhow, I think the effort you made just shows the point!
>
> I partly agree. The std::string is a sorry accident of history, and
without
> reference counting, it has very little to offer compared to vector<char>. But no string type will fit for all purposes. If you really are going for efficiency, you need some specialized string handling, and my point is,
that
> you can have that in C and C++ too (but STL will not help you). The
slicing
> concept of D is strong, and my solution in C++ was using slices too. Of cause much less elegantly than in D :-)
>
> Another win for the D version, is its associative arrays which I suspect
are
> hash tables internally.

And you'd be right. They are general purpose and aren't as efficient as a full custom hash table, but they work better than what one could quickly or casually build, and they're available at your fingertips.

> STL does not offer hash tables yet, but that does
> not mean that you cannot have them anyway. You just need to look
elsewhere.

Yup.

>>> The lint program is going to need to read object files also, isn't it, because some lint warnings might be based on global variables, types etc defined outside the source file it's processing..
>>
>> Lint doesn't check link errors - only syntax and probably some semantics errors. So it won't need to look at object files. The first pass - syntax checking - can also happen without looking at other source files. I don't know how much semantic analysis is possible without looking at the imports, though. Probably not much.
>
> I was thinking of a "narrowing integer conversions warning", say you're assigning a value to a global int. Lint would need to know that global was an int in order to give a warning about it.

It might need to search imported modules for the declaration of the global int, but it wouldn't have to know anything about object files (to me "object files" are the things generated by the compiler that contain machine code). I don't know how much a lint program would be able to accomplish aside from syntax checking without reading declarations from imported modules.