3 ms·

> No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned. That seems l

> No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned. That seems like an insane concept. I honestly can't see how it can be justified in a world where pretty much every compiler since the 90s has support for `#pragma once` and detects include guards automatically without re-reading the header.

lproven 3y ago
Oh really? Can you illustrate this with examples? Ones that are from outside of the Unix and C family, just to make it clear that we aren't talking about tweaks to old tools?
- GabrielTFS 3y ago
  Examples of what ? Also, what exactly do you mean by "outside of the Unix and C family" ? (note: if you want examples of compilers that have `#pragma once` then I don't know what to say because I'd be hard-pressed to name a compiler that does not support it - similar situation w.r.t. header-guard detection)
  - lproven 3y ago
    You said: > pretty much every compiler since the 90s has support for `#pragma once` I asked for examples. Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next. Inferno is Unix 3.0. It's what they did after Plan 9. Tweaks to the project that they had moved on from (or clones thereof, e.g. Linux) are not particularly interesting or relevant in this context, IMHO.
    - GabrielTFS 3y ago
      > Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next. You want me to cite compilers that don't compile C that support a C extension ? And you want the language it compiles to be completely unrelated to C ? Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes (I guess maybe something like cmd.exe (...though it's an interpreter, not even a compiler) or some assembler written entirely in assembly - I think there's a few I've seen for Windows (though an assembler isn't typically considered much of a compiler) or something like that ? Does Windows even count as "not Unix-like" ? Does Wine mean it runs on Unix-like OSes ?) This just makes your criteria seem like it can't match any compiler at all, quite frankly, unless you're asking to trawl through truly ancient stuff from the 60s that I wouldn't even be able to test at all in the first place (since by the criteria you've given it must not be able to run on my laptop) Also, I'll add that you're likely to be correct in the most literal sense - I don't expect many compilers for languages that don't directly descend from C to include anything like `#pragma once`, because they're using a completely different model from C: almost no languages these days use "copy-paste" style file inclusion to handle libraries, and if they do anything like that, `#pragma once` is implied and never needs to be manually specified. But in practice, `#pragma once` allows C libraries headers to work just like in many other languages - they can freely include other libraries without forcing the user to do so themselves manually. Just imagine if you had to follow the Plan 9 C scheme on other languages, imagine if everyone that did `import argparse` in Python had to then add `import os`, `import re`, `import gettext`, `import warnings` and `import sys` because `argparse` can't do it itself without fear of double inclusion (...and then you'd also have to manually add `import abc`, `import stat`, `import enum`, `import functools`, `import unicodedata`, `import copyreg`, `import posix`, `import posixpath`, `import nt`, `import ntpath`, `import subprocess`, `import io`, `import locale`, `import builtins`, `import linecache`, `import tracemalloc`, `import traceback`, `import types`, `import operator`, `import reprlib`, `import collections`, `import weakref`, `import typing`, `import genericpath`, `import pwd`, `import errno`, `import time`, `import signal`, `import threading`, `import contextlib`, `import fcntl`, `import msvcrt`, `import select`, `import selectors`, `import grp`, `import encodings`, `import tokenize`, `import fnmatch`, `import pickle`, `import itertools`, `import textwrap`, `import keyword`, `import atexit`, `import gc`, etc. as the nested dependencies of os/re/gettext/warnings/sys/etc.)... I can't imagine anyone would consider that a good thing.

lproven 3y ago

Oh really? Can you illustrate this with examples? Ones that are from outside of the Unix and C family, just to make it clear that we aren't talking about tweaks to old tools?

GabrielTFS 3y ago
Examples of what ? Also, what exactly do you mean by "outside of the Unix and C family" ? (note: if you want examples of compilers that have `#pragma once` then I don't know what to say because I'd be hard-pressed to name a compiler that does not support it - similar situation w.r.t. header-guard detection)
- lproven 3y ago
  You said: > pretty much every compiler since the 90s has support for `#pragma once` I asked for examples. Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next. Inferno is Unix 3.0. It's what they did after Plan 9. Tweaks to the project that they had moved on from (or clones thereof, e.g. Linux) are not particularly interesting or relevant in this context, IMHO.
  - GabrielTFS 3y ago
    > Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next. You want me to cite compilers that don't compile C that support a C extension ? And you want the language it compiles to be completely unrelated to C ? Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes (I guess maybe something like cmd.exe (...though it's an interpreter, not even a compiler) or some assembler written entirely in assembly - I think there's a few I've seen for Windows (though an assembler isn't typically considered much of a compiler) or something like that ? Does Windows even count as "not Unix-like" ? Does Wine mean it runs on Unix-like OSes ?) This just makes your criteria seem like it can't match any compiler at all, quite frankly, unless you're asking to trawl through truly ancient stuff from the 60s that I wouldn't even be able to test at all in the first place (since by the criteria you've given it must not be able to run on my laptop) Also, I'll add that you're likely to be correct in the most literal sense - I don't expect many compilers for languages that don't directly descend from C to include anything like `#pragma once`, because they're using a completely different model from C: almost no languages these days use "copy-paste" style file inclusion to handle libraries, and if they do anything like that, `#pragma once` is implied and never needs to be manually specified. But in practice, `#pragma once` allows C libraries headers to work just like in many other languages - they can freely include other libraries without forcing the user to do so themselves manually. Just imagine if you had to follow the Plan 9 C scheme on other languages, imagine if everyone that did `import argparse` in Python had to then add `import os`, `import re`, `import gettext`, `import warnings` and `import sys` because `argparse` can't do it itself without fear of double inclusion (...and then you'd also have to manually add `import abc`, `import stat`, `import enum`, `import functools`, `import unicodedata`, `import copyreg`, `import posix`, `import posixpath`, `import nt`, `import ntpath`, `import subprocess`, `import io`, `import locale`, `import builtins`, `import linecache`, `import tracemalloc`, `import traceback`, `import types`, `import operator`, `import reprlib`, `import collections`, `import weakref`, `import typing`, `import genericpath`, `import pwd`, `import errno`, `import time`, `import signal`, `import threading`, `import contextlib`, `import fcntl`, `import msvcrt`, `import select`, `import selectors`, `import grp`, `import encodings`, `import tokenize`, `import fnmatch`, `import pickle`, `import itertools`, `import textwrap`, `import keyword`, `import atexit`, `import gc`, etc. as the nested dependencies of os/re/gettext/warnings/sys/etc.)... I can't imagine anyone would consider that a good thing.