standards

Why will std::sort crash if the comparison function is not as operator <?

狂风中的少年 提交于 2019-11-26 14:44:34
The following program is compiled with VC++ 2012. #include <algorithm> struct A { A() : a() {} bool operator <(const A& other) const { return a <= other.a; } int a; }; int main() { A coll[8]; std::sort(&coll[0], &coll[8]); // Crash!!! } If I change return a <= other.a; to return a < other.a; then the program runs as expected with no exception. Why? xorguy std::sort requires a sorter which satisfies the strict weak ordering rule, which is explained here So, your comparer says that a < b when a == b which doesn't follow the strict weak ordering rule, it is possible that the algorithm will crash

Is `long` guaranteed to be at least 32 bits?

ぃ、小莉子 提交于 2019-11-26 14:31:37
By my reading of the C++ Standard, I have always understood that the sizes of the integral fundamental types in C++ were as follows: sizeof(char) <= sizeof(short int) <= sizeof(int) <= sizeof(long int) I deduced this from 3.9.1/2: There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment Further, the size of char is described by 3.9.1/ as being: [...] large enough to store any

C/C++ int[] vs int* (pointers vs. array notation). What is the difference?

孤街醉人 提交于 2019-11-26 14:29:07
I know that arrays in C are just pointers to sequentially stored data. But what differences imply the difference in notation [] and *. I mean in ALL possible usage context. For example: char c[] = "test"; if you provide this instruction in a function body it will allocate the string on a stack while char* c = "test"; will point to a data (readonly) segment. Can you list all the differences between these two notations in ALL usage contexts to form a clear general view. Sergey K. According to the C99 standard: An array type describes a contiguously allocated nonempty set of objects with a

Why do the CSS width and height properties not adjust for padding?

↘锁芯ラ 提交于 2019-11-26 14:16:44
问题 So first a bit of meat to set the scene: HTML <div id="container"> <div id="inner">test</div> </div> CSS #container { width:300px; height:150px; background-color:#d7ebff; } #inner { width:100%; height:100%; padding:5px; background-color:#4c0015; opacity:.3; } This will produce something that looks like this in all modern browsers: Now I know this is the standards-compliant behavior (as I knew before, but reconfirmed in this post, and I also know that if I include this code in the inner CSS

Why are nested functions not supported by the C standard?

天大地大妈咪最大 提交于 2019-11-26 14:08:25
问题 It doesn't seem like it would be too hard to implement in assembly. gcc also has a flag (-fnested-functions) to enable their use. 回答1: It turns out they're not actually all that easy to implement properly. Should an internal function have access to the containing scope's variables? If not, there's no point in nesting it; just make it static (to limit visibility to the translation unit it's in) and add a comment saying "This is a helper function used only by myfunc()". If you want access to

Are all integer values perfectly represented as doubles? [duplicate]

旧街凉风 提交于 2019-11-26 13:48:59
问题 This question already has an answer here: Representing integers in doubles 5 answers My question is whether all integer values are guaranteed to have a perfect double representation. Consider the following code sample that prints "Same": // Example program #include <iostream> #include <string> int main() { int a = 3; int b = 4; double d_a(a); double d_b(b); double int_sum = a + b; double d_sum = d_a + d_b; if (double(int_sum) == d_sum) { std::cout << "Same" << std::endl; } } Is this

is size_t always unsigned?

☆樱花仙子☆ 提交于 2019-11-26 13:48:22
问题 As title: is size_t always unsigned, i.e. for size_t x , is x always >= 0 ? 回答1: Yes . It's usually defined as something like the following (on 32-bit systems): typedef unsigned int size_t; Reference: C++ Standard Section 18.1 defines size_t is in <cstddef> which is described in C Standard as <stddef.h> . C Standard Section 4.1.5 defines size_t as an unsigned integral type of the result of the sizeof operator 回答2: According to the 1999 ISO C standard (C99), size_t is an unsigned integer type

C++ Static member method call on class instance

风格不统一 提交于 2019-11-26 13:21:26
Here is a little test program: #include <iostream> class Test { public: static void DoCrash(){ std::cout<< "TEST IT!"<< std::endl; } }; int main() { Test k; k.DoCrash(); // calling a static method like a member method... std::system("pause"); return 0; } On VS2008 + SP1 (vc9) it compiles fine: the console just display "TEST IT!". As far as I know, static member methods shouldn't be called on instanced object. Am I wrong? Is this code correct from the standard point of view? If it's correct, why is that? I can't find why it would be allowed, or maybe it's to help using "static or not" method in

Are constant C expressions evaluated at compile time or at runtime?

泪湿孤枕 提交于 2019-11-26 13:06:15
问题 If I write a #define that performs an operation using other preprocessor constants, is the final value computed each time the macro appears at runtime? Does this depend on optimizations in the compiler, or is it covered under a standard? Example: #define EXTERNAL_CLOCK_FREQUENCY 32768 #define TIMER_1_S EXTERNAL_CLOCK_FREQUENCY #define TIMER_100_MS TIMERB_1_S / 10 Will the operation 32768 / 10 occur at runtime every time I use the TIMER_100_MS macro? I would like to avoid the following:

git: change styling (whitespace) without changing ownership/blame?

十年热恋 提交于 2019-11-26 13:05:22
问题 We have a massive, ancient codebase that needs a lot of cleanup. We have always had coding standards and everyone has always tried to follow them, but they were not enforced so over time a lot of violations have creeped in. Many of them are just whitespace issues, like using tabs instead of spaces, or spaces where there shouldn\'t be any, or missing spaces where they should be. We are going to start actively enforcing our coding standards to make sure more violations don\'t creep in, but it\