|
Contains Acetone fucked around with this message at 17:39 on Jun 24, 2020 |
# ? May 10, 2013 23:41 |
|
|
# ? May 28, 2024 23:32 |
|
Plorkyeran posted:10 seconds on a 30 minute build with msvc. Importantly: 10 seconds slower with #pragma once.
|
# ? May 11, 2013 00:13 |
|
I don't really care myself which one is faster, I just wish they would standardize #pragma once and move on. The #ifdef include guards are cumbersome and error prone. I can't believe an elegant, one line solution like #pragma once is even a debate. All the poo poo they added to C++ 11 and they couldn't make this essential part of developing programs just a little bit easier is baffling. Someone submit a proposal for C++ 14 please. xgalaxy fucked around with this message at 02:40 on May 11, 2013 |
# ? May 11, 2013 02:37 |
|
MrMoo posted:Importantly: 10 seconds slower with #pragma once. We might be looking at two different runs, but the original data that drove the inclusion of #pragma once was a ~1 minute speedup with it on Visual Studio.
|
# ? May 11, 2013 02:44 |
|
The #ifndef variant provides a convenient escape-hatch if there's some case where you really do want to re-include the header, which you can't do with #pragma once. So if you've got one of those cases in your codebase then you've got to either use include guards everywhere, or have this one file that does things completely different to the rest of your codebase.
|
# ? May 11, 2013 02:58 |
|
xgalaxy posted:The #ifdef include guards are cumbersome and error prone. The two reasons for removal from Chromium are firstly it being more error prone, and secondly not being faster. The "original data" for inclusion of #pragma once could not be reproduced and ends up a show piece for cargo culting.
|
# ? May 11, 2013 03:42 |
|
MrMoo posted:cargo culting I'll take "phrases that nobody actually uses correctly" for 400, Alex.
|
# ? May 11, 2013 05:05 |
|
I'd love to see a real world example where #pragma once is error prone that isn't a result of a compiler bug.
|
# ? May 11, 2013 06:56 |
|
Jabor posted:The #ifndef variant provides a convenient escape-hatch if there's some case where you really do want to re-include the header, which you can't do with #pragma once. So if you've got one of those cases in your codebase then you've got to either use include guards everywhere, or have this one file that does things completely different to the rest of your codebase.
|
# ? May 11, 2013 07:37 |
|
Plorkyeran posted:Or you could just not do that, since I can't think of any case where it would be legal to include a header twice yet sensible to have include guards that doesn't involve doing something incredibly stupid. One example would be where you have some file containing message definitions. Some other header file uses those to generate function declarations for stuff to do with the messages, while the corresponding implementation file uses them to generate definitions for those functions. The message definition file needs to be doubly-included in that particular implementation file, but should still be guarded for everywhere else.
|
# ? May 11, 2013 08:12 |
|
MrMoo posted:The two reasons for removal from Chromium are firstly it being more error prone, and secondly not being faster.
|
# ? May 11, 2013 09:49 |
|
If you're making errors while typing out an include guard then stop using computers
|
# ? May 11, 2013 12:53 |
|
Dicky B posted:If you're making errors while typing out an include guard then stop using computers Or use an IDE that will create them for you.
|
# ? May 11, 2013 13:32 |
|
Jabor posted:One example would be where you have some file containing message definitions. Some other header file uses those to generate function declarations for stuff to do with the messages, while the corresponding implementation file uses them to generate definitions for those functions. Uh? What you're doing sounds like X-Macros, and you can't really just include an X-Macros header at random. What's a concrete example when you imagine this?
|
# ? May 11, 2013 14:09 |
|
Suspicious Dish posted:Uh? What you're doing sounds like X-Macros, and you can't really just include an X-Macros header at random. What's a concrete example when you imagine this? When the header containing the message definitions also contains typedefs for various types used in the message, and you're explicitly including all headers that you rely on instead of depending on them being transitively included somewhere (which is a good idea for other reasons).
|
# ? May 11, 2013 14:28 |
|
That was a good concrete example. I love the double-definition of typedefs that surely won't end in an error.
|
# ? May 11, 2013 14:43 |
|
Only thing I could remotely think of would be something I saw awhile back that wouldn't use include guards *OR* pragma once: File.h: code:
code:
|
# ? May 11, 2013 14:50 |
|
While we're on this subject, is there a standard naming convention for include-guards to prevent library headers from fighting project headers? I've occasionally felt in danger of having a library that does a #define _FOO_H_ for one of its headers and then having a header file with the same name in the main project, which would result in whichever one of the two is included second not getting included at all, which would be horrific to debug if it happened by surprise.
|
# ? May 11, 2013 14:55 |
|
Hughlander posted:Only thing I could remotely think of would be something I saw awhile back that wouldn't use include guards *OR* pragma once: Jabor posted:The message definition file needs to be doubly-included in that particular implementation file, but should still be guarded for everywhere else.
|
# ? May 11, 2013 14:56 |
|
Hughlander posted:Only thing I could remotely think of would be something I saw awhile back that wouldn't use include guards *OR* pragma once: Yeah, this is known as "X-Macros", and normally doesn't have any include guards.
|
# ? May 11, 2013 14:59 |
|
roomforthetuna posted:While we're on this subject, is there a standard naming convention for include-guards to prevent library headers from fighting project headers?
|
# ? May 11, 2013 14:59 |
|
Dicky B posted:If you're making errors while typing out an include guard then stop using computers
|
# ? May 11, 2013 15:03 |
|
Jabor posted:One example would be where you have some file containing message definitions. Some other header file uses those to generate function declarations for stuff to do with the messages, while the corresponding implementation file uses them to generate definitions for those functions. I would file that under "incredibly stupid". Just split the things that need to be doubly-included into a separate file that isn't include-guarded rather than being ~clever~.
|
# ? May 11, 2013 15:07 |
|
Suspicious Dish posted:That was a good concrete example. I love the double-definition of typedefs that surely won't end in an error. But defining the same typedef twice doesn't result in an error.
|
# ? May 11, 2013 17:01 |
|
FamDav posted:But defining the same typedef twice doesn't result in an error. http://codepad.org/sU0wPJlo ?
|
# ? May 11, 2013 17:50 |
|
Dicky B posted:I think the onus is on the library writer to do something sensible like _LIBRARYNAME_FOO_H. Don't start with an underscore. Global names that begin with _ are reserved (also names that begin with _ followed by a capital letter are reserved everywhere, and so are names that contain a double underscore).
|
# ? May 11, 2013 17:59 |
|
roomforthetuna posted:While we're on this subject, is there a standard naming convention for include-guards to prevent library headers from fighting project headers? The Chromium project uses directory names as a prefix, separated by underscores. Example: http://src.chromium.org/svn/trunk/src/base/atomicops_internals_atomicword_compat.h #ifndef BASE_ATOMICOPS_INTERNALS_ATOMICWORD_COMPAT_H_
|
# ? May 11, 2013 19:52 |
|
Sorry, I thought yall were talking about C++ for some reason. EDIT: though it's going to work like C++ in C11, apparently. FamDav fucked around with this message at 20:31 on May 11, 2013 |
# ? May 11, 2013 20:15 |
|
Suspicious Dish posted:I'll take "phrases that nobody actually uses correctly" for 400, Alex. It's cargo cult copying when you see poo poo like this: code:
|
# ? May 11, 2013 23:04 |
|
MrMoo posted:Importantly: 10 seconds slower with #pragma once. I can't speak for Chromium (yet), but our internal codebase at work did show a small improvement (MSVC; we didn't test GCC) with #pragma once. Not much more than 1% of the total clean build time, but hey everything helps.
|
# ? May 12, 2013 01:33 |
|
MrMoo posted:It's cargo cult copying when you see poo poo like this: That's not actually how #pragma once was used in Chromium. ??
|
# ? May 12, 2013 07:01 |
|
On my current compiler and architecture, chars are 8-bit, shorts are 16-bit, ints and pointers are 32-bit, long longs and doubles are 64-bit, and floats/longs/pointers are 32 or 64 depending on whether I'm compiling in 32-bit or 64-bit. Are these sizes consistent or guaranteed in any way across modern compilers/architectures? Sorry, I'm sure this is an obvious question, but I'm not really sure what to google for. Ciaphas fucked around with this message at 00:38 on May 15, 2013 |
# ? May 15, 2013 00:33 |
|
The standards only guarantee minimum sizes, and not necessarily useful minimum sizes at that. However, practically speaking, char will always be eight bits, short will be 16, int will be 32, and long long will be 64. long is not portable across architectures or compilers. The floating-point types are generally portable except on weird systems (not including long double). However, to the extent that you care about exact sizes, you should be using typedefs like uint32_t.
|
# ? May 15, 2013 00:46 |
|
Buggery. I knew about things like size_t but had no idea there were typedefs for precisely-sized definitions like that. It's terrible how much basic stuff I don't know, I hesitate to imagine how much of my code would end up in the Horrors thread if it had the chance. Oh well, thanks much.
|
# ? May 15, 2013 00:50 |
|
Well what are you doing that requires this kind of information?
|
# ? May 15, 2013 00:52 |
|
Lots and lots (and lots) of what amounts to file format conversions, basically. It's all worked so far since we've only targeted one platform (namely, ours--SunCC/SunOS/SPARC) but with the eventual (like, 2+ years out) move to g++/Linux/Intel I've been checking out possible portability issues left and right, and this one occurred to me suddenly.
|
# ? May 15, 2013 02:38 |
|
I have a quick question regarding some logic I have written. It's my first C program, and it's a guess the number game in the console. I wrote the following code to prompt the player if they wanted to play again, and to continually do so until they either typed 'y' (121) or 'n' (110).code:
Am I misunderstanding something fundamental about logic here?
|
# ? May 15, 2013 09:56 |
|
Morham posted:I have a quick question regarding some logic I have written. It's my first C program, and it's a guess the number game in the console. I wrote the following code to prompt the player if they wanted to play again, and to continually do so until they either typed 'y' (121) or 'n' (110). What's the difference between code:
code:
|
# ? May 15, 2013 10:02 |
The do..while loop continues until the condition becomes false. The != operator is false when the operands are equal. The || operator is false only when both operands are false. If input!=121 is false then input must be equal to 121, and then input!=110 can't also be false. Therefore your condition with || could never become false. Another thing, use character constants instead of numeric constants. You can write input!='y' and get the same behavior as with input!=121, but the former is much clearer about your intention. Remember that character constants (single characters enclosed in single quotes) are a fancy way of writing integer constants, but express different intentions to a human reader. Lastly, a good rule to learn is this: If X and Y are boolean expressions, then !(X&&Y)==(!X||!Y), and conversely !(X||Y)==(!X&&!Y). (It has a name which I forgot.)
|
|
# ? May 15, 2013 10:10 |
|
|
# ? May 28, 2024 23:32 |
|
Also please don't use magic numbers.C++ code:
|
# ? May 15, 2013 10:11 |