I still think something like the following is happenning:
I got 54 as a result of that.Code:#include<iostream> bool foo() { } int main() { std::cout<<foo(); }
Turn up your warnings.
I still think something like the following is happenning:
I got 54 as a result of that.Code:#include<iostream> bool foo() { } int main() { std::cout<<foo(); }
Turn up your warnings.
No, because of the here2 output.
As a matter of fact, here is the other function
Code:bool Quadtree::pointInLeaf(node*& leaf, const Point3d& p) { if(...) for(...) if( .. ) return false; return true; for(..) if( .. ) return false; return true; }
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
You suspect wrongly:Originally Posted by Elkvis
Originally Posted by C++11 Clause 3.9.1 Paragraph 6As I quoted above, bool is neither signed nor unsigned. You quoted, but seem to have missed, this part: "If the destination type is bool, see 4.12. If the source type is bool, the value false is converted to zero and the value true is converted to one."Originally Posted by jimblumberg
So, for a conversion from bool to an integer type, it is clear that the result must be either zero or one. It cannot be say, zero or two. However, as I noted earlier, I was not sure if when printing a bool using formatted output but without boolalpha, if the result is required to be as if the bool was converted to int. But, thanks to your boolalpha hint, I found:
... which means the answer is yesOriginally Posted by C++11 Clause 22.4.2.2.2 Paragraph 6 (part)
Therefore, I'm even more certain that we're looking at the result of undefined behaviour in std10093's code, not some implementation defined thing. std10093 apparently has ruled out one possibility of undefined behaviour raised by SirPrattlepod, so presumably more searching for the bug is in order.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yes, I knew it probably wouldn't be the case. I was trying to reproduce your observation with a test case and couldn't. So I was wondering if my test case produced anything unusual or unexpected using your compiler and environment.
Using my compiler, the test case I presented printed nothing unexpected even when the variable wasn't initialised...
Last edited by SirPrattlepod; 08-21-2013 at 07:00 PM.
I suspect it is a case of undefined behaviour. You'll note that with this code it can fall off the end without returning a value. Now consider that just because it isn't going down that path, that this does not mean that the function must behave correctly when it goes down the other path.
I expect that NRVO is occurring. This is generally only achievable where every return point simply returns the same variable. You'll note that here however, that this criterion is satisfied. There are no other places that return a different variable, even though there should be.
So the result of the function is then presumably going to be determined by the pointInLeaf implementation which you have not shown.
I cant specifically account for the behaviour in the original post, but I'd guess that it's something about the way the NRVO optimises the code.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Is it beyond the capability of everyone here to produce a test case?
Saying something is undefined behaviour, without demonstrating what that undefined behaviour is, is a cop out.
It should be within std10093's capability to narrow down the code to produce a test case such that the program can be debugged.Originally Posted by SirPrattlepod
By definition, it is impossible to demonstrate undefined behaviour reliably. By chance, I might be able to reproduce the effects of the bug in std10093's code, but it may well be a test case that has nothing to do with the actual bug in std10093's code. Hence, the onus is on std10093, e.g., to come up with the smallest and simplest compilable program that demonstrates the problem.Originally Posted by SirPrattlepod
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
I agree mostly. The (partial) code presented is not a test case, though.
However, it is perfectly possible to create a test case that demonstrates undefined behaviour especially when current code appears to be doing so.
Last edited by SirPrattlepod; 08-22-2013 at 05:30 AM.
False. Look at post #20 please!
The bug I found, is that the nodes of the tree, all, except root have vectors with size zero, while I would expect them to be at least of size 3. But still, this does not explain the output of bool value with a non binary value.
>iMalc said: I cant specifically account for the behaviour in the original post, but I'd guess that it's something about the way the NRVO optimises the code
That's might be the reason!
Output:Code:bool Quadtree::pointInside(const Point3d& p) { bool a = pointInside(root, p); std::cout<< "here1 " << a << std::endl; return a; } bool Quadtree::pointInside(Node*& node, const Point3d& p) { if(!node->child[0]) // Is node a leaf? { bool a = pointInLeaf(node, p); std::cout<< "here2 " << a << std::endl; return a; } std::cout<<0 + (p.x() >= node->split.x()) + 2 * (p.y() >= node->split.y()) + 4 * (p.z() >= node->split.z()) << " = index\n"; // index is 7 printNode(node->child[7]); // Will print a node as expected, I have //filled the corresponding vector with some expected values pointInside(node->child[0 + (p.x() >= node->split.x()) + 2 * (p.y() >= node->split.y()) + 4 * (p.z() >= node->split.z())], p); } bool Quadtree::pointInLeaf(Node*& leaf, const Point3d& p) {return true; // I did this for testing! .... }
Code:7 = index -------------------------Node 0.5,-1,-1 Bounding box is: ( 0, -1, -1 ) - ( 1, 1, 1 ) vectorSize = 6 0 1 2 3 4 5 ------------------------- here2 1 <-- Since it's one here here1 80 <-- it should be one here as well!!!!!! 80 Polytope's destructor called!
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
Exactly, but in post #20 you have quoted my answer, the one that you claim in post #26 to Elysia, that you did not get.
>My question is does the code I pasted produce anything unexpected using your OS and compiler?
Redundant. Please refer to my answer for the reason of this redundancy.
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
Hold on: have you fixed this bug? When you say that you "expect them to be at least of size 3", does that mean that you were accessing the one or more or the first 3 elements of these vectors, even though they did not actually exist?Originally Posted by std10093
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)