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 ]