3 ms·

Standards evolve. There's value in keeping things simple and consistent to allow that. So it'd be a cost to have specifically version treated exceptionally he

by emn13 7y ago

Standards evolve. There's value in keeping things simple and consistent to allow that. So it'd be a cost to have specifically version treated exceptionally here, and it'd be a cost to have system headers treated very differently from other headers (because it makes it harder to extend the system). So while it makes sense that system headers needn't be files - in principle - it sounds like a pretty big change too with some downsides as well. All that just for "version"?

ncmncm 7y ago
Not for <version>, or just for <version>. Rather, for being able to designate header names without worry about what files have been shoveled into random directories. It really is on the compiler implementers for not providing a better accommodation to this very predictable problem. That said, fixing the autoconf scripts may be the most immediate route to sanity for the "config.h" / <version> case, eliminating the problem at its source.
- a1369209993 7y ago
  > for being able to designate header names In other words, there's no reason why '#include <foo>' should ever be looking in the translation unit's directory; that's what '#include "foo"' is for.
  - ncmncm 7y ago
    I bet autoconf actually says "-I $top_level" or some such. What's mad is that -I controls where <> names are searched.
    - kazinator 7y ago
      I concur. -I is a traditional option from Unix compilers with a very silly behavior; but for years now we have had something called -iquote in gcc (and clang). Before -iquote, there was -I- which is deprecated.
kazinator 7y ago
There is value in not telling your compiler to look for all headers in your project root. There is no telling what clash that will create. Documented, public <> headers include other headers that are not documented. There is no telling what their names are.
- emn13 7y ago
  sure, no question - but that's out of the standards body control. And even if you don't include your own top-level dir, using a common file name might clash in other dirs too. Hoping that compilers would not resolve headers via user-specifiable directories sounds absurd to me - every single compiler I know of allows that, not just on unix, so if you want to retire that, that's going to be huge, multi-year effort. No point in considering that hypothetical reality when it comes to meaningful header names unless there is a reasonable likelihood of that happening. Not objecting to such a push; it just sounds wildly out of scope when picking a header file name.

by emn13 7y ago

ncmncm 7y ago

Not for <version>, or just for <version>. Rather, for being able to designate header names without worry about what files have been shoveled into random directories. It really is on the compiler implementers for not providing a better accommodation to this very predictable problem. That said, fixing the autoconf scripts may be the most immediate route to sanity for the "config.h" / <version> case, eliminating the problem at its source.

a1369209993 7y ago
> for being able to designate header names In other words, there's no reason why '#include <foo>' should ever be looking in the translation unit's directory; that's what '#include "foo"' is for.
- ncmncm 7y ago
  I bet autoconf actually says "-I $top_level" or some such. What's mad is that -I controls where <> names are searched.
  - kazinator 7y ago
    I concur. -I is a traditional option from Unix compilers with a very silly behavior; but for years now we have had something called -iquote in gcc (and clang). Before -iquote, there was -I- which is deprecated.

kazinator 7y ago

There is value in not telling your compiler to look for all headers in your project root. There is no telling what clash that will create. Documented, public <> headers include other headers that are not documented. There is no telling what their names are.

emn13 7y ago
sure, no question - but that's out of the standards body control. And even if you don't include your own top-level dir, using a common file name might clash in other dirs too. Hoping that compilers would not resolve headers via user-specifiable directories sounds absurd to me - every single compiler I know of allows that, not just on unix, so if you want to retire that, that's going to be huge, multi-year effort. No point in considering that hypothetical reality when it comes to meaningful header names unless there is a reasonable likelihood of that happening. Not objecting to such a push; it just sounds wildly out of scope when picking a header file name.