Topic: const valarray::operator[] returning rvalue ?


Author: Bronek Kozicki <brok@rubikon.pl>
Date: Sun, 22 Feb 2004 12:00:18 CST
Raw View
According to standard (clause 26.3.2.3) element access operator for
const std::valarray have signature:
  T operator[](size_t) const;

It seems strange - I'm unable to do simple thing like:
void f(const std::valarray<int>& c)
{
  const int * p = &c[0];
}

however, because returned rvalue is non-const I can modify it, which
seems really unnecessary relaxation of valarray const-ness (why would
anoyone want to modify this temporary value ?). Apparently GCC have
non-confirming implementation of this operator:
  const _Tp&  operator[](size_t) const;

which seems better (consistent with containers and allowing certain
const-lvalue operations, like taking pointer to element). Can anybody
explain why standard mandates returning rvalue ?

Thanks


B.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: =?ISO-8859-1?Q?=22Daniel_Kr=FCgler_=28nee_Spangenberg=29=22?= <dsp@bdal.de>
Date: Mon, 23 Feb 2004 11:25:58 CST
Raw View
Good Morning Bronek Kozicki,

Bronek Kozicki schrieb:

>According to standard (clause 26.3.2.3) element access operator for
>const std::valarray have signature:
>  T operator[](size_t) const;
>
>It seems strange - I'm unable to do simple thing like:
>void f(const std::valarray<int>& c)
>{
>  const int * p = &c[0];
>}
>
>however, because returned rvalue is non-const I can modify it, which
>seems really unnecessary relaxation of valarray const-ness (why would
>anoyone want to modify this temporary value ?). Apparently GCC have
>non-confirming implementation of this operator:
>  const _Tp&  operator[](size_t) const;
>
>which seems better (consistent with containers and allowing certain
>const-lvalue operations, like taking pointer to element). Can anybody
>explain why standard mandates returning rvalue ?
>

Your intuition is right. This problem is already resolved according to

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#389

in the sense that the corresponding operator signature should be changed to

  const T& operator[](size_t const);


Greetings from Bremen,

Daniel Kr   gler



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Seungbeom Kim <musiphil@bawi.org>
Date: Mon, 23 Feb 2004 15:53:49 CST
Raw View
Bronek Kozicki wrote:
>
> According to standard (clause 26.3.2.3) element access operator for
> const std::valarray have signature:
>   T operator[](size_t) const;
>
> It seems strange - I'm unable to do simple thing like:
> void f(const std::valarray<int>& c)
> {
>   const int * p = &c[0];
> }
>
> however, because returned rvalue is non-const I can modify it, which
> seems really unnecessary relaxation of valarray const-ness (why would
> anoyone want to modify this temporary value ?). Apparently GCC have
> non-confirming implementation of this operator:
>   const _Tp&  operator[](size_t) const;
>
> which seems better (consistent with containers and allowing certain
> const-lvalue operations, like taking pointer to element). Can anybody
> explain why standard mandates returning rvalue ?

It seems to have been discussed before and, strangely, one of two
relevant items is marked NAD(not a defect) and the other Ready:

http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#77
http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#389

The latter one is later than the former one, so I presume the
committee have changed their mind and now consider it as a defect.

--
Seungbeom Kim

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Bronek Kozicki <brok@rubikon.pl>
Date: Mon, 23 Feb 2004 15:54:47 CST
Raw View
On Mon, 23 Feb 2004 11:25:58 CST, Daniel Kr   gler (nee Spangenberg)
wrote:
> Your intuition is right. This problem is already resolved according to
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#389
> in the sense that the corresponding operator signature should be changed to
>
>   const T& operator[](size_t const);

Thanks for reference. I think there is typo in the issue documentation.
There is:

>>> citation begin
In the class synopsis in 26.3.2 [lib.template.valarray], and in 26.3.2.3
[lib.valarray.access] just above paragraph 1, change

  T operator[](size_t const);
to

  const T& operator[](size_t const);
>>> citation end

there should be :

>>> updated version begin
In the class synopsis in 26.3.2 [lib.template.valarray], and in 26.3.2.3
[lib.valarray.access] just above paragraph 1, change

  T operator[](size_t) const;
to

  const T& operator[](size_t) const;

>>> updated version end

Kind regards


B.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Wed, 25 Feb 2004 11:47:22 CST
Raw View
Bronek Kozicki <brok@rubikon.pl> writes:

| According to standard (clause 26.3.2.3) element access operator for
| const std::valarray have signature:
|   T operator[](size_t) const;
|
| It seems strange - I'm unable to do simple thing like:
| void f(const std::valarray<int>& c)
| {
|   const int * p = &c[0];
| }
|
| however, because returned rvalue is non-const I can modify it, which
| seems really unnecessary relaxation of valarray const-ness (why would
| anoyone want to modify this temporary value ?). Apparently GCC have
| non-confirming implementation of this operator:
|   const _Tp&  operator[](size_t) const;

Previous GNU implementations contained the "T" returning
operator[]() const version.  That was changed to reflect

  (1) to the proposed resolution; and
  (2) to match real-world use.

| which seems better (consistent with containers and allowing certain
| const-lvalue operations, like taking pointer to element). Can anybody
| explain why standard mandates returning rvalue ?

I would say, it is was oversight in trying to use the existing C++
type system to encode alias-freeness.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Gabriel Dos Reis <gdr@cs.tamu.edu>
Date: Wed, 25 Feb 2004 11:47:32 CST
Raw View
Seungbeom Kim <musiphil@bawi.org> writes:

[...]

| It seems to have been discussed before and, strangely, one of two
| relevant items is marked NAD(not a defect) and the other Ready:
|
| http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#77
| http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#389
|
| The latter one is later than the former one, so I presume the
| committee have changed their mind and now consider it as a defect.

Basically, yes.

It think that for "archeological purposes", it was decided to create
new issue items instead of trying to rewrite history.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]