|
Boost : |
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-05-28 17:34:37
On 5/28/22 20:21, Peter Dimov via Boost wrote:
> Soronel Haetir wrote:
>> Something I would consider useful from a compiler standpoint would be able
>> to control warnings on a path basis. That is, if it's part of the system includes
>> (along with other customizable directories), a different, much more forgiving
>> set of warnings is in effect.
>> Particularly for style warnings like NULL vs nullptr vs 0. Only code that is
>> explicitly part of my current target (whatever that means in the given
>> environment) should have stylistic warnings in effect.
>>
>> Even MSVC's #pragma warning doesn't give that kind of control, it can reduce
>> warnings (or disable particular warnings) for a block of includes, but has
>> nothing to do with the paths the files come from.
>
> That's not as useful as it seems because the header is often included multiple
> times using different paths and because of include guards only the first path
> matters, which usually has nothing to do with the path that would have led
> to the warning were those previous includes not present.
I think the idea is to associate warning settings with a set of files in
the filesystem (i.e. inodes), not the paths to them. Somewhat similar to
how `#pragma once` works. Although there are caveats with `#pragma
once`, most of the time it works rather reliably, so maybe not such a
bad idea. Though I have a hard time to imagine how such heterogeneous
settings would be expressed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk