undefined-behavior

问题 Turns out many innocently looking things are undefined behavior in C++. For example, once a non-null pointer has been delete 'd even printing out that pointer value is undefined behavior. Now memory leaks are definitely bad. But what class situation are they - defined, undefined or what other class of behavior? 回答1: Memory leaks. There is no undefined behavior. It is perfectly legal to leak memory. Undefined behavior: is actions the standard specifically does not want to define and leaves

问题 I have the following code: #include <iostream> #include <complex> using namespace std; int main() { complex<int> delta; complex<int> mc[4] = {0}; for(int di = 0; di < 4; di++, delta = mc[di]) { cout << di << endl; } return 0; } I expect it to output "0, 1, 2, 3" and stop, but it outputs an endless series of "0, 1, 2, 3, 4, 5, ....." It looks like the comparison di<4 doesn't work well and always returns true. If I just comment out ,delta=mc[di] , I get "0, 1, 2, 3" as normal. What's the

问题 I have written a simple, working tetris game with each block as an instance of a class singleblock. class SingleBlock { public: SingleBlock(int, int); ~SingleBlock(); int x; int y; SingleBlock *next; }; class MultiBlock { public: MultiBlock(int, int); SingleBlock *c, *d, *e, *f; }; SingleBlock::SingleBlock(int a, int b) { x = a; y = b; } SingleBlock::~SingleBlock() { x = 222; } MultiBlock::MultiBlock(int a, int b) { c = new SingleBlock (a,b); d = c->next = new SingleBlock (a+10,b); e = d-

问题 I have written a simple, working tetris game with each block as an instance of a class singleblock. class SingleBlock { public: SingleBlock(int, int); ~SingleBlock(); int x; int y; SingleBlock *next; }; class MultiBlock { public: MultiBlock(int, int); SingleBlock *c, *d, *e, *f; }; SingleBlock::SingleBlock(int a, int b) { x = a; y = b; } SingleBlock::~SingleBlock() { x = 222; } MultiBlock::MultiBlock(int a, int b) { c = new SingleBlock (a,b); d = c->next = new SingleBlock (a+10,b); e = d-

问题 If I have: unsigned int x; x -= x; it's clear that x should be zero after this expression, but everywhere I look, they say the behavior of this code is undefined, not merely the value of x (until before the subtraction). Two questions: Is the behavior of this code indeed undefined? (E.g. Might the code crash [or worse] on a compliant system?) If so, why does C say that the behavior is undefined, when it is perfectly clear that x should be zero here? i.e. What is the advantage given by not

问题 I had read the following rule and I've been trying to write an example, which reflects one. The rule is from 3.8/5 N3797: Before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that refers to the storage location where the object will be or was located may be used but only in limited ways. For an object

问题 main(){ int a = 5; int b = 6; printf("%d %d %d",a==b,a=b,a<b); } Output in my testing 1 6 1 In above program I am expecting output as 0 6 0 . In some compilers it is giving this output (e.g. Xcode) but where as in some other compilers it is giving output as 1 6 1 . I couldn't find the explanation . It is also the case of Sequence point. Consider this below program main(){ int a = 5; int b = 6; printf("%d %d %d",a<b,a>b,a=b); printf("%d %d",a<=b,a!=b); } Output in my testing 0 0 6 1 0 this

问题 Writing a library that works with function callbacks, I've frequently type-casted (and called) function pointers to types with the same calling convention and same signatures, but with one exception: they had parameters pointing to different types (all data), or void pointers. Recently, I discovered that it might not be that safe, according to this: https://stackoverflow.com/a/14044244/3079266 Basically, as I understood it, if the types of the arguments are compatible, that means the function

问题 I'm compiling a C++ program to run in a freestanding environment and the CPU I'm running on defines a 32-bit peripheral register to be available ( edit: memory-mapped ) at PERIPH_ADDRESS (aligned correctly, and not overlapping with any other C++ object, stack etc.). I compile the following code with PERIPH_ADDRESS predefined, later link it with a full program and run it. #include <cstdint> struct Peripheral { const volatile uint32_t REG; }; static Peripheral* const p = reinterpret_cast

问题 Discussion According to the standard §20.10.2/1 Header <type_traits> synopsis [meta.type.synop]: 1 The behavior of a program that adds specializations for any of the class templates defined in this subclause is undefined unless otherwise specified. This specific clause contradicts to the general notion that STL should be expandible and prevents us from expanding type traits as in the example below: namespace std { template< class T > struct is_floating_point<std::complex<T>> : std::integral