inline functions and return by reference.

[Sreenivas]

Hi,
We cannot return a reference to an automatic variable from a function, as per
the ANSI C++ standard the behaviour is undefined. Does this hold for inline
functions too? or can I return a reference to the automatic variable from the
inline function. I meant automatic variable by stack variable strictly local to
that function.
Thanks,
Sreenivas.

 

[John Harrison]

Hi,
We cannot return a reference to an automatic variable from a function, as
per
the ANSI C++ standard the behaviour is undefined. Does this hold for
inline
functions too?

Yes

john

 

[JKop]

Sreenivas posted:

Hi,
We cannot return a reference to an automatic variable from a function,
as per the ANSI C++ standard the behaviour is undefined. Does this hold
for inline functions too? or can I return a reference to the automatic
variable from the inline function. I meant automatic variable by stack
variable strictly local to that function.
Thanks,
Sreenivas.

The following two functions are equivalent in that they give the caller
access to an object which has already been destroyed:

int& Monkey()
{
int k = 4;

return k;
}


int& Ape()
{
int k = 4;

return &k;
}



As regards inline functions, they work exactly as do everyday functions.
Their static variables work exactly the same too. There's only two
differences between an inline function and a normal function:

1) It has "inline" written before it.

2) You're not violating the One Definition Rule if you define it more than
once, eg. the following is *il*legal:

int Blah() { return 5; }
int Blah() { return 5; }

While the following is perfectly legal:

inline int Blah() { return 5; }
inline int Blah() { return 5; }


(Or maybe I'm mistaken there? Perhaps you can define inline functions as
many times as you want... except it must be once per translation unit?)

Anyway, the result is that you can stick an inline function in a header
file!


-JKop

 

[Michael Kurz]

Sreenivas posted:


int Blah() { return 5; }
int Blah() { return 5; }

While the following is perfectly legal:

inline int Blah() { return 5; }
inline int Blah() { return 5; }


(Or maybe I'm mistaken there? Perhaps you can define inline functions as
many times as you want... except it must be once per translation unit?)

IMHO "inline" solves only the linker error of linking multiple functions
with the same signature, as the compiler and the linker will typically keep
track of them over all compilation units, whereas including the same
function in the same compilation unit twice leads to a compiler error.


Regards
Michael

 

[Sreenivas]

Yes

john

const int& junk()
{
const int junk = 11;
return junk;
}

int main(...)
{
int basket; // const int & basket = junk(); __This cud give unexpected
// behaviour__

basket = junk(); // but what about this????????
return 0;
}

does this code snippet give the expected bahaviour all the time?
can i rely on this code??
-Sreenivas

 

[John Harrison]

const int& junk()
{
const int junk = 11;
return junk;
}

int main(...)
{
int basket; // const int & basket = junk(); __This cud give unexpected
// behaviour__

basket = junk(); // but what about this????????
return 0;
}

does this code snippet give the expected bahaviour all the time?
can i rely on this code??
-Sreenivas

I don't know, I would ask this question again where someone who does know
can answer it.

john

 

[Sreenivas]

Would someone acknowledge this? whether this explanation is correct or
not.

when junk() returns a reference to an object, infact it's value wud b
copied into _basket_, as _basket_ is an object itself and not a
reference and it has it's own memory allocated. so, if this statement
is executed as an atomic statement(in multi-threaded env) it shouldn't
give any problems as per my understanding.(what happens if it's single
threaded env? i see no problems)

PS: to understand the above explanation refer the code above

 

[John Harrison]

Would someone acknowledge this? whether this explanation is correct or
not.

when junk() returns a reference to an object, infact it's value wud b
copied into _basket_, as _basket_ is an object itself and not a
reference and it has it's own memory allocated. so, if this statement
is executed as an atomic statement(in multi-threaded env) it shouldn't
give any problems as per my understanding.(what happens if it's single
threaded env? i see no problems)

PS: to understand the above explanation refer the code above[/QUOTE]

I think the code is wrong. The reference refers to an object which has been
destroyed. Multithreading or single threading has nothing to do with it.

john

 

[JKop]

const int& junk()
{
const int junk = 11;
return junk;
}

Returning a reference to a local object, giving the calling function access
to an object which no longer exists. Let me know how that goes!

Maybe use of the "auto" keyword would make it more obvious to you:

int const& junk()
{
int const auto junk = 1;

return junk;
}

int main(...)

No comment.

{
int basket; // const int & basket = junk(); __This cud give
unexpected
// behaviour__

basket = junk(); // but what about this????????

Here you're doing an assignment from an object that no longer exists. Let me
know how it goes!

return 0;
}

does this code snippet give the expected bahaviour all the time?
can i rely on this code??

Undefined Behaviour.


-JKop