Returning Automatic Variables from Functions

jabney · November 29th, 2008, 04:22 AM

I have just a bit of minor confusion.

I was under the impression that any variable that was created within the body of a function would go out of scope after the function returned.

Specifically in Chapter 5 pages 265 and 268, we are warned:

Never ever return the address of a local automatic variable from a function.

Never ever return a reference to a local variable from a function.

I've been operating under the impression that automatics simply shouldn't ever be returned from functions, but apparently this only applies to pointers and references to automatics.

In chapter 14 we're told to build the GetBoundRect() function like this:

Code:

CRect CElement::GetBoundRect()
{
     CRect BoundingRect;
     BoundingRect = m_EnclosingRect;
     BoundingRect.InflateRect(m_Pen, m_Pen);
     return BoundingRect;
}

So here were returning an automatic from a function and there's no problem. The only thing I can figure is that the automatic variable BoundingRect is copied as it's being returned, and that the automatic within the function body really does go out of scope.

Is this correct, or could someone give me a better idea if how this is working? I suppose I'm answering my own question. An automatic can be returned from a function, as long as it's not a pointer or a reference.

Old Pedant · November 29th, 2008, 07:32 PM

Even without seeing the code for class CRect, I would guess that it has (at a minimum) a copy constructor and so, yes, your assumption that a copy of the local variable is returned would be correct.

Actually, you can be pretty sure it has both a copy contstructor and an assignment operator (that is, operator =), since we see the line
BoundingRect = m_EnclosingRect;
That almost surely is doing a member-wise copy of the data members of the m_EnclosingRect into the corresponding members of BoundingRect.

My C++ is a little rusty (it's been 8 years since I really used C++), but I vaguely recall that if you have an operator = defined for a class, then C++ will automatically use that to create a copy constructor for you. (And of course the default copy or assignment is just a bit-wise copy of all bytes, but that's often not the semantics you want.)

Not germaine to this question, but you can always return primitive values (e.g., int, float, etc.) from functions, however they are declared, because all primitives have implicit copy constructor semantics.

Incidentally, if a class purposely does *NOT* have an operator = or a copy constructor, then no, you wouldn't be able to return an instance of it from a function by returning an automatic variable.

Let's see how much the people who are "up" on C++ tear up my answer.

jabney · November 29th, 2008, 09:56 PM

OP, thanks, that helps a lot. It makes perfect sense, I just needed to wrap my head around it and flush out the incorrect assumptions. I learn best visually, so descriptions of things don't always stick to my brain very well until I've come up against the concept in practice.

BTW, I think I remember Ivor mentioning that a class's copy constructors and assignment operators, if they're not explicitly defined, are generated by the compiler by default to create member-wise clones.

This would mean that any class without a copy constructor or assignment operator would get one anyway, which is why you want to create them manually in any situations where class members are assigned dynamic memory -- unless you actually wanted object instances to share the same memory for some reason.

Thanks again!