What's your opinion on this argument of mine?

[Austin J]

Recently I was discussing get functions, for bools mainly. I actually got in an argument with this person on how you should return a boolean value, and a bit into how you should return value in general.

I say if you want to return, say a bool named isFat, you should approach it like this.

Foo::isFat()
{
    if(Foo::_isFat==true)
    {
        return true;
    }
    return false;
}

They said, and I quote, "Why? That's just stupid extra work, with a bool you can just return it and it will equal true or false."

To them the proper way is

Foo::isFat()
{
    return Foo:_isFat;
}

Note, this isn't a get function though as in get the variable and access it, I tried explaining this. If all you want to know is whether or not Foo is fat, then why the hell would you return the variable, even if it's not a reference? Do it my way you know it's just returning a literal value, and that's all it's good for. Their method could have it's purpose misunderstood and applied improperly. They're convinced though that just because their way takes a few less lines, it's the "better" way.

So as you can see we weren't even really arguing about a get function, however
that seems to be what they thought.

Then we argue a bit about get functions in general. Apparently they think that you should always just return that variable (sometimes you should return it of course) and it doesn't matter you can't actually change it unless you're returning a reference or pointer. Really does this person have no sense of safety? I'm not you're doing bad programming if you just return it, sometimes you just need to do that, it all depends on the situation. Obviously you can't always make a return statement based on a conditional branch. If you have a program calculating where the moon will be at a given time, then obviously you have a huge series of values passing around and you just have to. You still can apply safety barriers though. I.e if you don't need to worry about keeping a reference to what a function returns, then why not just return a copy that will be removed from that stack once it's finished?

I'm not saying what they think is right is always wrong, sometimes that's what you need to do, but I'm highly irritated by how they seemingly won't acknowledge other more proper ways for different scenarios.

[cire]

First, let's get the function signature right:

bool Foo::isFat() const;

Assuming Foo::isFat returns a boolean value, both functions should compile to the same code with optimizations, however yours is way more verbose than it needs to be. Given the return type we know that whatever we return, if it's type is not already bool, will be converted to a boolean value if possible (otherwise you'll end up with an error and it won't compile.)

And so:

bool Foo::isFat() const
{
    return _isFat ;
}

should be as obvious as:

bool Foo::isFat() const
{
    return _isFat == true ; 
    // or return _isFat == true ? true : false ;
}

which is what your code boils down to.

[Disch]

I agree with your friend. The extra conditional here does nothing but add additional, unnecessary code. It does not clarify anything.

If all you want to know is whether or not Foo is fat, then why the hell would you return the variable, even if it's not a reference?

I don't understand this question. The function returns a bool. So what difference does it make if you copy the bool from a variable or from a literal value?

Do it my way you know it's just returning a literal value

Returning a literal value is meaningless. The function returns a bool. Where that bool comes from doesn't matter because it's copied as part of the return process.

Really does this person have no sense of safety?

I really fail to see how your version is any safer. Or how there's any advantage to it at all. Can you clarify? Like perhaps give an example of where your friend's version could be misused?


EDIT: ninja'd by cire.

[Thumper]

What cire said.

And in regards to the following:

they think that you should always just return that variable and it doesn't matter you can't actually change it unless you're returning a reference or pointer

That's the entire purpose of accessor functions. You don't want to be able to change the variable with a get function. If you want the user to be able to change it you would create a sister set function.
Accessor functions allow you to control what a user can and cannot change about a class, so I can't imagine why you would return a nonconst reference of anything with a get function.

[Disch]

To put this in perspective...

int myclass::getFoo()
{
   if(foo == 1)  return 1;
   if(foo == 2)  return 2;
   if(foo == 3)  return 3;
   if(foo == 4)  return 4;
   //...
}

vs

int myclass::getFoo()
{
    return foo;
}

You can obviously see why that first version is absurd. Yet this is exactly what you're doing with your bool.

Why treat bools different from the way you'd treat any other type?

[Lachlan Easton]

if you don't need to worry about keeping a reference to what a function returns, then why not just return a copy that will be removed from that stack once it's finished?

Do you mean like

bool Foo::isFat() const
{
    return _isFat ;
}

?

[Austin J]

Yeah, point I want to make Disch I never said it was a good idea to do

int myclass::getFoo()
{
   if(foo == 1)  return 1;
   if(foo == 2)  return 2;
   if(foo == 3)  return 3;
   if(foo == 4)  return 4;
   //...
}

I did state that you can't do that, in case you just skimmed ;)

I know both ways work, it's just that in the scenario you don't want the function to return something modifiable that could be mistaken as such, his way could be worse. Although neither of us thought of const for this, (neither of us have much experience). I'm assuming if you add the const into the fray a compiler will always tell you that you're trying to modify a non modifiable value. So in that case yes my way is stupid extra work.

So I'll keep const return in mind gentlemen ;)

[Disch]

I did state that you can't do that, in case you just skimmed ;)

Alright I reread it and see where you said that now. Whoopsie. ^^

it's just that in the scenario you don't want the function to return something modifiable that could be mistaken as such

But that's determined by the return type of the function... not whether or not you return a literal value from the function. I'm still confused.

 bool Foo::isFat();
// ^
// |
// returning a bool.  Doesn't matter how isFat returns its value.  Const or
//  not, the original boolean owned by the class will not be modifiable. 

Returning by value means a copy is returned. So I don't see the point in creating yet another copy in the function itself.

[ne555]

if(Foo::_isFat==true)
lets assume that `Foo::_isFat' is a bool
you think that a bool is not good enough to be used in a condition, so you compare it against true
However, that operation would return a `bool', so the proper way is
if(Foo::_isFat==true==true==true==true==true==true==true==true/*ad nauseam*/)

If `Foo::_isFat' is not a bool, then that statement is error prone


> but I'm highly irritated by how they seemingly won't acknowledge
> other more proper ways for different scenarios.
yes, that's hideous.