81–90 of 108 posts
Earlier quoted context omitted.
> I mean, it’s non-standard. What more do you need? so are most programming languages used in the world. In practice, #pragma once is less trouble than #ifdef ; we had the debate just today in reddit :-) https://www.reddit.com/r/cpp/comments/a14o5q/real_world_prob...
"#pragma once" used to cause GCC to launch a game of Tetris instead of compiling your code. Not super relevant today, but a fun fact.
I don’t particularly like the style guide either, but the reasons presented here aren’t great: > GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, #pragma once is non-standard but widely supported. I mean, it’s non-standard. What more do you need? > Although GSG does not forbid them categoricaly, it says to “Avoid using forward declarations where possible”. The example provided is like the one pla…
it is also less bugprone in the real world. There are cases where it doesn't work, but they amount to stupid things that nobody does outside of contrived examples. I switched our codebase after finding several variations of #ifdef message_h #define massage_h That potential bug existed in our code base for years (I checked history)
The error could be diagnosed by the compiler---submit a patch to gcc!
That is to say, if the following pattern occurs around the content of the file:
#ifndef
#define
#endif
Note that GCC already looks for this pattern and optimizes it! That has been implemented for ages; probably twenty years if not more. See here:
https://gcc.gnu.org/onlinedocs/cpp/Once-Only-Headers.html
That optimization must have a check in place that it's the same symbol in both places. And so that piece of code which checks can probably be augmented to emit a warning fairly easily.
A sophisticated version of the warning would only kick in if the symbols appear to be similar (e.g. close by Levenschtein distance) so that one of them is plausibly a typo for the other.
Another solution is to have a commit hook which looks for such a problem: it enforces the include guard on headers, and checks that the symbols match.
Earlier quoted context omitted.
Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double-inclusion.
You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces. As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.
You could say that. I didn't. Bolting on some sort of module system is just a totally different scope of enhancement than my modest proposal.
> As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.
That's just not true. It doesn't need to be robust against byzantine source trees and/or build systems to be defined in the C standard or to be useful. The standard can leave the concept of "the same file" implementation-defined, as it does many other concepts.
On Unix system C implementations, it is sufficient to use stat() and compare st_ino and st_dev against previously observed values for a given compilation unit. You do not need to checksum files. You especially do not need to write the specific behavior of checksumming header files into the C standard.
Earlier quoted context omitted.
Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double-inclusion.
Is it trivial to implement? The detailed semantics of #pragma once is murky. If #pragma once appears in a file, will that preclude an identical copy of the file from being included? Do we go by content, or just some filesystem identifier like device and inode number? Or the absolute path? Will #pragma once preclude that same file from being included again through a symbolic or hard link? Is the answer the same for al…
Yes.
https://github.com/llvm-mirror/clang/blob/799b6c6d7/lib/Lex/...
https://github.com/llvm-mirror/clang/blob/799b6c6d7/include/...
Does it work for them?
Speaking for myself as an engineer who works in that codebase, I rarely find it gets in my way, and when I've felt exceptions were the clearest/best approach, I've not found it burdensome or difficult to justify them.
It's ambiguous in the article, and it's not specifically mentioned in the Google C++ Style Guide, but during code review at Google it's likely that a reviewer will object to this code: std::vector v; v.resize(10, 42); That form of std::vector::resize is discouraged because nobody can remember which argument is which. A reviewer would probably prefer: std::vector v(10); std::fill(v.begin(), v.end(), 42); Or even std::…
You'd never see `v.resize(10, 42);` because 10 and 42 would be in self-documenting variables, e.g. ``` int kDefaultValue = 42; size_type kExpectedSize = 10; v.resize(kExpectedSize, kDefaultValue); ```
It seems like the author didn't read the guidelines very well. Especially this part: "The intent of this document is to provide maximal guidance with reasonable restriction. As always, common sense and good taste should prevail." There are good arguments for deriving from the guidelines in lots of situations, guidelines merely establish the default style, but don't prohibit code that does not follow the guidelines _i…
The author is complaining about the use of these guidelines in other places outside Google, especially for people who take these guidelines more seriously than Google itself.
Earlier quoted context omitted.
Is it trivial to implement? The detailed semantics of #pragma once is murky. If #pragma once appears in a file, will that preclude an identical copy of the file from being included? Do we go by content, or just some filesystem identifier like device and inode number? Or the absolute path? Will #pragma once preclude that same file from being included again through a symbolic or hard link? Is the answer the same for al…
> Is it trivial to implement? Yes. https://github.com/llvm-mirror/clang/blob/799b6c6d7/lib/Lex/... https://github.com/llvm-mirror/clang/blob/799b6c6d7/include/...
I don't think there is any good way to specify how this should behave for all the corner cases; but a given specification isn't hard to implement.
Earlier quoted context omitted.
Or even: C++11 - Cool, it's 2018, guess what: Migrating a codebase as large as Google's from C++11 to C++1x is a bunch of work. And a lot of the C++1x goodies are library additions, available in Abseil " rel="nofollow">https://github.com/abseil/abseil-cpp> .
This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.