|
actually, x went out of scope, so the variable x is destroyed, but even if is x doesn't exist anymore, what you get with the pointer is the address at which x was stored...
so, yes, the memory occupied by x is released (so that any other memory request could use this space), but not overwritten, that means that the value persists until some write a new variable's value on it.
you musn't do the asumption that immediately when exiting your function, the caller can get the value pointed by x though
|
|
|
|
|
Well, there is only a big mistake: you're are returning a pointer to a temporary value, this you must never do, because calling code cannot consider reliable the pointer.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi CPallini,
Yes I agree with that and I was wondering why it still works.
How is the pointer returned? Is it copied with a copy constructor?
Thanks.
|
|
|
|
|
the address is returned by value... but why would you wind about this ?
|
|
|
|
|
As toxcct pointed out, it's returned by value.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
and as an idiot is roaming over here, all my posts today got voted 1 or 2 
|
|
|
|
|
Simply don't worry about.
Helping people it's more rewarding than getting high scores; unfortunately, idiots can be found everywhere, even here.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Let me explain what happens.
int x = 6;
creates a int variable on the stack and sets it to the value 6
int * ptr = &x;
creates a pointer to integer variable on the stack and sets the value to the stack address where x is located.
return ptr;
retuns to the calling function lowering the stack pointer to where it was before calling the function.
and returns the value of the pointer. The pointer is now addressing somewhere in the unused stack space. The values of the stack remain there until the are overwritten/needed for other variables, or other function calls.
In other words this is not a good practice and should never be used.
I don't know what you mean about the copy constructor, since int isn't a class so it doesn't have a copy constructor in the way you think.
codito ergo sum
|
|
|
|
|
Hi BadKarma
Thanks for that. Yes I thought it was bad practice to return an object on the stack in a function call.
With regards to the copy constructor, if I have a class alpha in the function
<br />
alpha * func()<br />
{<br />
alpha anything;<br />
alpha *ptr = &anything;<br />
return ptr;<br />
<br />
}<br />
<br />
how would it return ptr. Would it copy the pointer ptr using the copy constructor and then destroy it as the function goes out of scope?
Thanks.
|
|
|
|
|
you're doing the exactly same mistake...
your object "anything", whether it's an int or an alpha, is local to the function, so destroyed when getting out of space...
|
|
|
|
|
Hi ya
I know about the mistake of the object on the stack going out of scope.
I was questioning how it returns the pointer. It just copies the address and does not involve using copy constructors? Is that right ?
Thanks.
|
|
|
|
|
you're confusing about the object life, and the returning stuff.
there's no copy constructors (actually, not even basic constructors at all) for pointers...
|
|
|
|
|
minkowski wrote: It just copies the address and does not involve using copy constructors?
Yes, no copy constructor are involved. In fact, no constructor at all will be called, because you don't construct a new object. You only delete an object (when the function goes out of scope) and then return its address. Which is of course very very bad .
|
|
|
|
|
Ok thanks!
|
|
|
|
|
minkowski wrote:
alpha * func()
{
alpha anything;
alpha *ptr = &anything;
return ptr;
}how would it return ptr. Would it copy the pointer ptr using the copy constructor and then destroy it as the function goes out of scope?
The type you return is pointer. In this case, pointer to alpha.
And pointers do not have such things as copy constructors.
So, no copy c'tor is called.
Failure is not an option - it's built right in.
|
|
|
|
|
I have a c++ project in VC2005
------------------------------
try.h
#include <stdafx.h>
public class TryIt {
int i;
public:
void test(void);
};
------------------------------
try.cpp
#include "try.h"
#include "stdafx.h"
void TryIt::test() {
int i = 5;
}
------------------------------
both files in the project folder
but I always get
c:\vcproj\audit\audit\try.cpp(4) : error C2653: 'TryIt' : is not a class or namespace name
Any idea?
Nathan
|
|
|
|
|
Hi,
Hope this will help: From VS2005 Documentation
Error Message
'identifier' : is not a class or namespace name
Syntax requires a class, structure, union, or namespace name.
The following sample generates C2653:
class yy {
void func1(int i);
};
void xx::func1(int m) {}
void yy::func1(int m) {}
C2653 is also possible if you try to define a compound namespace; compound namespaces are not allowed in C++:
namespace a::b {int i;}
namespace a {
namespace b {
int i;
}
}
int main() {
a::b::i = 2;
}
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
My Blog: ^_^
|
|
|
|
|
not sure if that will help, but in your try.h, you don't provide exclusive inclusion like this :
#ifndef __A_VERY_LONG_AND_UNIQUE_NAME__
#define __A_VERY_LONG_AND_UNIQUE_NAME__
#endif
BTW, looking at your error, i would say that you don't include un try.cpp the header try.h, but looking at your sample, you do it, so...
|
|
|
|
|
try:
<br />
------------------------------<br />
try.h<br />
#include <br />
<br />
class TryIt {<br />
int i;<br />
<br />
public:<br />
void test(void);<br />
};<br />
------------------------------<br />
try.cpp<br />
#include "stdafx.h"<br />
#include "try.h"<br />
<br />
void TryIt::test() {<br />
int i = 5;<br />
}<br />
------------------------------<br />
I have removed the public from the class definition (I'm not sure what a private class would be?) - I suspect this is the problem. Also, I changed the order of the include files - if you are using precompiled headers stdafx.h must be first. This is probably not the issue as you would get a different error message, but probably good practice.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
cp9876 wrote: if you are using precompiled headers stdafx.h must be first. This is probably not the issue as you would get a different error message, but probably good practice.
Actually that is exactly the issue. Everything before #include "stdafx.h" gets ignored by the preprocessor.
|
|
|
|
|
Michael Dunn wrote: Everything before #include "stdafx.h" gets ignored by the preprocessor.
Huh? I thought everything up to and including the specified filename (stdafx.h by default) is
precompiled.
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mike's right - from MSDN:[^]
------------------------------------------------------------
AppWizard puts the line "#include 'stdafx.h'" as one of the first lines in every .CPP file in a project. Because of the compiler options being used by projects generated with AppWizard, anything up to and including "stdafx.h" in a .CPP file is considered by the compiler to be part of a precompiled header.
The problem with this is that when you edit the .CPP files and insert #includes, #defines, declarations, or other code before the "#include 'stdafx.h'" line, all of it is ignored by the compiler. This is the correct behavior because when the compiler is using the precompiled header, it starts to compile the code in the .CPP file after skipping past the "stdafx.h" line.
This behavior can lead to compiler errors that do not seem to make sense, because it appears that you are including all the needed declarations and header files in the .CPP file. For example, some of the errors that may result are the following:
• error C2065: 'CTestClass' : undeclared identifier
• error C2146: syntax error : missing ';' before identifier 'tc'
• error C2064: term does not evaluate to a function
------------------------------------------------------------
The last time I made this mistake was in VC6, and there, if I recall correctly, the compiler clagged - gave some warning that the include files up to stdafx.h did not match those it precompiled.
By the way, what is a 'public class', I know that for nested classes you can have public / private etc, but in global scope? What would a private class do?
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Hi Peter, I also don't kown the private/public issue, anyway I use the class wizard to add the TryIt class, it worked
|
|
|
|
|
cp9876 wrote: The problem with this is that when you edit the .CPP files and insert #includes, #defines, declarations, or other code before the "#include 'stdafx.h'" line, all of it is ignored by the compiler. This is the correct behavior because when the compiler is using the precompiled header, it starts to compile the code in the .CPP file after skipping past the "stdafx.h" line.
 Ok I gotcha. I was thinking of when the precompiled header is precompiled, everything
through the indicated file is precompiled. 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark Salsbery wrote: Ok I gotcha. I was thinking of when the precompiled header is precompiled, everything
through the indicated file is precompiled
Your thinking is correct. Given that the precompiled header options were not changed from the defaults that VS uses, the precompiled header was created when stdafx.cpp was compiled. The OP probably added his includes in a "real" source file, not stdafx.cpp. In that case, everything prior to "#include stdafx.h" is ignored. If the #include for the class in question had been added to stdafx.cpp before the usual single line #include "stdafx.h", it would have worked.
Just for posterity's sake if someone searches for this thread ... I do not recommend changing stdafx.cpp. If something needs to be included in every file in the project, change YourProjectApp.h or stdafx.h
Judy
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
