Re: Pointer to the out of scope local variables

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Stuart Redmann" <DerTopper@xxxxxx> wrote in message
news:fhbu1c$lm4$1@xxxxxxxxxxxxxxx
Ulrich Eckhardt wrote:

K?r?at wrote:

As far as I know local variables are deleted when they go out of
scope.


They are destroyed, not deleted.


Well, but somtimes we need to return local variables address to the
caller.


I'd rather say no to that claim.


Is it valid to do so?


In pretty much any case the answer is "no", without even looking at the
code. Anyway, let's see...


struct 3D
{
int X;
int Y;
int Z;
};


No, not okay, '3D' is not a valid identifier, at least not in any of the
languages I would expect from the rest of the syntax. But well, let's
ignore this obvious error and assume it was a valid identifier.


3D * buildPoint (int nX, int nY, int nZ)
{
3D tmp;

tmp.X = nX;
tmp.Y = nY;
tmp.Z = nZ;

return &tmp;
}


1. You can return objects from functions.
2. Your function seems to do what C++ constructors are for.
3. You could allocate storage dynamically in a function and return a
pointer
to it if you don't want to copy the struct for whatever reason. This puts
the burden of cleanup on you though and generally you don't want that.

I think Ulrich had only had a quick look at the code so that he missed the
main error of it. It may be the case that a very experienced C++
programmer develops a kind of 'black spot' for the most fundamental
errors. Thus he probably saw the signature of buildPoint, saw the return
of a pointer, and jumped to the conclusion that you allocated the memory
for the return value _dynamically_. As

AFAICT, he already responded to that earlier in the post (it is never
acceptable to return a pointer to a local variable), so he started offering
alternatives.


this would be only bad style, the code you have actually posted is plainly
broken: You return a pointer that is not valid outside the function call
(any decent compiler would at least produce a warning). As the variable
'tmp' goes out of scope at the end of buildPoint, you must no longer use
it.

There are two alternatives: 1) Return a pointer to a dynamically allocated
object (using operator new), or 2) make the return type a non-pointer.
Alternative 2) is better than alternative 1) as alternative one violates
the informal rule that whoever allocates memory is responsible for
deleting it. In this particular case the funtion buildPoint would allocate
the memory but the calling function had to free the memory. If the caller
forgets to do so, you'll get a memory leak.

Regards,
Stuart


.

Relevant Pages

  • Re: Is There Any Reason to Even Use VC++ Anymore?
    ... If, for another reason, the calling function needs to allocate memory, ... It does this by taking a pointer to a ball object ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Memory management and allocation
    ... > As I'm writing a piece of code that basically acts as a server and ... > memory management is a topic that is quite crucial. ... Or can I just allocate the variable ... Nor is it usually necessary to set the pointer to ...
    (comp.lang.c)
  • Re: Virtual Machine implementation problem, Please help me to spot the bug
    ... I kept on getting error messages. ... You don't allocate enough memory here. ... Again conversions between pointer and integer types. ...
    (comp.lang.c)
  • Re: Advice on how to return a list of values
    ... The caller passes a pointer to a previously allocated array of 64 ... My function allocates the array and returns it. ... well allocate that much space and be done with it. ...
    (comp.lang.c)
  • Re: This is getting really weird.
    ... I thought 4 bytes for reference count and 4 for string length. ... > There should be no memory allocation for that line. ... > manager may allocate more space than requested for its own efficiency. ... > that New returned with a pointer to the string constant. ...
    (alt.comp.lang.borland-delphi)