In article <3sshp4$orp@ritz.cec.wustl.edu>,
John Andrew Fingerhut <sg3235@shelob.sbc.com> wrote:
>Hello,
>   I was hoping to make a public comment to the standards committee
>relating to the binding of non-const references to temporaries (rvalues).
>
>According to the draft standard section 8.5.3 (References [dcl.init.ref])
>following a couple of paragraphs about binding references to lvalues,
>paragraph 8 states:
>
>Otherwise, the reference shall be to a non-volatile const type (i.e., cv1
>shall be const).
>
>According to section 3.10 (Lvalues and rvalues [basic.lval]) paragraph 5:
>
>Constructor invocations and calls to functions that do not return
>references are always rvalues.
>
>First, it would seem that section 12.2 (Temporary objects
>[class.temporary]) paragraph 5 (which extends the life of a temporary
>object if it is bound to a reference) should somehow be changed to specify
>a const reference.
>
>Second, according to a foot note in 3.10, paragraph 2, member functions
>can be invoked on temporary objects.  This allows non-member functions to
>modify an object that cannot be modified through a binding to a non-const
>reference.  I can only assume that the committee deemed it reasonable to
>modify a temporary object through a call to a member function because the
>change may cause a side effect that is more important than the change
>itself.  For example, one could format a character array using a temporary
>ostrstream:
>
> int i = 14;
> char buf[256];
> ostrstream (buf, sizeof (buf)) << "The value of i is: " << i << ends;
>
>because the operator << functions being invoked are member functions.
>
>However, if we create the following basic String class:
>
>class String {
> char *ptr;
>public:
> String (const char *s) {
>  ptr = new char [strlen (s) + 1];
>  strcpy (ptr, s);
> }
> friend ostream &operator<< (ostream &o, const String &s)
> {
>  return o << s.ptr;
> }
>};
>
>then the fifth line of the following five lines is a syntax error:
>
> char *ptr = "Hello World";
> String s (ptr);
> char buf[256];
> ostrstream (buf, sizeof (buf)) << ptr << ends;
> ostrstream (buf, sizeof (buf)) << s << ends;
>
>Yet it seems to me that whatever reasoning makes the fourth line legal can
>be applied to the fifth line as well.  That is, the modification of the
>temporary causes a side effect that is more important that the obtaining
>the modification results.
>
>Does anyone else think that this issue is worth commenting on?  If so, I
>was hoping for some help in creating an "official comment" that would
>provide the above information (assuming that my reading of the draft is
>correct) that wouldn't be rejected simply because it didn't provide either
>enough justification or information.
>--
>Stephen Gevers
>sg3235@shelob.sbc.com


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Hello,
   I was hoping to make a public comment to the standards committee
relating to the binding of non-const references to temporaries (rvalues).

According to the draft standard section 8.5.3 (References [dcl.init.ref])
following a couple of paragraphs about binding references to lvalues,
paragraph 8 states:

Otherwise, the reference shall be to a non-volatile const type (i.e., cv1
shall be const).

According to section 3.10 (Lvalues and rvalues [basic.lval]) paragraph 5:

Constructor invocations and calls to functions that do not return
references are always rvalues.

First, it would seem that section 12.2 (Temporary objects
[class.temporary]) paragraph 5 (which extends the life of a temporary
object if it is bound to a reference) should somehow be changed to specify
a const reference.

Second, according to a foot note in 3.10, paragraph 2, member functions
can be invoked on temporary objects.  This allows non-member functions to
modify an object that cannot be modified through a binding to a non-const
reference.  I can only assume that the committee deemed it reasonable to
modify a temporary object through a call to a member function because the
change may cause a side effect that is more important than the change
itself.  For example, one could format a character array using a temporary
ostrstream:

 int i = 14;
 char buf[256];
 ostrstream (buf, sizeof (buf)) << "The value of i is: " << i << ends;

because the operator << functions being invoked are member functions.

However, if we create the following basic String class:

class String {
 char *ptr;
public:
 String (const char *s) {
  ptr = new char [strlen (s) + 1];
  strcpy (ptr, s);
 }
 friend ostream &operator<< (ostream &o, const String &s)
 {
  return o << s.ptr;
 }
};

then the fifth line of the following five lines is a syntax error:

 char *ptr = "Hello World";
 String s (ptr);
 char buf[256];
 ostrstream (buf, sizeof (buf)) << ptr << ends;
 ostrstream (buf, sizeof (buf)) << s << ends;

Yet it seems to me that whatever reasoning makes the fourth line legal can
be applied to the fifth line as well.  That is, the modification of the
temporary causes a side effect that is more important that the obtaining
the modification results.

Does anyone else think that this issue is worth commenting on?  If so, I
was hoping for some help in creating an "official comment" that would
provide the above information (assuming that my reading of the draft is
correct) that wouldn't be rejected simply because it didn't provide either
enough justification or information.
--
Stephen Gevers
sg3235@shelob.sbc.com