jthorn@davinci.thp.univie.ac.at (Jonathan Thornburg) writes:

| In article <7mfonv$n1b$1@nnrp1.deja.com>,
| James Kanze <James.Kanze@dresdner-bank.com> wrote:
| >Globally, I think that this poses less problems (and requires less
| >restrictions) than variable length arrays.  Whatever you think of the
| >struct hack, variable length arrays are definitly useful in C, and once
| >you have variable length arrays, you've done most of the work for the
| >struct hack.
| >
| >Of course, in C++, variable length arrays aren't nearly as important as
| >they are in C.

[...]

|  [[Another point, really a question: what about the underlying
|  storage layout of vector<> and contiguous valarray<>?  Is this
|  guaranteed to be contiguous?  That is, suppose I have a
|  vector<double> or a contiguous valarray<double>.  Can I easily
|  (i.e. without making a temp copy) and reasonably portably get
|  a pointer to the guaranteed-contiguous underlying array?

valarray<> is guaranteed by the current standard to be contiguous.
vector<> will be, thanks to the next TC.

|  This isn't an idle question; this is essential for passing
|  these critters back and forth to (say) Fortran subroutines
|  which expect array arguments.  My copy of Stroustrup[3] is
|  at home at the moment; can someone clarify the vector<> and
|  valarray<> functionality in this area for me?]]

If you were to do number crunching, valarray is the recommended way to
go.  This class has been (badly ?) designed on purpose:
implementations are free to make some assumptions and do some
optimizations with them.

valarray is a "library" incarnation of C9x 'restrict' keyword.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 20 Jul 99 02:05:25 GMT, Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:

>If you were to do number crunching, valarray is the recommended way to
>go.  This class has been (badly ?) designed on purpose:
>implementations are free to make some assumptions and do some
>optimizations with them.

Why is valarray supposedly so fast?


>valarray is a "library" incarnation of C9x 'restrict' keyword.

How so?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos_Reis wrote:
>
> valarray<> is guaranteed by the current standard to be contiguous.
> vector<> will be, thanks to the next TC.

Could someone enumerate the argument used for vector ? (or point me
to some documentation).
It still sound like an spec bug to me, why was that solution selected
instead of the one choosen for string ? (and what is the problem
solved by that solution, by the way)

Alain


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@localhost.localdomain (Siemel Naran) writes:

| On 20 Jul 99 02:05:25 GMT, Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:
|
| >If you were to do number crunching, valarray is the recommended way to
| >go.  This class has been (badly ?) designed on purpose:
| >implementations are free to make some assumptions and do some
| >optimizations with them.
|
| Why is valarray supposedly so fast?

Because the standard explicitly allows an implementation to do unusual
things with them :-)

26.3.1/3
   Any function returning a valarray<T> is permitted to return an
   object of another type, provided that all the const member
   functions of valarray<T> are also applicable to this type.  This
   return type shall not add more than two levels of template nesting
   over the most deeply nested argument type.

| >valarray is a "library" incarnation of C9x 'restrict' keyword.
|
| How so?

The intent of 'restrict' is to suggest optimization opportunities to
the compiler, especially in the number crunching area.  valarray<T>
casts the section 6.7.3.1 of C9x in stone through the associated
helper classes -- slice_array, gslice_array, indirect_array,
mask_array.

I resist to say valarray<T> is superior :-)

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7mfonv$n1b$1@nnrp1.deja.com>,
James Kanze <James.Kanze@dresdner-bank.com> wrote:
>Globally, I think that this poses less problems (and requires less
>restrictions) than variable length arrays.  Whatever you think of the
>struct hack, variable length arrays are definitly useful in C, and once
>you have variable length arrays, you've done most of the work for the
>struct hack.
>
>Of course, in C++, variable length arrays aren't nearly as important as
>they are in C.

Hmm.  Granted, C++ provides other mechanisms (STL vector<> and valarray<>)
which may substitute for some usages of variable length arrays (VLAs).
But those other mechanisms aren't full substitutes for VLAs -- they
allocate on the heap, not on the stack.  So, IMHO VLAs are (remain)
very important for C++.

 [[Another point, really a question: what about the underlying
 storage layout of vector<> and contiguous valarray<>?  Is this
 guaranteed to be contiguous?  That is, suppose I have a
 vector<double> or a contiguous valarray<double>.  Can I easily
 (i.e. without making a temp copy) and reasonably portably get
 a pointer to the guaranteed-contiguous underlying array?
 This isn't an idle question; this is essential for passing
 these critters back and forth to (say) Fortran subroutines
 which expect array arguments.  My copy of Stroustrup[3] is
 at home at the moment; can someone clarify the vector<> and
 valarray<> functionality in this area for me?]]

Moreover, having C++ be (to a high degree of approximation) a superset
of C -- that is, having almost all legal C code also be legal C++ code
with the same semantics -- is very useful in its own right:  It eases
migration of existing C code (including VLAs, which have been around
for a fair while in gcc) to C++.

As Stroustrup hoped, C++ is indeed a more powerful and more enjoyable
language (for the experienced programmer) than C.  I don't want to have
to go back to C (or even Fortran) just to get VLAs!

--
-- Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "The first strike in the American Colonies was in 1776 in Philadelphia,
    when [...] carpenters demanded a 72-hour week." -- Anatole Beck
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]