Thread: Bool returning function gives me a non binary value

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;
}

Originally Posted by Elkvis

I'm having trouble locating the relevant section in the standard, but I suspect that the values for bool, beyond what the standard says in 4.12, are implementation defined.

You suspect wrongly:

Originally Posted by C++11 Clause 3.9.1 Paragraph 6

Values of type bool are either true or false.47 [ Note: There are no signed, unsigned, short, or long bool types or values. —end note ] Values of type bool participate in integral promotions (4.5).

Originally Posted by jimblumberg

True but Section 4.7 doesn't really tell you much IMO.
Section 4.7 Integral conversions.
(...)
So it seems important to know if bool is signed or unsigned, and how many bits the bool can contain. Depending on how bool on the system in question is defined the conversion from an int to a bool could lead to an implementation defined value.

As 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."

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:

Originally Posted by C++11 Clause 22.4.2.2.2 Paragraph 6 (part)

If (str.flags() & ios_base::boolalpha) == 0 returns do_put(out, str, fill, (int)val)

... which means the answer is yes

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.

Originally Posted by laserlight

You suspect wrongly

yes. I corrected myself in a later post.

Originally Posted by std10093

Sirplattelbot, that's not the case. These are uninitialized variables!

Here is the function's missing part, which, eventually is executed once.

[snip]

So, our result from this, is that the when printed, the bool value is not guaranteed to be binary?

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...

Originally Posted by std10093

Here is the function's missing part, which, eventually is executed once.

Code:

bool Quadtree::pointInside(node*& node, const Point3d& p)
{
    if(!node->child[0]) // Is node a leaf?
    {
        bool bla = pointInLeaf(node, p);
        std::cout<< "here2 |" << bla <<"|" << std::endl;
        return bla;
    }
    std::cout<< "entered " << std::endl;
    if(!node->child[7]) std::cout << "NULL" << std::cout; // This is NOT null
    pointInside(node->child[0 + (p.x() >= node->split.x())        // The index results to 7
        + 2 * (p.y() >= node->split.y())
        + 4 * (p.z() >= node->split.z())], p);
}

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.

Originally Posted by SirPrattlepod

Saying something is undefined behaviour, without demonstrating what that undefined behaviour is, is a cop out.

Then why don't you do it? >_<
Besides, people are expected to do some searching and research on their own. A simple google on undefined behaviour should yield lots of results.

Originally Posted by SirPrattlepod

Is it beyond the capability of everyone here to produce a test case?

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

Saying something is undefined behaviour, without demonstrating what that undefined behaviour is, is a cop out.

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.

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.

Originally Posted by SirPrattlepod

I did. I asked the OP if my code produced any unexpected behaviour (it has undefined behaviour in it) but so far no response.

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!

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!
   ....
}

Output:

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!

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.

Originally Posted by std10093

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.

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?