|
Thanks Josh,
Good answer! I have a further question about programming best practice. Do you think it is safe to let the address of the *local* static variable as the return value of a function? Then other part of code (out of this function) will access or even modify the variable by the returned address of the *local* static variable?
Any disadvantages of this approach?
Example,
<br />
<br />
int* func()<br />
{<br />
static int i;<br />
<br />
return &i;<br />
}<br />
<br />
regards,
George
|
|
|
|
|
when you mark some variable static, compiler wil decide how to treat that variable.. so there no scope of local and global variable concept here!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I
IV
Support CRY- Child Relief and You
|
|
|
|
|
Thanks Alok!
If you think static variable is different from local or global variables, how do you think static variable is stored and managed so that the value is reserved each time we enters the function in which the static variable is defined?
regards,
George
|
|
|
|
|
George_George wrote: Good answer! I have a further question about programming best practice. Do you think it is safe to let the address of the *local* static variable as the return value of a function? Then other part of code (out of this function) will access or even modify the variable by the returned address of the *local* static variable?
Any disadvantages of this approach?
I'd say it smells like bad design, the only reason to return a pointer rather than a copy of the int is to allow some other code to modify it. I'd rather provide a method to allow other code to modify the static.
|
|
|
|
|
Josh Gray wrote: I'd say it smells like bad design, the only reason to return a pointer rather than a copy of the int is to allow some other code to modify it. I'd rather provide a method to allow other code to modify the static.
sorry to interrupt you.. it's somewhat Singleton pattern...! so i don't think it bad design.. though it break OOPS basic concept of encapsulation and abstraction!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
ThatsAlok wrote: i don't think it bad design.. though it break OOPS basic concept of encapsulation and abstraction!
Which to me makes it bad design. You can still have the static and therefore the singleton pattern but my comments was more about how you expose the interface to it. Returning the address of what is basically a private variable is bad.
|
|
|
|
|
Thanks Josh,
I can generally understand and agree with your points. But I am confused about some details. Could you show us your points by a couple of lines of code please?
regards,
George
|
|
|
|
|
Thanks Alok!
How do you think returning static variable is similar to Singleton pattern? Any more details about how similar points do they have?
regards,
George
|
|
|
|
|
George_George wrote: How do you think returning static variable is similar to Singleton pattern
just on basic.. concept of Singleton pattern says that.. there should only copy exist for any variable.. look more in detail here:-
http://www.codeproject.com/cpp/singletonrvs.asp[^]
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Thanks Alok,
The similarity you mean is only one copy of data?
regards,
George
|
|
|
|
|
thats what single pattern all about
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Thanks Josh,
Josh Gray wrote: I'd rather provide a method to allow other code to modify the static.
I agree with most points of you. But I do not quite understand your above points. Could you show me a sample please about how to modify the static variable please?
I am wondering how to modify the value of the static variable from other function (other than from the function in which it is defined)?
regards,
George
|
|
|
|
|
George_George wrote: I am wondering how to modify the value of the static variable from other function (other than from the function in which it is defined)?
Sorry, my mistake as you cant do that.
You can however define a static in a class and access it from any of the methods in that class. Even const methods!
|
|
|
|
|
Hi Josh,
I think you mean static member of a class. But I mean a static variable defined inside a function.
regards,
George
|
|
|
|
|
George_George wrote: I think you mean static member of a class. But I mean a static variable defined inside a function.
Yes you are right which makes me wonder why you have global methods? I suspect there is probably a better to solution to what you are trying to do but its hard to suggest anything without knowing more about what you are doing and in what context
|
|
|
|
|
Thanks Josh,
You are right. I am writing a part of the application in C (not C++). I am wondering and willing to listen to your comments and ideas of any disadvantages if I return the address of static variable defined in a function, then let other part of code to access the variable by the returned address.
regards,
George
|
|
|
|
|
George_George wrote: You are right. I am writing a part of the application in C (not C++). I am wondering and willing to listen to your comments and ideas of any disadvantages if I return the address of static variable defined in a function, then let other part of code to access the variable by the returned address.
Well you could make the static global rather than defining it within a function then have two function to get and set its value but thats just an attempt to make a procedural language more OO.
|
|
|
|
|
Thanks Josh,
I can understand and agree that your approach works. But when we come back to my approach, returning address of function *local* static variable, are there any disadvantages?
regards,
George
|
|
|
|
|
Personal experience says your approach will not work. Inaccessible address, I think. Depends on compiler, I guess. Maybe exception error at run time...
IIRC we are talking heap versus stack issues.
|
|
|
|
|
(Surprised) I tried it and it worked. There was no problem accessing the static variable by address outside the function.
Be certain not to in-line the function, as that has certain ramifications.
The static is created on the heap, and the address *is* accessible from outside the class and outside the function it is defined in.
I am quite surprised. I thought even the compiler would catch it. Ignore previous post.
<br />
int *CPBDialog::TryThis()<br />
{<br />
static int test;<br />
<br />
test += 1;<br />
return &test;<br />
}<br />
<br />
<br />
CErrorOkDlg::CErrorOkDlg(CWnd* pParent )<br />
: CPBDialog(CErrorOkDlg::IDD, pParent)<br />
{<br />
}<br />
<br />
<br />
BOOL CErrorOkDlg::OnInitDialog() <br />
{<br />
CPBDialog::OnInitDialog();<br />
<br />
ModifyStyleEx(0,WS_EX_NODRAG,0);<br />
<br />
SoundWarning();<br />
int *test = TryThis();<br />
int test2 = *test;<br />
<br />
return FALSE;<br />
}<br />
<br />
<br />
Gary
|
|
|
|
|
Thanks for your help and sample, Gary!
It is great!
regards,
George
|
|
|
|
|
This is a very interresting article about the use and the concept of the static keyword
clickety[^]
codito ergo sum
|
|
|
|
|
Thanks BadKarma,
If I mean local static function variable, and if I use the address of the variable as the return value, then access the address outside the function (read/write). Does this approach have any disadvantages?
regards,
George
|
|
|
|
|
Whether this is a bad design or a good one, depends on the place where you use this. So you should think carefully where to implement.
There is however on big disadvantage to this design. The function isn't thread safe.
This means that when called from multiple threads the behavior will be unpredictable.
codito ergo sum
|
|
|
|
|
Thanks BadKarma,
BadKarma wrote: This means that when called from multiple threads the behavior will be unpredictable
Could you provide more detailed scenario to describe why it is not thread safe please?
regards,
George
|
|
|
|