I am sorry for this...

[Nakor]

Hello,

I am a Computer Programmer Analyst student. I am taking this course
which for this week's assignment requires me to join some newsgroups.
I am sorry to have to spam you with such useless crap.

Regardless I am supposed to instigate a response of some sort, so could
someone please fulfill that requirement for me?

Thanks,

Nakor

[Alf P. Steinbach]

* Nakor:

I am a Computer Programmer Analyst student. I am taking this course
which for this week's assignment requires me to join some newsgroups.
I am sorry to have to spam you with such useless crap.

Regardless I am supposed to instigate a response of some sort, so could
someone please fulfill that requirement for me?

Thanks,

Nakor

Okay, what's wrong with this function

std::string const& helloText()
{
return "A response";
}

?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Nakor]

Thanks for replying. I'm not certain what would be intended by this
bit of code, but I am willing to guess.

If you merely wished for the function to pass back a welcome string
then this would suffice:

std::string helloText()
{
return "A response";
}

Other than that I'm not sure what would be the intention :)

[Matthias]

Nakor wrote:

Other than that I'm not sure what would be the intention :)

The point is, returning a reference to a local object can generally be
called a bad idea :)

--
Regards,
Matthias

[Nakor]

Ah ok! Thanks heh :)

[Victor Bazarov]

Matthias wrote:

Nakor wrote:

Other than that I'm not sure what would be the intention :)

The point is, returning a reference to a local object can generally be
called a bad idea :)

I actually thought the function returned a reference to a temporary.
The problem is not that it's local (and a string literal is not really
local to anything), the problem is in the lifetime of the temporary.

V

[Matthias]

Victor Bazarov wrote:

Matthias wrote:

Nakor wrote:

Other than that I'm not sure what would be the intention :)

The point is, returning a reference to a local object can generally be
called a bad idea :)

I actually thought the function returned a reference to a temporary.
The problem is not that it's local (and a string literal is not really
local to anything), the problem is in the lifetime of the temporary.

V

Yes, the temporary will be deleted upon leaving the scope. So will any
local object during stack unwinding. So the point stays the same, no? :)

--
Regards,
Matthias

[Jakob Bieling]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:Sw*******************@newsread1.mlpsca01.us.t o.verio.net...

Matthias wrote:

Nakor wrote:

Other than that I'm not sure what would be the intention :)

The point is, returning a reference to a local object can generally be
called a bad idea :)

I actually thought the function returned a reference to a temporary.
The problem is not that it's local (and a string literal is not really
local to anything), the problem is in the lifetime of the temporary.

I am not sure if I understood this right: A temporary exists as long as
the const reference it was bound to. So the part of binding the temporary to
the return value should not yet pose a problem. The problems start when
actually using the return value, because assigning it to another const
reference (which includes calling std::string::operator=) does not extend
the life of the temporary again, thus leaving us with a const reference to
an invalid object. Is this correct?

thanks!
--
jb

(reply address in rot13, unscramble first)

[Victor Bazarov]

Matthias wrote:

Victor Bazarov wrote:

Matthias wrote:

Nakor wrote:
Other than that I'm not sure what would be the intention :)
The point is, returning a reference to a local object can generally
be called a bad idea :)
I actually thought the function returned a reference to a temporary.
The problem is not that it's local (and a string literal is not really
local to anything), the problem is in the lifetime of the temporary.

V

Yes, the temporary will be deleted upon leaving the scope.

Why? There is a const reference bound to it...
So will any
local object during stack unwinding. So the point stays the same, no? :)

No.

[Matthias]

Victor Bazarov wrote:

Why? There is a const reference bound to it...

I see. Thanks for clearing up :)

--
Regards,
Matthias

[Default User]

Nakor wrote:

Hello,

I am a Computer Programmer Analyst student. I am taking this course
which for this week's assignment requires me to join some newsgroups.
I am sorry to have to spam you with such useless crap.

Ok, I'll supply some advice for using the Google interface for posting
to usenet groups. It's common practice to quote a relevant portion of
the message to which you are replying, as I have done here.
Unfortunately, the Google interface doesn't make it obvious to the new
user how to do so.

Rather than clicking the Reply at the bottom of the message, look for
one alongside the header labeled "show options". Click this, and the
header will expand. Select the Reply shown there, and you will get a
full quoting of the message with proper attributions. This will make
your experience on usenet MUCH more fulfilling.


Brian

[Victor Bazarov]

Jakob Bieling wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:Sw*******************@newsread1.mlpsca01.us.t o.verio.net...

Matthias wrote:

Nakor wrote:
Other than that I'm not sure what would be the intention :)
The point is, returning a reference to a local object can generally be
called a bad idea :)

I actually thought the function returned a reference to a temporary.
The problem is not that it's local (and a string literal is not really
local to anything), the problem is in the lifetime of the temporary.

I am not sure if I understood this right: A temporary exists as long as
the const reference it was bound to. So the part of binding the temporary to
the return value should not yet pose a problem. The problems start when
actually using the return value, because assigning it to another const
reference (which includes calling std::string::operator=) does not extend
the life of the temporary again, thus leaving us with a const reference to
an invalid object. Is this correct?

This is a very good question. I am not really sure, to be honest.

Recently there were some discussions (I even participated in one of
them, IIRC) about lifetimes of temporaries if they are returned from
functions as objects and then either bound to references or not. So,
from those points of view, if I write

#include <string>
const std::string& foo() { return "foo"; }
int main() {
const std::string& bar = foo();
}

the temporary created inside 'foo' should survive until 'main' returns
since there is always some reference bound to it...

Another point you brought up is assignment, so if I write

#include <string>
const std::string& foo() { return "foo"; }
int main() {
std::string bar = foo();
}

it still should be OK, since the temporary is created as part of the
initialiser expression, and will last until the constructor returns
upon constructing the 'bar' object (12.2/4).

Now, I am likely making a mistake in both of those cases and the
temporary is not going to survive long enough. 12.2/5 among other
things, states "A temporary bound to the returned value in a function
return statement (6.6.3) persists until the function exits" which does
put me in doubt about my correctness.

Now, the main question is, can _re_binding the reference keep the
temporary alive or do we only get one shot at it? IOW, if I do

std::string foo() { return "42"; }
const std::string& bar() { return foo(); }
const std::string& foobar() { return bar(); }

does 'foobar' return a valid reference? Even stricter, does 'bar'
return a valid reference?

V

[Victor Bazarov]

Matthias wrote:

Victor Bazarov wrote:

Why? There is a const reference bound to it...

I see. Thanks for clearing up :)

Not at all. I mean, I don't think I cleared it up. But that
muddying of the waters wasn't intentional. I myself am in the
fog WRT this. One thing I know for sure, it's not a local
object.

V

[Ioannis Vranos]

Victor Bazarov wrote:

Not at all. I mean, I don't think I cleared it up. But that
muddying of the waters wasn't intentional. I myself am in the
fog WRT this. One thing I know for sure, it's not a local
object.

Based on TC++PL "10.4.10 Temporary Objects" I think the temporary
created after the return of the literal is destroyed at the end of the
expression.
An example mentioned there:

"However, in combination they can cause obscure problems.

For example:

void f(string& s1, string& s2, string& s3)
{
const char* cs= (s1+s2).c_ str() ;

cout << cs;

if (strlen(cs=(s2+s3).c_ str())<8 && cs[0]==´a´) {
// cs used here
}
}

Probably, your first reaction is "but don’t do that," and I agree.

However, such code does get written, so it is worth knowing how it is
interpreted.

A temporary object of class string is created to hold s1+s2. Next, a
pointer to a C-style string is extracted from that object. Then – at the
end of the expression – the temporary object is deleted.

Now, where was the C-style string allocated? Probably as part of the
temporary object holding s1+s2, and that storage is not guaranteed to
exist after that temporary is destroyed. Consequently, cs points to
deallocated storage. The output operation cout<<cs might work as
expected, but that would be sheer luck. A compiler can detect and warn
against many variants of this problem.

The example with the if-statement is a bit more subtle. The condition
will work as expected because the full expression in which the temporary
holding s2+s3 is created is the condition itself.

However, that temporary is destroyed before the controlled statement is
entered, so any use of cs there is not guaranteed to work.

Please note that in this case, as in many others, the problems with
temporaries arose from using a high-level data type in a low-level
way. A cleaner programming style would have not only yielded a more
understandable program fragment, but also avoided the problems with
temporaries completely. For example:

...."


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

Based on TC++PL "10.4.10 Temporary Objects" I think the temporary
created after the return of the literal is destroyed at the end of the
expression.
An example mentioned there:

"However, in combination they can cause obscure problems.

For example:

void f(string& s1, string& s2, string& s3)
{
const char* cs= (s1+s2).c_ str() ;

cout << cs;

if (strlen(cs=(s2+s3).c_ str())<8 && cs[0]==´a´) {
// cs used here
}
}

Actually this example is different from what we are discussing here, and
probably the temporary remains until the end of the scope of the const
reference.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

and
probably the temporary remains until the end of the scope of the const
reference.

Probably in agreement to this, TC++PL mentions in the same place:
"A temporary can be used as an initializer for a const reference or a
named object. For example:

void g(const string&, const string&) ;

void h(string& s1, string& s2)
{
const string& s = s1+s2;

string ss = s1+s2;

g(s,ss); // we can use s and ss here
}

This is fine. The temporary is destroyed when "its" reference or named
object go out of scope.

Remember that returning a reference to a local variable is an error
(7.3) and that a temporary object cannot be bound to a non-const
reference (5.5).

A temporary object can also be created by explicitly invoking a
constructor. For example:

void f(Shape& s, int x, int y)
{
s.move(Point(x,y)); // construct Point to pass to Shape::move()
// ...
}

*Such temporaries are destroyed in exactly the same way as the
implicitly generated temporaries.*"


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Bogdan Sintoma]

Victor Bazarov wrote:

Jakob Bieling wrote:

I am not sure if I understood this right: A temporary exists as long as the const reference it was bound to. So the part of binding the temporary to the return value should not yet pose a problem. The problems start when actually using the return value, because assigning it to another const reference (which includes calling std::string::operator=) does not extend the life of the temporary again, thus leaving us with a const reference to an invalid object. Is this correct?

IMHO it is.
#include <string>
const std::string& foo() { return "foo"; }
int main() {
const std::string& bar = foo();
}

the temporary created inside 'foo' should survive until 'main' returns since there is always some reference bound to it... I think not. As you say there is "some" reference.
A const reference "initialized" with a temporary value makes that
temporary value live for the lifetime of the reference itself. But,
chaining of const references assignment doesn't prevent temporary
destruction (IMHO you need GC to ensure such a behavior).
Now, I am likely making a mistake in both of those cases and the
temporary is not going to survive long enough. 12.2/5 among other
things, states "A temporary bound to the returned value in a function
return statement (6.6.3) persists until the function exits" which does put me in doubt about my correctness.

Yes I think this paragraph is relevant on this topic.
..
..
Best regards,
Bogdan

[Richard Herring]

In message <11**********************@c13g2000cwb.googlegroups .com>,
Nakor <na***@indolentspecies.com> writes

Hello,

I am a Computer Programmer Analyst student. I am taking this course
which for this week's assignment requires me to join some newsgroups.
I am sorry to have to spam you with such useless crap.

Regardless I am supposed to instigate a response of some sort, so could
someone please fulfill that requirement for me?

That's easy. Please post the email address of the person who set you
this useless task, so we can return the favour.

There you are. Purposeful communication on Usenet. Whatever next?

--
Richard Herring

[Nakor]

>That's easy. Please post the email address of the person who* set you

this useless task, so we can return the favour.

My sentiments exactly. Unfortunately I can not send you her email as I
would certainly get in trouble with the school. I was very annoyed to
have to do this assignment.

[Richard Herring]

In message <11*********************@z14g2000cwz.googlegroups. com>, Nakor
<na***@indolentspecies.com> writes

That's easy. Please post the email address of the person who* set you

this useless task, so we can return the favour.

My sentiments exactly. Unfortunately I can not send you her email as I
would certainly get in trouble with the school. I was very annoyed to
have to do this assignment.

You'd better hope that L*** A**** isn't reading this group, then.

--
Richard Herring

[Ioannis Vranos]

Nakor wrote:

My sentiments exactly. Unfortunately I can not send you her email as I
would certainly get in trouble with the school. I was very annoyed to
have to do this assignment.

And how will she understand that you fulfilled this "assignment"?


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Jakob Bieling]

"Bogdan Sintoma" <bo****@yahoo.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Jakob Bieling wrote:

> I am not sure if I understood this right: A temporary exists as long as > the const reference it was bound to. So the part of binding the temporary to > the return value should not yet pose a problem. The problems start when > actually using the return value, because assigning it to another const > reference (which includes calling std::string::operator=) does not extend > the life of the temporary again, thus leaving us with a const reference to > an invalid object. Is this correct?

IMHO it is.

Ok, now please consider the following snippet:

int const& f ()
{
return 2;
}

int main ()
{
int i = f();
}

Now we do not use our const reference to initialize another reference,
but assign the value to another variable right away. So, as the temporary is
bound to the const reference return value, and that return value goes out of
scope after the ';' .. this should be valid? But is it, tho it is
contradictory to the passage Victor cited.

thanks!
--
jb

(reply address in rot13, unscramble first)

[Victor Bazarov]

Jakob Bieling wrote:

[...]
Ok, now please consider the following snippet:

int const& f ()
{
return 2;
}

int main ()
{
int i = f();
}

Now we do not use our const reference to initialize another reference,
but assign the value to another variable right away. So, as the temporary is
bound to the const reference return value, and that return value goes out of
scope after the ';' .. this should be valid? But is it, tho it is
contradictory to the passage Victor cited.

Which one of the two ';' do you mean when you say that "return value goes
out of scope after the ';'"?

Of course, I'd really prefer an example involving classes. In your case
the '2' is a literal and has a life of its own. And while the Standard
does talk about a potential creation of a temporary during the binding of
a reference to an rvalue, how can we make sure there is a temporary in
this case? I can only think of one method: a constructor that is called
for the temporary. So, updating your code to

struct A { int i; A(int i) : i(i) {}; operator int() { return i; }};
A const& f()
{
return 2;
}
int main()
{
int i = f();
}

is it legal or does the temporary get destroyed at the 'f's closing brace?

Thanks.

V

[Alf P. Steinbach]

* Victor Bazarov:

struct A { int i; A(int i) : i(i) {}; operator int() { return i; }};
A const& f()
{
return 2;
}
int main()
{
int i = f();
}

is it legal or does the temporary get destroyed at the 'f's closing brace?

Answering my own original innocent question, now escalated into a full-blown
debate: it's the latter (as would also be the case with just using 'int').

§12.2/5 "A temporary bound to the returned value in a function return
statement (6.6.3) persists until the function exits".

If this was not the case, then gross inefficiencies would have to be
introduced to allocate memory for the result of a function for the
general case. With a reference result the referred object can be
any size whatsoever. Which means that the calling code cannot pre-
allocate space on the stack.

But of course we can wonder _why_ the standard requires near certain UB
(only if you don't use the result in any way can you avoid UB) instead
of simply disallowing this thing. Well, it may be the case that it one
return path the function returns a valid reference, while in another,
just a temporary to satisfy that warning-addicted compiler. Or it may
be the case that the programmer is engaging in Unholy Practices to obtain
the stack-pointer.

Although I would have preferred that the standard disallowed this...

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Howard]

"Nakor" <na***@indolentspecies.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

That's easy. Please post the email address of the person who- set you

this useless task, so we can return the favour.

My sentiments exactly. Unfortunately I can not send you her email as I
would certainly get in trouble with the school. I was very annoyed to
have to do this assignment.

You shouldn't be annoyed. I have found through experience that newsgroups
are an incredibly helpful tool for my programming. I've solved countless
problems by asking questions in the newsgroups, by reading answers to
others' questions, and by joining in discussions/debates. An assignment
like you've been given is meant to introduce all the students to a valuable
asset, one that every programmer should know about and know how to make good
use of. (Google is another one that's invaluable, by the way.) Spend some
time just lurking here... you'll learn a LOT!

-Howard

[Ioannis Vranos]

Jakob Bieling wrote:

Ok, now please consider the following snippet:

int const& f ()
{
return 2;
}

int main ()
{
int i = f();
}

Now we do not use our const reference to initialize another reference,
but assign the value to another variable right away. So, as the temporary is
bound to the const reference return value, and that return value goes out of
scope after the ';' .. this should be valid? But is it, tho it is
contradictory to the passage Victor cited.

thanks!

No the above is not valid (meaning it invokes undefined behaviour).


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Victor Bazarov wrote:

Which one of the two ';' do you mean when you say that "return value goes
out of scope after the ';'"?

Of course, I'd really prefer an example involving classes. In your case
the '2' is a literal and has a life of its own.
Still the known sure life-time of the literal is the function scope and
in most cases an int(2) gets created upon the return statement in the
function scope, a const reference is returned to this temporary which is
destroyed after the return statement, that is, return 2; in this case is
equivalent to return int(2);
So in this case both the literal's known life-time and the life-time of
the possible temporary is the function scope, and this means we get
undefined behaviour.
And while the Standard
does talk about a potential creation of a temporary during the binding of
a reference to an rvalue, how can we make sure there is a temporary in
this case? I can only think of one method: a constructor that is called
for the temporary. So, updating your code to

struct A { int i; A(int i) : i(i) {}; operator int() { return i; }};
A const& f()
{
return 2;
}
int main()
{
int i = f();
}

is it legal or does the temporary get destroyed at the 'f's closing brace?

The above is equivalent to
struct A { int i; A(int i) : i(i) {}; operator int() { return i; }};

A const& f()
{
return A(2);
}
int main()
{
int i = f();
}
which of course is the same case, since a reference to a local temporary
is returned, while in the original case a reference to a local literal
or temporary is also returned.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Nakor]

Heh :) L*** A**** know's I am a lippy asshat. She know's I say what I
mean and mean what I say. I don't think she'd be too angry with me. :)

[Nakor]

Ioannis Vranos wrote:

And how will she understand that you fulfilled this "assignment"?

I have provided her with a link to the newsgroups.

Nakor

[Nakor]

Howard wrote:

An assignment
like you've been given is meant to introduce all the students to a valuable asset, one that every programmer should know about and know how to make good use of. (Google is another one that's invaluable, by the way.) Spend some time just lurking here... you'll learn a LOT!

Yes, a valuable asset, but one I was already very aware of. I have a
couple of message boards that I use when I absolutely have to. For now
I love my books. When my books begin to fail me I will turn more to
the net.

Nakor