No, the language of the standard carefully omits talking about files. This is because there are still ancient mainframe operating systems around that do not have typical hierarchical filesystems, but it is still technically possible to provide a C++ implementation for these. Prescribing a module name to file name mapping woukd not work in these environments either. This is also why #pragma once was rejected and the replacement #once [unique ID] was invented instead: just defining what is and isn't the same file for #pragma once turned out too difficult to define.

What I don't get though is why these ancient mainframes need the latest version of the standard. I can't imagine the compiler writers for these OSs to be too eager implement any change at all. You said "technically possible", are you implying that nobody actually does? What are these OSs?

To me this seems like a weird take on accessibility. In order to accommodate that one OS that has some serious disabilities, everyone else has to suffer the consequences. Why not build a ramp for that one OS, and build stairs for everyone else?

IBM has multiple people in the standard committee and they care a lot for both backward compatibility and new standards. They alone were strongly opposed from removing trigraphs from the standard.

Still trigraphs were removed in the end; if there is enough support the committee is willing to break backward compatibility.

>just defining what is and isn't the same file for #pragma once turned out too difficult to define.

Admittedly that's not just a problem with old mainframes. Any system supporting file aliases (be it hardlinks, symlinks or the same FS mounted at several locations for instance) would be tricky to handle.

I always thought #pragma once was a bad idea for that reason, header guards with unique IDs don't require any compiler magic and are simple to reason about without having to read the standard or compiler's docs to figure out how it operates.

That's handled by the preprocessor. It's literally just a "insert the contents of that file here" copy-paste.

But the preprocessor is part of the C++ standard, no? I'm really not seeing why it's ok for the preprocessor to refer to files but not the language.

Also, going to this level of trouble to support systems that don't have files seems... odd. Targets that don't have files, that I can totally understand. But compiler toolchains that don't have the notion of a file? That sounds obscure beyond obscure. I'm surprised such a system would be a compilation host instead of a cross-compile target.

We are talking about a language that goes so far as to make sure it functions on systems where the size of a byte is not 8, or where memory is not necessarily linearly addressed. People tend to forget how shockingly flexible standard-compliant C++ code actually is.

I get that, but there's also precedent for cutting ancient things loose. Both C and C++ have finally decided to specify that signed integers are two's complement: https://twitter.com/jfbastien/status/989242576598327296?lang... Also trigraphs are gone in C++17.

This C++ code actually compiles with clang++. Incredible!

    int main(int argc, char *argv<::>)
    <%
        if (argc not_eq 1 and argc not_eq 2) <% return 1; %>
        return 0;
    %>

https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C

Digraphs are still a part of the language. I would be more surprised if a conformant piece of code did not compile with a conformant compiler.

Trigraphs are gone, but it took a while to win IBM representatives over it

I don't think they were ever really won over, I think their concerns were heard and they begrudgingly acquiesced rather than vote down C++17.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n421...