Alberto Barbati wrote:
> Which implementation of valarray are you referring to?

It seems that older Dinkumware versions had the operator in question.
Here's a help page with the (T*) operator.

http://www.qnx.com/developers/docs/momentics621_docs/dinkum_en/full/valarray.html

Lesson learnt: in the world of C++, documentation that's 5 years old is
most certainly out of date!

Derek.

---
[ 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                       ]

Gabriel Dos Reis wrote:
> | ACCESSING CONTAINED DATA
> |
> | T* data();
> | Return a pointer to the first element of the array of data. I know
> | valarray has a T* casting operator, but that's sort of gross, in part
> | because casting is generally frowned upon in C++.
>
> I guess, I do not understand that statement.  Could you clarify?

I'm referring to a function that would be analogous to the
std::string::data() function. For a valarray<float> my_va, the following
four operations would be identical:

float* pf;

// existing functions
pf = &my_va[0];
pf = (float*)my_va; /* valarray provides a casting operator that returns
a pointer to the first element of the array. I've heard many people say
that casting should be avoided in C++ if possible. I'm not sure if you
would use a static_ or reinterpret_cast in place of the (float*) above.*/

// suggested functions
pf = my_va.begin();
pf = my_va.data();

I suppose that this is a lot of redundancy. I don't know if that's a
good thing or a bad thing. At least it makes valarray more similar to
many of the other container classes in the STL.

Derek.

---
[ 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                       ]

math@antiquark.com (Derek Ross) writes:

[...]

| pf = (float*)my_va; /* valarray provides a casting operator that

I guess that is the statement I did not understand, as valarray does
not provide such a conversion function.

| returns a pointer to the first element of the array. I've heard many
| people say that casting should be avoided in C++ if possible. I'm not
| sure if you would use a static_ or reinterpret_cast in place of the
| (float*) above.*/

There is no conversion function so none of those is appropriate.

|
| // suggested functions
| pf = my_va.begin();
| pf = my_va.data();
|
| I suppose that this is a lot of redundancy. I don't know if that's a
| good thing or a bad thing. At least it makes valarray more similar to
| many of the other container classes in the STL.

valarray<> wasn't meant to ressemble other STL containers :-)
It was meant ot embody the idea that you can do BLAS level-1
operations in parallel (if your compiler supports it).  It wasn't
meant to support sequencing, which other STL containers try hard to do.

I've met many situations where I'd like to have the address of the first
element (mostly when working with legacy codes  in C and Fortran) but
not in case I'd like valarray to be an STL container.

--
                                                        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                       ]

Derek Ross wrote:
> // existing functions
> pf = &my_va[0];
> pf = (float*)my_va; /* valarray provides a casting operator that returns
> a pointer to the first element of the array. I've heard many people say
> that casting should be avoided in C++ if possible. I'm not sure if you
> would use a static_ or reinterpret_cast in place of the (float*) above.*/
>

According to my copy of the standard (TC1) there is *no* casting
operator from valarray<T> to T* (btw, the correct name is "user-defined
conversion" not "casting operator").

In fact, on VC7.1 writing (float*)my_va produces the following error:
"No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called". Using static_cast won't
help (same error), and reinterpret_cast is simply wrong as it can't
invoke user-defined conversions.

Which implementation of valarray are you referring to?

Alberto

---
[ 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                       ]

math@antiquark.com (Derek Ross) writes:

| Hello All,
|
| Since wishlists seem to be popular in this group, here's mine for
| changes to the valarray template. I think that a few of these have
| been mentioned before.
|
| I really like the notational convenience of valarray. In fact, the
| main reason I originally started using valarray wasn't for the speed,
| but because it was so easy and intuitive to code mathematical
| operations with. I don't use it much anymore because it has a few
| annoying drawbacks. This wishlist addresses those drawbacks.
|
|
| VALARRAY ASSIGNMENT
|
| assign(const valarray<T>& x);
| Pretty much the same as the assignment operator, except that it will
| resize the destination valarray to the same size as 'x'. The current
| assignment operator is really annoying. It forces you to fill your
| code with:
|
|   a.resize(b.size());
|   a = b;

Then, make is a function

  template<class T>
   inline void
   assign(valarray<T>& a, const valarray<T>& b)
   {
      a.resize(b.size());
      a = b;
   }

|
| And if you forget to resize, the bug is silent because it's now
| undefined behavior.
|
|
| CHECKED ACCESS
|
| at(size_t index);
| Boundary-checked array access. I realize that the valarray is
| (prematurely) optimized for speed, but an 'at' function would help
| during development when speed is secondary to correctness. After the
| development phase, the 'at's could be replaced with '[]'s, either
| manually or by means of macros.
|
|
| BEGIN, END POINTERS
|
| begin(), end()
| These functions would return pointers to the beginning and end of the
| valarray data. This would eliminate confusing code like:
|
|   find( &the_va[0], &the_va[the_va.size()] );

It can be argued whether those aren't counter to the design philosophy
of parallelism.

| ACCESSING CONTAINED DATA
|
| T* data();
| Return a pointer to the first element of the array of data. I know
| valarray has a T* casting operator, but that's sort of gross, in part
| because casting is generally frowned upon in C++.

I guess, I do not understand that statement.  Could you clarify?

--
                                                        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                       ]

Hello All,

Since wishlists seem to be popular in this group, here's mine for
changes to the valarray template. I think that a few of these have been
mentioned before.

I really like the notational convenience of valarray. In fact, the main
reason I originally started using valarray wasn't for the speed, but
because it was so easy and intuitive to code mathematical operations
with. I don't use it much anymore because it has a few annoying
drawbacks. This wishlist addresses those drawbacks.


VALARRAY ASSIGNMENT

assign(const valarray<T>& x);
Pretty much the same as the assignment operator, except that it will
resize the destination valarray to the same size as 'x'. The current
assignment operator is really annoying. It forces you to fill your code
with:

  a.resize(b.size());
  a = b;

And if you forget to resize, the bug is silent because it's now
undefined behavior.


CHECKED ACCESS

at(size_t index);
Boundary-checked array access. I realize that the valarray is
(prematurely) optimized for speed, but an 'at' function would help
during development when speed is secondary to correctness. After the
development phase, the 'at's could be replaced with '[]'s, either
manually or by means of macros.


BEGIN, END POINTERS

begin(), end()
These functions would return pointers to the beginning and end of the
valarray data. This would eliminate confusing code like:

  find( &the_va[0], &the_va[the_va.size()] );


ACCESSING CONTAINED DATA

T* data();
Return a pointer to the first element of the array of data. I know
valarray has a T* casting operator, but that's sort of gross, in part
because casting is generally frowned upon in C++.


--
Derek Ross.

---
[ 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                       ]