const pointer to const valarray element

[Jeremy Sanders]

Hi - I want to get a const pointer to a valarray element:

#include <valarray>

void func(const std::valarray<double> *x)
{
const double* ptr = &((*x)[0]);
}

int main()
{
std::valarray<double> foo(10);
func(&foo);

return 0;
}

This code compiles fine under gcc 4.4.3, but fails under MS Visual C++
Express Edition 2008 with "error C2102: '&' requires l-value".

Stroustup says valarray has a "T operator[](size_t) const" and a "T&
operator[](size_t)".

Is gcc or MSVC correct?

Is there a portable way to get a const pointer to an element of a const
valarray?

Thanks

Jeremy

 

[Victor Bazarov]

Hi - I want to get a const pointer to a valarray element:

#include <valarray>

void func(const std::valarray<double> *x)
{
const double* ptr = &((*x)[0]);
}

int main()
{
std::valarray<double> foo(10);
func(&foo);

return 0;
}

This code compiles fine under gcc 4.4.3, but fails under MS Visual C++
Express Edition 2008 with "error C2102: '&' requires l-value".

Stroustup says valarray has a "T operator[](size_t) const" and a "T&
operator[](size_t)".

Is gcc or MSVC correct?

Think about it. Your 'valarray' (to which 'x' points) is a _const_
object, isn't it? So, how would a non-const member function be called
for it? It can't. So, the former op[] is called. It returns a
temporary which is *not* an lvalue. MSVC is correct, gcc isn't.

Is there a portable way to get a const pointer to an element of a const
valarray?

I am not sure what you're trying to accomplish with it. The language
forces you to jump through hoops for a reason: perhaps you shouldn't do
it, you know. What would a const pointer do for you that a regular
*value* can't? The only reason to prefer a pointer over a value is if
you are going to change the value. But with a const valarray you're not
supposed to, right? So, why do you need a pointer?

V

 

[Jeremy Sanders]

Think about it. Your 'valarray' (to which 'x' points) is a _const_
object, isn't it? So, how would a non-const member function be called
for it? It can't. So, the former op[] is called. It returns a
temporary which is *not* an lvalue. MSVC is correct, gcc isn't.

Thanks - I see gcc also includes an "const T& operator[] const" member,
which looks like a good idea (see below, fixing a defect in the standard).

I am not sure what you're trying to accomplish with it. The language
forces you to jump through hoops for a reason: perhaps you shouldn't do
it, you know. What would a const pointer do for you that a regular
*value* can't? The only reason to prefer a pointer over a value is if
you are going to change the value. But with a const valarray you're not
supposed to, right? So, why do you need a pointer?

Please don't be so hostile. If my question annoyed you, don't bother
answering it, though I appreciate that you did.

I would like const pointers to iterate through the valarray. Stroustrup says
that pointers are random-access iterators to a valarray, and should be
compatible with the standard algorithms.

Secondly I need a pointer to pass the data to a C function expecting a C
array.

These are both valid things to do with a valarray. For the first case I
could use the index (breaking algorithms that expect iterators). In the
second a copy of the array would be needed, negating the performance
benefits of valarrays.

It would seem that operator[] returning a const reference would be a good
idea for valarray. It looks like it's filed as a defect for C++
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389 and that is
why it works for gcc.

I'll just have to cast away the const for MSVC...

Jeremy

 

[Victor Bazarov]

Think about it. Your 'valarray' (to which 'x' points) is a _const_
object, isn't it? So, how would a non-const member function be called
for it? It can't. So, the former op[] is called. It returns a
temporary which is *not* an lvalue. MSVC is correct, gcc isn't.

Thanks - I see gcc also includes an "const T& operator[] const" member,
which looks like a good idea (see below, fixing a defect in the standard).

I am not sure what you're trying to accomplish with it. The language
forces you to jump through hoops for a reason: perhaps you shouldn't do
it, you know. What would a const pointer do for you that a regular
*value* can't? The only reason to prefer a pointer over a value is if
you are going to change the value. But with a const valarray you're not
supposed to, right? So, why do you need a pointer?

Please don't be so hostile. If my question annoyed you, don't bother
answering it, though I appreciate that you did.

Well, here is a bit of psychology 101 for you. If *you* talk about
hostility, it's *you* who is hostile. You see my response as "hostile"
because that's how *you* feel (probably about having to ask for help in
a public forum). Why? I don't know. Pay a pro to figure it out for you.

Annoyed? I? No. It is *you* who is annoyed with my answer. I would
guess it's because you have set certain expectations, and my response
didn't fit. Well, your expectations are apparently too tight/narrow.
Adjust them.

Check out "projection" in psychology. And try not to take offense
because none is intended.

I would like const pointers to iterate through the valarray. Stroustrup says
that pointers are random-access iterators to a valarray, and should be
compatible with the standard algorithms.

Secondly I need a pointer to pass the data to a C function expecting a C
array.

These are both valid things to do with a valarray.

Yes. I did not consider those when reading your post. Good that you
explained.

> For the first case I
could use the index (breaking algorithms that expect iterators). In the
second a copy of the array would be needed, negating the performance
benefits of valarrays.

It would seem that operator[] returning a const reference would be a good
idea for valarray. It looks like it's filed as a defect for C++
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389 and that is
why it works for gcc.

Yes, in the next standard (looking at the n3000 document), there are two
operator[] in valarray. None returns a value.

I'll just have to cast away the const for MSVC...

It's an acceptable work-around. Don't forget to supply compiler version
conditional block (#ifdef or #if) so that in the next version of MSVC
somebody (maybe you) would have to review the code and correct it.

V

 

[Jeremy Sanders]

Well, here is a bit of psychology 101 for you. If *you* talk about
hostility, it's *you* who is hostile. You see my response as "hostile"
because that's how *you* feel (probably about having to ask for help in
a public forum). Why? I don't know. Pay a pro to figure it out for you.

That's a bit pop psychology for me! Is every hostile action in the eye of
the beholder? I think not. Phrases such as "Think about it." and "perhaps
you shouldn't do it, you know" came across as hostile to me, but it is hard
to gauge how different cultures respond to different text. I've never found
other responses in public forums that hostile.

Let's leave this here before it goes off topic.

Thanks for the rest of your response, which was productive.

Thanks again

Jeremy