0

let's imagine a simple class such as this:

class Foo {
public:
    Foo(int b) : bar(b) {}
    int bar;

    friend bool operator==(const Foo& l, const Foo& r); 
};

bool operator==(const Foo& l, const Foo& r) {
    return l.bar == r.bar;
}

I'm having a weird behaviour with the operator== where comparing an object with another with the same bar value doesn't return true.

To understand, consider this code:

Foo& findRef(int barToFind); //Assume those functions works correctly
Foo findCopy(int barToFind);

Foo f1(1);

Foo& fRef = findRef(1);
Foo fCopy = findCopy(1);

f1 == fRef; //Will evaluate to false
f1 == fCopy; //Will evaluate to true

Why is that? Did I miss something? This code was tested on Visual Studio 2013.

Thank you

Edit: Provided is the findRef function. The findCopy is exactly the same, except it doesn't return a reference. MyArray is assured to live for the duration of the program.

Foo& findRef(int bar) {
    //MyArray of type std::vector<Foo>
    auto it = std::find_if(std::begin(MyArray), std::end(MyArray), [=](const Foo& f){ return f.bar == bar; });
    assert(it != std::end(MyArray));

    return *it;
}
Rosme
  • 1,049
  • 9
  • 23
  • 6
    I don't think we *can* assume that function works correctly. I think you have [undefined behaviour](http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope). – chris Jul 30 '14 at 18:56
  • @chris I can still access all methods and variable of those classes. It basically find just an object in an array and return it. Verified by an assert. – Rosme Jul 30 '14 at 18:58
  • 4
    You don't have me convinced. Undefined behaviour can "work", and often does. – chris Jul 30 '14 at 18:59
  • @chris I provided the findRed method if you'd like. – Rosme Jul 30 '14 at 19:03
  • Okay well that should work as long as `MyArray` lives long enough. – chris Jul 30 '14 at 19:05
  • 2
    You probably return a reference to a locally defined object and all bets are off. To convince yourself, declare `const Foo& fRef = findRef(1);`, you can bound const references to temporaries and keep the temporary alive. Your code will probably work. – vsoftco Jul 30 '14 at 19:06
  • 1
    Seeing `Foo f1(1);`: You messed up constructors/assignment of Foo –  Jul 30 '14 at 19:07
  • 1
    This almost certainly points to the value returned by reference from ``findRef`` not staying alive and this giving you undefined behavior. – aruisdante Jul 30 '14 at 19:07
  • @chris It does live long enough. It dies with the end of the program. – Rosme Jul 30 '14 at 19:07
  • 1
    We need to see more code to find the problem. There are a lot of good guesses above, and any one of them might be the issue. Logging `f1.bar`, `fRef.bar`, and `fCopy.bar` might help. – David Schwartz Jul 30 '14 at 19:07
  • 1
    Also, this can be very easily tested by simply printing out the value of ``fRef.bar`` and seeing if it's what you expect it to be, unless of course this is a very simplified example and that's not a practical thing to do. – aruisdante Jul 30 '14 at 19:09
  • @DieterLücking I added the constructor, just forgot to put it originally. Logging the value all gives me 1. – Rosme Jul 30 '14 at 19:11
  • 1
    Running it on ideone with C++11 output both to true. Might be a bug in VS2013? See http://ideone.com/baDde5 – Rosme Jul 30 '14 at 19:15
  • @Rosme I am running VS2013 Update 1, and running your code prints `true` for both. – PaulMcKenzie Jul 30 '14 at 19:39
  • @PaulMcKenzie Odd...all I can think is that there is something wrong in the rest of my code. I'm going to be searching and try to find the source. Most probably some UB for some reason. – Rosme Jul 30 '14 at 19:54
  • Please post a complete runnable program that reproduces the bug. – n. m. could be an AI Jul 31 '14 at 02:43
  • @n.m. I can't. I'll dig more into my code. I definitely have something wrong in my code that causes this odd behaviour. (Unrelated directly, but should I just delete this question since it doesn't seem to be what I thought it was?) – Rosme Jul 31 '14 at 02:53

0 Answers0