Topic: passing a temporary as a non-const reference parameter
Author: comeau@panix.com (Greg Comeau)
Date: 1997/01/03 Raw View
In article <32C8362E.20EB@mci.com> Srinivas.Vobilisetti@mci.com writes:
>Greg Comeau wrote:
>>
>> In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>> >I've found out that there is a change to C++ that prohibits passing
>> >temporaries via non-const reference. What is the rationale behind
>> >this change?
>>
>> If you mean what I think you do, this change goes back many years,
>> back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
>> is simply that it can lead to surprises and as well is often not
>> what was intended. For instance, in general, what does it mean to
>> modify an unnamed temporary?
>>
>> - Greg
>
>I am going thru the topic on temporaries from "The Design and Evolution
>of C++ - Bjarne Stroustrup". At the end of the topic, he says, if I
>understand it correctly, the early version of C++ allowed creating
>temporaries for non-const reference arguments but the later version,
>maybe 2.1, prohibits such creation of temporaries. For example
>
>void ToInt(double &d)
>{
> d = int(d);
>}
>
>void main()
>{
> int i = 2;
> ToInt(i); // Error: Can't pass int for double&
>}
>
>This is just an example please. But for my compiler it is a warning and
>not
>an error. Not sure why?
Because it is allowing old code to compile? No doubt then it also
has a command line switch or similar to make it into an error.
>But I don't think, C++ prohibits changing an argument, even if temporary
>is
>passed for a reference argument, within the function. So,
>
>(ofstream("x") << "Writing to temporary" << endl).close();
>
>maybe still valid.
>
>So, In the above example, is ToInt(double(i)) valid? maybe.
Even when of the right type, the draft requires it to be a const ref.
Remember, always break down things to their simplest parts.
In this case, recall that argument passing involves initialization
so you really have:
double &d = i; // This is a type mismatch :. error
double &d = double(i); // This is not, but this init'r is not an
// lvalue even though of the right type :. error
const double &d = i; // ok
const double &d = double(i); // ok
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: jpotter@falcon.lhup.edu (John E. Potter)
Date: 1997/01/06 Raw View
> In article <32C8362E.20EB@mci.com> Srinivas.Vobilisetti@mci.com writes:
> >> In article <32c22385.22232114@library.airnews.net>
> >> rmashlan@r2m.com (Robert Mashlan) writes:
> >> >I've found out that there is a change to C++ that prohibits passing
> >> >temporaries via non-const reference. What is the rationale behind
> >> >this change?
> >>
>
> >But I don't think, C++ prohibits changing an argument, even if temporary
> >is
> >passed for a reference argument, within the function. So,
> >
> >(ofstream("x") << "Writing to temporary" << endl).close();
> >
> >maybe still valid.
A temporary is an rvalue, and the rules prohibit initialization of a
nonconst reference with an rvalue. However, an rvalue is not const
and may be modified via a member function. Both the original example
and the above are valid because ofstream::operator<<(char const*) is
a member function. This does not work for global functions taking a
nonconst reference.
I can not use the global operator& to get the address of an rvalue;
however, the implementation can use an rvalue to initialize the this
pointer or a const reference. The rules are there to prevent me
from accidentally modifying a temporary. If I really want to, the
language makes it easy to do so.
template <class T>
T& lvalue_cast (T const& t) {
return const_cast<T&>(t);
}
I can then do lots of useful things as well as silly things like
lvalue_cast(2 + 3) = 7;
It is explicit and my responsibility to be sure that it makes sence.
I am quite happy with the rules,
John
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: jpotter@falcon.lhup.edu (John E. Potter)
Date: 1997/01/06 Raw View
: In article <32C8362E.20EB@mci.com> Srinivas.Vobilisetti@mci.com writes:
: >> In article <32c22385.22232114@library.airnews.net>
: >> rmashlan@r2m.com (Robert Mashlan) writes:
: >> >I've found out that there is a change to C++ that prohibits passing
: >> >temporaries via non-const reference. What is the rationale behind
: >> >this change?
[snip]
: >But I don't think, C++ prohibits changing an argument, even if temporary
: >is
: >passed for a reference argument, within the function. So,
: >
: >(ofstream("x") << "Writing to temporary" << endl).close();
: >
: >maybe still valid.
A temporary is an rvalue and the rules prohibit initializing a nonconst
reference with an rvalue. However, an rvalue is not const and can be
modified via a nonconst member function. The original example and the
one above are both still valid because ofstream::operator<<(char const*)
is a member function.
I cannot use global operator& to get a pointer to an rvalue; however,
the implementation can initialize the this pointer or a const& from
an rvalue. Given these capabilities, I can work around the
restrictions.
template <class T>
T& lvalue_cast (T const& t) {
return const_cast<T&>(t);
}
and write silly things like
lvalue_cast(2 + 3) = 7;
and other things which are not silly. As in all work arounds, it is my
responsibility to be sure that it is reasonable. And, it is explicit.
The language prevents accidental modification of temporaries and allows
explicit modification.
I am quite happy with the rules,
John
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Chelly Green <chelly@eden.com>
Date: 1996/12/30 Raw View
Robert Mashlan wrote:
>
> comeau@panix.com (Greg Comeau) wrote:
>
> >In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
> >>I've found out that there is a change to C++ that prohibits passing
> >>temporaries via non-const reference. What is the rationale behind
> >>this change?
> >
> >If you mean what I think you do, this change goes back many years,
> >back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
> >is simply that it can lead to surprises and as well is often not
^^^^^^^^^^^^^^^^^^^^^^^^
> >what was intended. For instance, in general, what does it mean to
> >modify an unnamed temporary?
...
> I think there are many situations where it's valid to modify an
> unnamed temporary.
I'm sure there are, but the error-prone possibilities are still there.
> Just about any object that represents a hardware
> resource external to a program would need an non-const object. For
> instance, I may have a function that takes a reference to an object
> that represents a bi-directional communications port.
OK:
CommPort comm_port;
func( comm_port );
> When I call
> this function, it seems perfectly valid to use an unnamed temporary to
> create and destroy an object used to communicate with the port for use
> only by that function.
But are you creating and destroying the comm port each time?
> To me, it seems like a silly rule, on the level prohibiting
> inefficient activities such assigning values that are never used to
> local variables.
The language does not prohibit the latter.
<sarcasm> Yeah, I guess C++ is so silly, it should just be an assembler
so you can do anything! All these dumb typing restrictions just get in
the way. Sure, they help prevent errors, but they also prevent such
useful constructs.
> However, with the restriction on temporary usage, it
> prohibits the programmer from doing that is potentially useful.
Yep, I agree, I use assembler all the time. C++ requires so few lines of
code. It is too cryptic.
</sarcasm>
OK, I'm going to have to post a solution I posted a few days ago (with a
little improvement):
template<class T>
struct lvalue
{
T obj;
lvalue() { }
template<class A1>
lvalue( A1& a1 ) : obj( a1 ) { }
template<class A1,class A2>
lvalue( A1& a1, A2& a2 ) : obj( a1, a2 ) { }
};
usage:
func( lvalue<CommPort>().obj )
If you don't have member templates, then you could either drop the ctors
that take parameters, use different lvalue classes, i.e. lvalue_1,
lvalue_2, or use some template functions and a few helper classes.
--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Srinivas Vobilisetti <Srinivas.Vobilisetti@mci.com>
Date: 1996/12/30 Raw View
Greg Comeau wrote:
>
> In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
> >I've found out that there is a change to C++ that prohibits passing
> >temporaries via non-const reference. What is the rationale behind
> >this change?
>
> If you mean what I think you do, this change goes back many years,
> back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
> is simply that it can lead to surprises and as well is often not
> what was intended. For instance, in general, what does it mean to
> modify an unnamed temporary?
>
> - Greg
I am going thru the topic on temporaries from "The Design and Evolution
of C++ - Bjarne Stroustrup". At the end of the topic, he says, if I
understand it correctly, the early version of C++ allowed creating
temporaries for non-const reference arguments but the later version,
maybe 2.1, prohibits such creation of temporaries. For example
void ToInt(double &d)
{
d = int(d);
}
void main()
{
int i = 2;
ToInt(i); // Error: Can't pass int for double&
}
This is just an example please. But for my compiler it is a warning and
not
an error. Not sure why?
But I don't think, C++ prohibits changing an argument, even if temporary
is
passed for a reference argument, within the function. So,
(ofstream("x") << "Writing to temporary" << endl).close();
maybe still valid.
So, In the above example, is ToInt(double(i)) valid? maybe.
Srinivas
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: "Bill Wade" <bill.wade@stoner.com>
Date: 1996/12/31 Raw View
Robert Mashlan <rmashlan@r2m.com> wrote in article
<32c22385.22232114@library.airnews.net>...
> I've found out that there is a change to C++ that prohibits passing
> temporaries via non-const reference. What is the rationale behind
> this change?
The change isn't recent.
I suppose the rational is that somebody thought interpreting
const short s = 3;
s = 7;
as
const short s = 3;
int temp = s;
temp = 7;
was a bad idea. Since this example may be ambiguous or otherwise bogus,
how about
void Assign7(int& i){ i = 7; }
const short s = 3;
Assign7(s);
Notice that
const short s = 3;
int(s) = 7;
is also illegal, and closely parallels your example.
Implicit construction of temporaries occurs in too many places for comfort.
Arguably, with explicit construction, such as your example and int(s) = 7,
the restriction could be relaxed.
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: James Kanze <james-albert.kanze@vx.cit.alcatel.fr>
Date: 1997/01/02 Raw View
rmashlan@r2m.com (Robert Mashlan) writes:
|> comeau@panix.com (Greg Comeau) wrote:
|>
|> >In article <32bf1a17.85359994@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
|> >>rmashlan@r2m.com (Robert Mashlan) wrote:
|>
|> >>To get the equivalent, I now have to write:
|> >>
|> >> {
|> >> ofstream temp("foo.log",ios::app);
|> >> temp << "something to log" << endl;
|> >> }
|> >
|> >At least at the time, a point was involved that indeed this may not
|> >have been equivalent (because of the lifetime of temporaries).
|>
|> According to the April draft, a temporary will live until the
|> evaluation of the full expression in which it is involved. (There are
|> two exceptions to the rule, which don't apply here). The point of
|> destruction for the temporary and the equivalent version should be the
|> same.
Today. Greg's comment was preceded by "At least at the time..." The
initial specification of C++ was rather vague as to the point of
destruction of temporaries, and different compilers did different
things. For example, in the expression:
ostrstream() << "abcd" << d ;
g++ would destruct the temporary ostrstream after the call to output the
string, but before outputting the d. It is important to note that this
was NOT due to a bug in g++, but was perfectly correct under the rules
at that time. (Other compilers, such as cfront, would not destruct
temporaries until the next closing brace. Some of the code which worked
with them is broken under the current rule.)
--
James Kanze home: kanze@gabi-soft.fr +33 (0)3 88 14 49 00
office: kanze@vx.cit.alcatel.fr +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
-- Conseils en informatique industrielle --
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: comeau@panix.com (Greg Comeau)
Date: 1997/01/03 Raw View
In article <32c7fef6.98458317@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>comeau@panix.com (Greg Comeau) wrote:
>
>>In article <32bf1a17.85359994@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>>>rmashlan@r2m.com (Robert Mashlan) wrote:
>
>>>To get the equivalent, I now have to write:
>>>
>>> {
>>> ofstream temp("foo.log",ios::app);
>>> temp << "something to log" << endl;
>>> }
>>
>>At least at the time, a point was involved that indeed this may not
>>have been equivalent (because of the lifetime of temporaries).
>
>According to the April draft, a temporary will live until the
>evaluation of the full expression in which it is involved. (There are
>two exceptions to the rule, which don't apply here). The point of
>destruction for the temporary and the equivalent version should be the
>same.
This is so, but it throws away that I said "At least at the time".
There was no April draft then.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: comeau@panix.com (Greg Comeau)
Date: 1997/01/03 Raw View
In article <32c6fc31.97748895@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>comeau@panix.com (Greg Comeau) wrote:
>
>>In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>>>I've found out that there is a change to C++ that prohibits passing
>>>temporaries via non-const reference. What is the rationale behind
>>>this change?
>>
>>If you mean what I think you do, this change goes back many years,
>>back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
>>is simply that it can lead to surprises and as well is often not
>>what was intended. For instance, in general, what does it mean to
>>modify an unnamed temporary?
>
>I didn't find this contraint in the April 95 draft. If possible,
>could you point out where this restriction exists in this draft?
Yes, I believe it is in 8.5.3/dcl.init.ref.
>I think there are many situations where it's valid to modify an
>unnamed temporary.
I don't think the issue is strictly one of validity.
Often, when trying to get at the root of something, it helps
to substitute builtin types. In this case, let's use a string
literal:
foo("hello");
I think you are arguing for the choice of foo(char *) vs foo(const char *)
as you see fit. But actually, the former is not a preferred option.
It can lead to suprises.
Is there ever a situation where you'd want to change the string
literal in memory? Sure. But then you would not know if it worked.
This is of course not the case at hand, but I think the points still apply.
Ditto for the solution (create a named object).
> Just about any object that represents a hardware
>resource external to a program would need an non-const object. For
>instance, I may have a function that takes a reference to an object
>that represents a bi-directional communications port. When I call
>this function, it seems perfectly valid to use an unnamed temporary to
>create and destroy an object used to communicate with the port for use
>only by that function.
You seem to be defending this by implying that such an object be unnamed
is some sort of requirement. I fail to see this.
>To me, it seems like a silly rule, on the level prohibiting
>inefficient activities such assigning values that are never used to
>local variables. However, with the restriction on temporary usage, it
>prohibits the programmer from doing that is potentially useful.
I also fail to see how you can justify the previous type mismatches
that were allowed in the old rules. That's hardly silly at all.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: rmashlan@r2m.com (Robert Mashlan)
Date: 1996/12/23 Raw View
I've found out that there is a change to C++ that prohibits passing
temporaries via non-const reference. What is the rationale behind
this change?
rm
---
Robert Mashlan R2M Software rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: rmashlan@r2m.com (Robert Mashlan)
Date: 1996/12/24 Raw View
rmashlan@r2m.com (Robert Mashlan) wrote:
>I've found out that there is a change to C++ that prohibits passing
>temporaries via non-const reference. What is the rationale behind
>this change?
To clarify, I disagree with this change. It breaks perfectly good
code like this:
ofstream("foo.log",ios::app) << "something to log" << endl;
To get the equivalent, I now have to write:
{
ofstream temp("foo.log",ios::app);
temp << "something to log" << endl;
}
---
Robert Mashlan R2M Software rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: comeau@panix.com (Greg Comeau)
Date: 1996/12/27 Raw View
In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>I've found out that there is a change to C++ that prohibits passing
>temporaries via non-const reference. What is the rationale behind
>this change?
If you mean what I think you do, this change goes back many years,
back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
is simply that it can lead to surprises and as well is often not
what was intended. For instance, in general, what does it mean to
modify an unnamed temporary?
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
***WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: comeau@panix.com (Greg Comeau)
Date: 1996/12/28 Raw View
In article <32bf1a17.85359994@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>rmashlan@r2m.com (Robert Mashlan) wrote:
>
>>I've found out that there is a change to C++ that prohibits passing
>>temporaries via non-const reference. What is the rationale behind
>>this change?
>
>To clarify, I disagree with this change. It breaks perfectly good
>code like this:
>
> ofstream("foo.log",ios::app) << "something to log" << endl;
>
>To get the equivalent, I now have to write:
>
> {
> ofstream temp("foo.log",ios::app);
> temp << "something to log" << endl;
> }
At least at the time, a point was involved that indeed this may not
have been equivalent (because of the lifetime of temporaries).
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
***WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: rmashlan@r2m.com (Robert Mashlan)
Date: 1996/12/29 Raw View
comeau@panix.com (Greg Comeau) wrote:
>In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>>I've found out that there is a change to C++ that prohibits passing
>>temporaries via non-const reference. What is the rationale behind
>>this change?
>
>If you mean what I think you do, this change goes back many years,
>back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
>is simply that it can lead to surprises and as well is often not
>what was intended. For instance, in general, what does it mean to
>modify an unnamed temporary?
I didn't find this contraint in the April 95 draft. If possible,
could you point out where this restriction exists in this draft?
I think there are many situations where it's valid to modify an
unnamed temporary. Just about any object that represents a hardware
resource external to a program would need an non-const object. For
instance, I may have a function that takes a reference to an object
that represents a bi-directional communications port. When I call
this function, it seems perfectly valid to use an unnamed temporary to
create and destroy an object used to communicate with the port for use
only by that function.
To me, it seems like a silly rule, on the level prohibiting
inefficient activities such assigning values that are never used to
local variables. However, with the restriction on temporary usage, it
prohibits the programmer from doing that is potentially useful.
rm
---
Robert Mashlan R2M Software rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1996/12/30 Raw View
rmashlan@r2m.com (Robert Mashlan) writes:
> comeau@panix.com (Greg Comeau) wrote:
>
> >In article <32c22385.22232114@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
> >>I've found out that there is a change to C++ that prohibits passing
> >>temporaries via non-const reference. What is the rationale behind
> >>this change?
> >
> >If you mean what I think you do, this change goes back many years,
> >back, to "C++ 2.1" if I recall correctly. Anyway, the rationale
> >is simply that it can lead to surprises and as well is often not
> >what was intended. For instance, in general, what does it mean to
> >modify an unnamed temporary?
>
> I didn't find this contraint in the April 95 draft. If possible,
> could you point out where this restriction exists in this draft?
Section 8.5.3 [dcl.init.ref]: "A reference to type 'cv1 T1' is
initialized by an expression of type 'cv2 T2' as follows: --If the
initializer expression is an lvalue [...] --Otherwise, the reference
shall be to a non-volatile const type."
--
James Kanze +33 (0)3 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: rmashlan@r2m.com (Robert Mashlan)
Date: 1996/12/30 Raw View
comeau@panix.com (Greg Comeau) wrote:
>In article <32bf1a17.85359994@library.airnews.net> rmashlan@r2m.com (Robert Mashlan) writes:
>>rmashlan@r2m.com (Robert Mashlan) wrote:
>>To get the equivalent, I now have to write:
>>
>> {
>> ofstream temp("foo.log",ios::app);
>> temp << "something to log" << endl;
>> }
>
>At least at the time, a point was involved that indeed this may not
>have been equivalent (because of the lifetime of temporaries).
According to the April draft, a temporary will live until the
evaluation of the full expression in which it is involved. (There are
two exceptions to the rule, which don't apply here). The point of
destruction for the temporary and the equivalent version should be the
same.
rm
---
Robert Mashlan R2M Software rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]