|
BTW the function is full of mistakes. And your hypothes are correct. However, for a while the values are available (they aren't immediatly overwritten). Of course you cannot do any assumption on their correctness in calling code.
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 ya
Why is my function full of mistakes? I ran the code and it works ok.
So in the function, x is available till it is over written which is why it works?
Is a copy constructor used in returning the ptr from the function ?
Thanks.
|
|
|
|
|
You function works perfectly, what you return is a the location that the function stored x. As to whether this is of any use depends on what is currently stored in that location - if you call another function the location will almost certainly be reused.
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 ya,
But I thought that x goes out of scope which means it is released. So since ptr is pointing to x then that is not valid. However, I know this works (having tried it) so the reasoning seems to be although that x goes out of scope, the memory has not been yet over written so it works.
Is that right?
And is a copy constructor called in returning the pointer?
Thanks.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
