 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
vadim alexandrov
Guest
|
 Posted: Tue Jul 19, 2005 9:35 am Post subject: using trmporary as buffer |
 |
|
Sometimes I need a temporarely buffer to convert class instance into
the string, for the sprintf call. The proposed sulution works on gcc
3.4.3 and icc 8.0 on RedHat Linux AS4. But, Is it C++ legal?
struct Buffer {
mutable char mStr[ 32 ];
};
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
sprintf( tmp.mStr, "%d", i );
return tmp.mStr;
}
int main( int argc, char * argv[] ) {
printf( "%s %sn", itoa( 1 ), itoa( 2 ) );
}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Thomas Tutone
Guest
|
| Posted: Tue Jul 19, 2005 3:54 pm Post subject: Re: using trmporary as buffer |
|
|
vadim alexandrov wrote:
| Quote: | Sometimes I need a temporarely buffer to convert class instance into
the string, for the sprintf call. The proposed sulution works on gcc
3.4.3 and icc 8.0 on RedHat Linux AS4. But, Is it C++ legal?
|
I think it involves undefined behavior.
| Quote: | struct Buffer {
mutable char mStr[ 32 ];
};
|
OK, at this point, no Buffer has been constructed yet...
| Quote: | const char * itoa( int i, const Buffer& tmp = Buffer() ) {
|
OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the function.
| Quote: | sprintf( tmp.mStr, "%d", i );
return tmp.mStr;
|
OK, you've just returned a pointer to a buffer in an object whose
destructor is called at the end of the function. If you use that
returned pointer, you enter undefined behavior.
| Quote: | }
int main( int argc, char * argv[] ) {
printf( "%s %sn", itoa( 1 ), itoa( 2 ) );
|
So that means two instances of undefined behavior in the above line.
Best regards,
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
gmramaswamy@gmail.com
Guest
|
| Posted: Tue Jul 19, 2005 3:55 pm Post subject: Re: using trmporary as buffer |
|
|
i tried another sample program that does something similar to this and
the thing is tmp (object in function argument) is getting destructed
afer your printf (in my case at the end of main). so its working fine.
But to my understanding, tmp should be allocated in function stack and
it should be destructed during stack unwininding of that funciton,
which will make tmp invalid and pointer to its member also invalid.
tried on Solaris, Sun CC compiler.
hope someone clarifies it.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Catalin Pitis
Guest
|
| Posted: Wed Jul 20, 2005 9:53 am Post subject: Re: using trmporary as buffer |
|
|
Hi
First, as it was already been said, returning a reference/pointer to a
temporary object leads to undefined behavior. In your case, you can
just replace the printf statement with:
printf( "%d, %d", 1, 2);
A better way to solve these probles is to use boost library. You have
either lexical_cast for converting values, so you can use:
lexical_cast< string>( 1) instead of itoa( ...)
or, for string formatting, use boost::format library, with something
like:
cout << (boost::format( "%1%, %2%") % 1 % 2).str();
Catalin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Maxim Yegorushkin
Guest
|
| Posted: Wed Jul 20, 2005 2:05 pm Post subject: Re: using trmporary as buffer |
|
|
On Tue, 19 Jul 2005 19:54:58 +0400, Thomas Tutone
<Thomas8675309 (AT) yahoo (DOT) com> wrote:
| Quote: | vadim alexandrov wrote:
Sometimes I need a temporarely buffer to convert class instance into
the string, for the sprintf call. The proposed sulution works on gcc
3.4.3 and icc 8.0 on RedHat Linux AS4. But, Is it C++ legal?
I think it involves undefined behavior.
|
I think it does not.
| Quote: | const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the function.
sprintf( tmp.mStr, "%d", i );
return tmp.mStr;
OK, you've just returned a pointer to a buffer in an object whose
destructor is called at the end of the function. If you use that
returned pointer, you enter undefined behavior.
|
The default argument has been constructed at the call site before the
call, no destructor is called here, no UB.
| Quote: | }
int main( int argc, char * argv[] ) {
printf( "%s %sn", itoa( 1 ), itoa( 2 ) );
|
Please refer to 8.3.6/9:
Default arguments are evaluated each time the function is called.
IMO, the rationale for that is quite simple. Default arguments are not a
part of a function signature, a compiler emits only one symbol and only
one piece of a function object code for a function which expects to be
passed all the arguments, no matter how much default arguments it has.
What means that the default arguments may only be created at the call site
by the caller, rather than callee.
--
Maxim Yegorushkin
<firstname.lastname (AT) gmail (DOT) com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mirek Fidler
Guest
|
| Posted: Wed Jul 20, 2005 3:01 pm Post subject: Re: using trmporary as buffer |
|
|
Thomas Tutone wrote:
| Quote: | vadim alexandrov wrote:
Sometimes I need a temporarely buffer to convert class instance into
the string, for the sprintf call. The proposed sulution works on gcc
3.4.3 and icc 8.0 on RedHat Linux AS4. But, Is it C++ legal?
I think it involves undefined behavior.
struct Buffer {
mutable char mStr[ 32 ];
};
OK, at this point, no Buffer has been constructed yet...
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the function.
sprintf( tmp.mStr, "%d", i );
return tmp.mStr;
OK, you've just returned a pointer to a buffer in an object whose
destructor is called at the end of the function. If you use that
returned pointer, you enter undefined behavior.
|
Hm, I am not so sure. The question is which expression is that Buffer
temporarary part of. I believe that it has nothing to do with internals
of itoa function.
I believe that you should rather think about it in this context:
int main( int argc, char * argv[] ) {
printf( "%s %sn", itoa( 1, Buffer() ), itoa( 2, Buffer() ) );
}
which I believe is legal C++ code. Anyway, I have found only a little in
the standard to accept or reject this interpretation.
Mirek
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
news.cern.ch
Guest
|
| Posted: Wed Jul 20, 2005 11:22 pm Post subject: Re: using trmporary as buffer |
|
|
"Thomas Tutone" <Thomas8675309 (AT) yahoo (DOT) com> wrote...
| Quote: | vadim alexandrov wrote:
Sometimes I need a temporarely buffer to convert class instance into
the string, for the sprintf call. The proposed sulution works on gcc
3.4.3 and icc 8.0 on RedHat Linux AS4. But, Is it C++ legal?
I think it involves undefined behavior.
|
I don't think so. Although whether it is good practise is another
question...
| Quote: | struct Buffer {
mutable char mStr[ 32 ];
};
OK, at this point, no Buffer has been constructed yet...
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the function.
|
No, you haven't constructed anything here, you've just defined a function
with a default parameter.
| Quote: | sprintf( tmp.mStr, "%d", i );
return tmp.mStr;
OK, you've just returned a pointer to a buffer in an object whose
destructor is called at the end of the function. If you use that
returned pointer, you enter undefined behavior.
|
No, the destructor is not called at the end of the function, it is passed by
reference.
| Quote: | }
int main( int argc, char * argv[] ) {
printf( "%s %sn", itoa( 1 ), itoa( 2 ) );
So that means two instances of undefined behavior in the above line.
|
This is where a temporary buffer is constructed. It will last until the end
of the surrounding statement, i.e. until after printf has been called, so no
undefined behaviour. As long as you don't keep a pointer to the buffer you
should be ok. However see Catalin's post for better solutions.
Emlyn
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thomas Tutone
Guest
|
| Posted: Thu Jul 21, 2005 10:38 am Post subject: Re: using trmporary as buffer |
|
|
Maxim Yegorushkin wrote:
| Quote: | Thomas Tutone wrote:
I think it involves undefined behavior.
I think it does not.
|
Your reasoning relies on a language subtlely that I did not consider
(or fully appreciate) when I wrote my response. But I wonder whether
you are right - see below.
| Quote: |
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the function.
|
To expand on this: Buffer() creates a temporary. When that temporary
is assigned to const Buffer& tmp, the compiler is at least permitted
(and for all I know, required) to create a copy-constructed duplicate
of Buffer() to which tmp is then a reference. Regardless of the
lifetime of the original temporary, it seems to me that the lifetime of
the copy-constructed duplicate lasts only until the end of the
function.
| Quote: |
sprintf( tmp.mStr, "%d", i );
return tmp.mStr;
OK, you've just returned a pointer to a buffer in an object whose
destructor is called at the end of the function. If you use that
returned pointer, you enter undefined behavior.
The default argument has been constructed at the call site before the
call, no destructor is called here, no UB.
}
int main( int argc, char * argv[] ) {
printf( "%s %sn", itoa( 1 ), itoa( 2 ) );
Please refer to 8.3.6/9:
Default arguments are evaluated each time the function is called.
IMO, the rationale for that is quite simple. Default arguments are not a
part of a function signature, a compiler emits only one symbol and only
one piece of a function object code for a function which expects to be
passed all the arguments, no matter how much default arguments it has.
What means that the default arguments may only be created at the call site
by the caller, rather than callee.
|
Clearly you understand this part of the Standard better than I do. But
even if the default argument is evaluated each time the function is
called, isn't the compiler permitted to copy-construct a duplicate and
have tmp be a reference to that duplicate? And if so, aren't we back
in undefined behavior, since the copy-constructed duplicate no longer
exists after returning from the function? Or am I simply missing the
obvious?
At the very least, I imagine that you and I can agree that this is a
dusty corner of the Standard that Sutter and Meyers would urge the user
to avoid. There are safe ways of accomplishing what the OP's function
tries to do. I wouldn't want to rely on every compiler-writer choosing
your interpretation over mine.
Best regards,
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johnchx2@yahoo.com
Guest
|
| Posted: Thu Jul 21, 2005 10:41 am Post subject: Re: using trmporary as buffer |
|
|
Thomas Tutone wrote:
| Quote: | OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the function.
|
12.2/5 says, "A temporary bound to a reference parameter in a function
call (5.2.2) persists until the completion of the full expression
containing the call." Which means that it's well-defined to use the
pointer within a full-expression of which the function call is a
sub-expression.
However, since it would be easy to use this function in an undefined
way (e.g. by assigning the returned pointer to a variable and using it
in subsequent expressions), I don't think this is a very good idea in
practice.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Maxim Yegorushkin
Guest
|
| Posted: Thu Jul 21, 2005 12:39 pm Post subject: Re: using trmporary as buffer |
|
|
On Thu, 21 Jul 2005 14:38:25 +0400, Thomas Tutone
<Thomas8675309 (AT) yahoo (DOT) com> wrote:
| Quote: | Maxim Yegorushkin wrote:
Thomas Tutone wrote:
I think it involves undefined behavior.
I think it does not.
Your reasoning relies on a language subtlely that I did not consider
(or fully appreciate) when I wrote my response. But I wonder whether
you are right - see below.
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You assign it to a
const reference that's an parameter of the function, so it (or a
copy-constructed duplicate) will last for the duration of the
function.
To expand on this: Buffer() creates a temporary. When that temporary
is assigned to const Buffer& tmp, the compiler is at least permitted
(and for all I know, required) to create a copy-constructed duplicate
of Buffer() to which tmp is then a reference. Regardless of the
lifetime of the original temporary, it seems to me that the lifetime of
the copy-constructed duplicate lasts only until the end of the
function.
|
That is true, function arguments are copy initialized. But again we are
back to the question where that copy is created. The compiled function in
an object file accepts exactly two arguments and it expects the second to
be a reference to const something. It's not that function's concern how
that reference has been initialized, it just accepts already initialized
one. Also note that a reference is implemented as a pointer (and we have
yet to see a compiler what wouldn't do that), so the function merely
accepts the passed pointer, no implicit pointed to object copies are done
in the function. So, it's just the compiler behind your back adds missing
trailing arguments at the call site as would a macro do.
[]
| Quote: | At the very least, I imagine that you and I can agree that this is a
dusty corner of the Standard that Sutter and Meyers would urge the user
to avoid. There are safe ways of accomplishing what the OP's function
tries to do. I wouldn't want to rely on every compiler-writer choosing
your interpretation over mine.
|
I agree whole-heartedly with that.
--
Maxim Yegorushkin
<firstname.lastname (AT) gmail (DOT) com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Jul 21, 2005 3:51 pm Post subject: Re: using trmporary as buffer |
|
|
Maxim Yegorushkin wrote:
| Quote: | On Thu, 21 Jul 2005 14:38:25 +0400, Thomas Tutone
[email]Thomas8675309 (AT) yahoo (DOT) com[/email]> wrote:
Maxim Yegorushkin wrote:
Thomas Tutone wrote:
I think it involves undefined behavior.
I think it does not.
Your reasoning relies on a language subtlely that I did not
consider (or fully appreciate) when I wrote my response.
But I wonder whether you are right - see below.
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You
assign it to a const reference that's an parameter of the
function, so it (or a copy-constructed duplicate) will
last for the duration of the function.
To expand on this: Buffer() creates a temporary. When that
temporary is assigned to const Buffer& tmp, the compiler is
at least permitted (and for all I know, required) to create
a copy-constructed duplicate of Buffer() to which tmp is
then a reference. Regardless of the lifetime of the
original temporary, it seems to me that the lifetime of the
copy-constructed duplicate lasts only until the end of the
function.
That is true, function arguments are copy initialized. But
again we are back to the question where that copy is created.
|
Sort of. I think the important point here is that the
constructed object *isn't* a function parameter, but a
temporary. Function parameters are destructed on leaving the
function. Temporaries are destructed at the end of the full
expression (modulo some cases where the temporary is held
longer). In this case, the reference is destructed at the end
of the called function; the temporary it refers to, however, is
destructed at the end of the full expression. (Note that
function arguments are not temporaries in the sense of the
standard; they are named variables with what is basically auto
lifetime.)
Of course, that doesn't mean that the code is good by any
means. Something like:
char const* p = itoa( x ) ;
is an invitation to disaster. And of course, trying to do the
same thing with float, e.g.:
char const*
ftoa( double d, Buffer const& tmp = Buffer() )
{
sprintf( tmp.mStr, "%f", d ) ;
return tmp.mStr ;
}
is likely to cause more than a few problems as well.
[...]
| Quote: | At the very least, I imagine that you and I can agree that
this is a dusty corner of the Standard that Sutter and
Meyers would urge the user to avoid. There are safe ways of
accomplishing what the OP's function tries to do. I
wouldn't want to rely on every compiler-writer choosing your
interpretation over mine.
I agree whole-heartedly with that.
|
Really. So you would say that you shouldn't count on things
like:
std::string s1, s2 ;
extern void legacy( char const* p ) ;
legacy( (s1 + s2).c_str() ) ;
The definition of the lifetime of temporaries in the standard
was designed intentionally to support such use. As far as I
know, no compiler destructs too soon (although some destruct too
late).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Jul 21, 2005 3:52 pm Post subject: Re: using trmporary as buffer |
|
|
Thomas Tutone wrote:
| Quote: | Maxim Yegorushkin wrote:
Thomas Tutone wrote:
I think it involves undefined behavior.
I think it does not.
Your reasoning relies on a language subtlely that I did not
consider (or fully appreciate) when I wrote my response. But
I wonder whether you are right - see below.
const char * itoa( int i, const Buffer& tmp = Buffer() ) {
OK, now you've constructed a temporary Buffer. You assign
it to a const reference that's an parameter of the
function, so it (or a copy-constructed duplicate) will
last for the duration of the function.
To expand on this: Buffer() creates a temporary. When that
temporary is assigned to const Buffer& tmp, the compiler is at
least permitted (and for all I know, required) to create a
copy-constructed duplicate of Buffer() to which tmp is then a
reference.
|
It's not required, and no compiler that I know of does make a
copy. (It is required that the copy be possible, but as far as
I know, recent versions of g++ are the only compilers which
actually verify this.)
| Quote: | Regardless of the lifetime of the original temporary, it seems
to me that the lifetime of the copy-constructed duplicate
lasts only until the end of the function.
|
What makes you say this? The parameter lasts only to the end of
the function, but the parameter is a reference to the temporary,
not the temporary. The temporary itself lasts to the end of the
full expression.
Had he declared the function to take a Buffer, rather than a
Buffer const&, there would be a problem here.
Of course, the whole technique is very flaky. How on earth can
anyone possibly know the correct minimum size for the buffer?
In practice, the original poster has just invented a new means
of getting buffer overrun problems. (Not to mention an abuse of
mutable which is bound to confuse any maintenance programmer.)
Worse, of course, is that there is a perfectly good solution
already defined in the standard:
std::string
atoi( int i )
{
std::ostringstream s ;
s << i ;
return s.str() ;
}
But of course, that's no fun, because everyone can easily
understand it, and there isn't any risk.
[...]
| Quote: | At the very least, I imagine that you and I can agree that
this is a dusty corner of the Standard that Sutter and Meyers
would urge the user to avoid.
|
I'm not sure. In this particular case, yes, of course. I'm
sure that both Meyers and Sutter would complain. Let's not
forget, the code in question writes an undefined number of
characters to a buffer whose length it doesn't know. I think
that about the only people who won't complain are those trying
to write viruses or worms.
But there are any number of more or less standard idioms (that
I'm sure Meyers and Sutter would approve of) which count on the
lifetime of temporaries.
| Quote: | There are safe ways of accomplishing what the OP's function
tries to do. I wouldn't want to rely on every compiler-writer
choosing your interpretation over mine.
|
There's no choice involved. The lifetime of a temporary is *at
least* until the end of the full expression in which it is
constructed. (There are special cases which extend the
lifetime, but none which shorten it.) I think you're confusing
the lifetime of function parameters (which aren't temporaries,
but named variables) with the lifetime of temporaries.
That doesn't mean that all compilers are 100% conform. The ARM
was rather open with regards to the lifetime of temporaries, and
for a long time, the draft standard followed the ARM. When the
lifetime was finally fixed, compilers using shorter lifetimes
(but still compatible with what the ARM required) were quickly
fixed, but at least one compiler which used a longer lifetime
still does, because of fears that shortening the lifetime to be
standard conform will break existing code (which was formally
already broken, but did work with the compiler in question).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
vadim alexandrov
Guest
|
| Posted: Fri Jul 22, 2005 11:01 am Post subject: Re: using trmporary as buffer |
|
|
The whole problem araises when I am dealing with printf:
the goal is:
Object1 o1;
int i;
Object2 o2;
printf( "%s %d %sn", s( o1 ), d( i ), s( o2 ) );
function %s corresponds to function s
%d corresponds to function d
etc
since printf defined ( const char*, ... )
arguments are not subject to the type conversion.
For example:
If opbect o1 has operator const char * () defined
puts will work
| Quote: | Worse, of course, is that there is a perfectly good solution
already defined in the standard:
std::string
atoi( int i )
{
std::ostringstream s ;
s << i ;
return s.str() ;
}
|
this is safe of-course. But combersome and slow.
printf( "%s", atoi( i ).c_str() );
and there is no overload for the user objects.
boost::format is nice but the is a legacy code...
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Maxim Yegorushkin
Guest
|
| Posted: Fri Jul 22, 2005 11:12 am Post subject: Re: using trmporary as buffer |
|
|
On Thu, 21 Jul 2005 19:51:20 +0400, <kanze (AT) gabi-soft (DOT) fr> wrote:
[]
| Quote: | At the very least, I imagine that you and I can agree that
this is a dusty corner of the Standard that Sutter and
Meyers would urge the user to avoid. There are safe ways of
accomplishing what the OP's function tries to do. I
wouldn't want to rely on every compiler-writer choosing your
interpretation over mine.
I agree whole-heartedly with that.
|
I have already regretted saying that ;)
| Quote: | Really. So you would say that you shouldn't count on things
like:
std::string s1, s2 ;
extern void legacy( char const* p ) ;
legacy( (s1 + s2).c_str() ) ;
The definition of the lifetime of temporaries in the standard
was designed intentionally to support such use. As far as I
know, no compiler destructs too soon (although some destruct too
late).
|
Your code is idiomatic, no doubt arise.
The question of the topic was not the life span of temporaries, rather
where the default argument is constructed and its life span.
--
Maxim Yegorushkin
<firstname.lastname (AT) gmail (DOT) com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thomas Tutone
Guest
|
| Posted: Sat Jul 23, 2005 1:06 am Post subject: Re: using trmporary as buffer |
|
|
Maxim Yegorushkin wrote:
| Quote: | At the very least, I imagine that you and I can agree that
this is a dusty corner of the Standard that Sutter and
Meyers would urge the user to avoid. There are safe ways of
accomplishing what the OP's function tries to do. I
wouldn't want to rely on every compiler-writer choosing your
interpretation over mine.
I agree whole-heartedly with that.
I have already regretted saying that 
|
Sorry I led you down that path. Looking back, I think I've figured out
the source of my confusion - I was thinking of the situation where the
argument passed to a const reference parameter is a literal, and the
compiler then constructs a copy that is bound to that const reference
for the duration of the function. I'm afraid I conflated that
situation with the binding of const references to temporaries in
general. My apologies for muddying the waters!
Best regards,
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
