Brock <peabody@npcinternational.com> wrote:
: Oleg Zabluda wrote in message <6ek534$nso@r02n01.cac.psu.edu>...
: <
: >10. Less of a type safety: there is no guarantee that
: >    vector<T>::const_iterator is not implicitly convertible
: >    to vector<T>::iterator.

: I had a hard time believing this one.  Was this just an oversight?

I sure hope it wasn't an act of terrorism :-)


: >11. It seems like there is no comparison operator
: >    bool operator == (vector<T>::const_iterator, vector<T>::iterator)


: I dont think this is necessary, since vector<T>::iterator is implicitly
: convertable to vector<T>::const_iterator.

Try this one day:

template<class T> bool f(T,T) { return false; }

f(int(), char());

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

Jurgen K. Singer wrote:
>
> > In article <6e7oco$r7a@marianna.psu.edu>, Oleg Zabluda
> > <zabluda@math.psu.edu> writes
> > >Olivier Galibert <galibert@pobox.com> wrote:
> > >: Is there a way to portably get  an pointer on a C-like  array out of a
> > >: vector ?
> > >
> > >vector<int> v(....);
> > >int* array = new int[v.size()];
> > >copy(v.begin(), v.end(), array);
> >
>
> That is the reason why the vector template class is essentially unsuitable
> for
> numerical work. Not to mention the unfortunate name choice - the word
> vector has a very specific meaning in Mathematics, but this has not stopped

That's nothing new; C arrays have significantly different
characteristics from mathematical arrays. Of course, that bad name
choice is shared by several other computer languages, and luckily does
not cause namespace pollution in C.

> the Standard Committee so far, as can be seen from the wrong definitions of
> the norm method for complex numbers and the wrong implementation of
> inner_product for complex numbers.

norm() returns the squared magnitude?! Aaaagh! Any chance of getting
that fixed?

inner_product() is a little easier to justify. It's a little messy
defining an inner_product template that efficiently does the right
things with both complex and real numbers. However, inner_product has a
form which takes a binary_op2 argument; a suitably defined function
object can be used to handle complex numbers correctly.
---
[ 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              ]

James Kuyper wrote:

> norm() returns the squared magnitude?! Aaaagh! Any chance of getting
> that fixed?
>
> inner_product() is a little easier to justify. It's a little messy
> defining an inner_product template that efficiently does the right
> things with both complex and real numbers. However, inner_product has a
> form which takes a binary_op2 argument; a suitably defined function
> object can be used to handle complex numbers correctly.

I agree that one can easily fix inner_product by using its alternate form.
When I first realized the  trouble with norm and inner_product I wrote
a note to the standard  committee - unfortunately too late for consideration
in the current standard.

However, I still think that ideally inner_product for complex number
should do the right thing by default, namely

    inner_product = sum_i =1^n   conj(a_i) * b_i

and not

    inner_product = sum_i=1^n  a_i * b_i

The problem here is that it is difficult (impossible?) to provide a template
specialization for complex, since complex is itself templated. Hence,

     template<class FLOAT> inner_product< complex<FLOAT> >

will not work. The only alternative would be to provide specializations
for complex<float>, complex<double>, and complex<long double> (the
only three types for which complex is guaranteed to work). For other,
user defined types used with complex this would lead to unpleasant (or at
least unexpected) consequences.

I agree that the norm method of complex should clearly be fixed as
soon as possible.

My previous complaint about the name of vector was a side-remark. But I still
maintain that C++ currently does not provide a suitable dynamic array for use
in numerical applications - valarray is not supposed to be resized and vector
does not guarantee contiguous memory.
My first choice  would be to redefine the behavior of valarray to something
reasonable, or secondly, provide a new standardized class for dynamic arrays
for numerical applications.

-- Jurgen

------------------------------------------------------------------------------
jurgen@acm.org                                           Dr. Jurgen K. Singer
fax:   (617) 258-5846                                    M.I.T. 36-848
phone: (617) 253-2631                                    Cambridge, MA 02139
---
[ 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              ]

>>>>> =ABJurgen=BB, Jurgen K Singer <jurgen@acm.org> wrote:

Jurgen> I agree that one can easily fix inner_product by using its alternate
Jurgen> form.  When I first realized the  trouble with norm and inner_product
Jurgen> I wrote a note to the standard  committee - unfortunately too late
Jurgen> for consideration in the current standard.

Jurgen> However, I still think that ideally inner_product for complex number
Jurgen> should do the right thing by default, namely

Jurgen>     inner_product = sum_i =1^n   conj(a_i) * b_i

Jurgen> and not

Jurgen>     inner_product = sum_i=1^n  a_i * b_i


I Agree.


Jurgen> The problem here is that it is difficult (impossible?) to provide
Jurgen> a template specialization for complex, since complex is itself
Jurgen> templated. Hence,

Jurgen>      template<class FLOAT> inner_product< complex<FLOAT> >

Jurgen> will not work. The only alternative would be to provide
Jurgen> specializations for complex<float>, complex<double>, and
Jurgen> complex<long double> (the only three types for which complex is
Jurgen> guaranteed to work). For other, user defined types used with
Jurgen> complex this would lead to unpleasant (or at least unexpected)
Jurgen> consequences.


IMHO, one can use traits techniques to get this fixed.

Jurgen> I agree that the norm method of complex should clearly be fixed as
Jurgen> soon as possible.

In fact there is already a function which does what norm() means
(mathemacally) : it's named abs(). It is desireable (for efficientcy
purpose) to have a function which returns sqr(abs(z)) but norm() is
not the right name. Probably it should be renamed squared_norm().


Jurgen> My previous complaint about the name of vector was a side-remark.
Jurgen> But I still maintain that C++ currently does not provide a suitable
Jurgen> dynamic array for use in numerical applications - valarray is not
Jurgen> supposed to be resized and vector does not guarantee contiguous memory.
Jurgen> My first choice would be to redefine the behavior of valarray to
Jurgen> something reasonable, or secondly, provide a new standardized class
Jurgen> for dynamic arrays for numerical applications.

Joe Buck <jbuck@Synopsys.COM> wrote:
: Just the same, it would have been nice to have a class like vector<T>
: that *would* guarantee contiguous memory and that iterators are pointers.
: If such a class existed, we would never need to use C-style arrays in C++
: at all.  Since we must interface to C code and to physical memory (to
: write drivers, embedded software, and such), we still sometimes need
: that guarantee.

Yes, there is a serious need for such a class. Not so much for the
guarantee of the contiguous memory alone, but so that it has
_absolutely no_ disadvantages compared to build-in arrays.

The disadvantaged of the vector, compared to array are:

1. Inability to allocate on the stack or statically.

2. Inability to express that vectors of different sizes are
   different types.

3. Memory overhead for internal info. Arrays have zero memory
   overhead.

4. You never know how much memory it really occupies. Even if
   you explicitly ask it to reserve room for N elements, it is
   allowed to reserve for no less then N. On top of that,
   malloc()/new is allowed to do that as well.

5. CPU overhead.

6. The need to have a copy constructor for contained classes.
   Many interesting classes don't have one or have one with
   nontraditional semantics.

7. Vector can throw bad_alloc, arrays can't.

8. Far more complex. Some say unsuitable for interfaces because
   of this.

9. Inability to get a "pointer to array" from it. This one bothers me
   personally the least of all.

All this can be cured by having an another class, say

template<class T, size_t dim>
class array {
private:
  T data_[dim];
// ..
};

I think it should have been in the standard to begin with. It's not
a big deal to write one, but then all the users will have to learn
yet another class, and since everyone will write their own, we are
back to the bool-style problem in C.

Oleg.
---
[ 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 <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> writes:

> The Standard doesn't require that vector<> stores objects in
> contiguous adresses, as it does for valarray<>  .

I think John knew that already.  His question was Why?
/Why/ doesn't the standard require contiguous addresses.
---
[ 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              ]

Oleg Zabluda <zabluda@math.psu.edu> wrote:
: Joe Buck <jbuck@Synopsys.COM> wrote:
: : Just the same, it would have been nice to have a class like vector<T>
: : that *would* guarantee contiguous memory and that iterators are pointers.
: : If such a class existed, we would never need to use C-style arrays in C++
: : at all.  Since we must interface to C code and to physical memory (to
: : write drivers, embedded software, and such), we still sometimes need
: : that guarantee.

: Yes, there is a serious need for such a class. Not so much for the
: guarantee of the contiguous memory alone, but so that it has
: _absolutely no_ disadvantages compared to build-in arrays.

: The disadvantaged of the vector, compared to array are:

: [1-9]

Two more (inadvertent) things:

10. Less of a type safety: there is no guarantee that
    vector<T>::const_iterator is not implicitly convertible
    to vector<T>::iterator.

11. It seems like there is no comparison operator
    bool operator == (vector<T>::const_iterator, vector<T>::iterator)

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

>>>>> =ABMichael=BB, Michael R Cook <michael_cook%erawan@cognex.com> wrot=
e:

Michael> Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> write=
s:
>> The Standard doesn't require that vector<> stores objects in
>> contiguous adresses, as it does for valarray<>  .

Michael> I think John knew that already.  His question was Why?
Michael> /Why/ doesn't the standard require contiguous addresses.

 This question is slightly different from John's. John's
original question was:

John> That's my understanding too, unfortunately.  Does anyone know why t=
=3D
he
John> standard does not define that

John>    a-b =3D3D=3D3D (&*a) - (&*b)

John> for any two iterators a, b to the same vector<> object?

To answer you question, I'd suggest that there is already a class with
the requirement you ask for: it's named valarray.

-- Gaby
---
[ 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 <6ecnvi$e4k@hermes.synopsys.com>, Joe Buck
<jbuck@Synopsys.COM> writes
>John Aldridge <jpsa@jjdash.demon.co.uk> writes:
>>That's my understanding too, unfortunately.  Does anyone know why the
>>standard does not define that
>
>>   a-b == (&*a) - (&*b)
>
>>for any two iterators a, b to the same vector<> object?  Does anyone
>>know of an implementation where it's not true?
>
>The reason is that it is legal to implement a vector not as a single
>contiguous chunk, but as several separate segments (much in the same
>way that deque<T> is implemented in the HP and SGI implementations of
>STL).

Several other people said much the same thing.

Sorry, I should have been clearer.  I _know_ that the standard doesn't
guarantee that a vector<> be implemented as a single chunk.  I'm asking
_why_ it doesn't.

If I want a deque<>, I know where to find it.

--
Cheers,
John
---
[ 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              ]

Joe Buck <jbuck@Synopsys.COM> wrote:
: Just the same, it would have been nice to have a class like vector<T>
: that *would* guarantee contiguous memory and that iterators are pointers.
: If such a class existed, we would never need to use C-style arrays in C++
: at all.  Since we must interface to C code and to physical memory (to
: write drivers, embedded software, and such), we still sometimes need
: that guarantee.

Yes, there is a serious need for such a class. Not so much for the
guarantee of the contiguous memory alone, but so that it has
_absolutely no_ disadvantages compared to build-in arrays.

The disadvantaged of the vector, compared to array are:

1. Inability to allocate on the stack or statically.

2. Inability to express that vectors of different sizes are
   different types.

3. Memory overhead for internal info. Arrays have zero memory
   overhead.

4. You never know how much memory it really occupies. Even if
   you explicitly ask it to reserve room for N elements, it is
   allowed to reserve for no less then N. On top of that,
   malloc()/new is allowed to do that as well.

5. CPU overhead.

6. The need to have a copy constructor for contained classes.
   Many interesting classes don't have one or have one with
   nontraditional semantics.

7. Vector can throw bad_alloc, arrays can't.

8. Far more complex. Some say unsuitable for interfaces because
   of this.

9. Inability to get a "pointer to array" from it. This one bothers me
   personally the least of all.

All this can be cured by having an another class, say

template<class T, size_t dim>
class array {
private:
  T data_[dim];
// ..
};

I think it should have been in the standard to begin with. It's not
a big deal to write one, but then all the users will have to learn
yet another class, and since everyone will write their own, we are
back to the bool-style problem in C.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

Oleg Zabluda wrote in message <6ek534$nso@r02n01.cac.psu.edu>...
<
>10. Less of a type safety: there is no guarantee that
>    vector<T>::const_iterator is not implicitly convertible
>    to vector<T>::iterator.

I had a hard time believing this one.  Was this just an oversight?

>11. It seems like there is no comparison operator
>    bool operator == (vector<T>::const_iterator, vector<T>::iterator)


I dont think this is necessary, since vector<T>::iterator is implicitly
convertable to vector<T>::const_iterator.

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

Olivier Galibert <galibert@pobox.com> wrote:
: Is there a way to portably get  an pointer on a C-like  array out of a
: vector ?

vector<int> v(....);
int* array = new int[v.size()];
copy(v.begin(), v.end(), array);

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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 <6e7oco$r7a@marianna.psu.edu>, Oleg Zabluda
<zabluda@math.psu.edu> writes
>Olivier Galibert <galibert@pobox.com> wrote:
>: Is there a way to portably get  an pointer on a C-like  array out of a
>: vector ?
>
>vector<int> v(....);
>int* array = new int[v.size()];
>copy(v.begin(), v.end(), array);

That's my understanding too, unfortunately.  Does anyone know why the
standard does not define that

   a-b == (&*a) - (&*b)

for any two iterators a, b to the same vector<> object?  Does anyone
know of an implementation where it's not true?
--
Cheers,
John
---
[ 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 <6e7oco$r7a@marianna.psu.edu>, Oleg Zabluda
> <zabluda@math.psu.edu> writes
> >Olivier Galibert <galibert@pobox.com> wrote:
> >: Is there a way to portably get  an pointer on a C-like  array out of a
> >: vector ?
> >
> >vector<int> v(....);
> >int* array = new int[v.size()];
> >copy(v.begin(), v.end(), array);
>

That is the reason why the vector template class is essentially unsuitable
for
numerical work. Not to mention the unfortunate name choice - the word
vector has a very specific meaning in Mathematics, but this has not stopped
the Standard Committee so far, as can be seen from the wrong definitions of
the norm method for complex numbers and the wrong implementation of
inner_product for complex numbers.
The best choice I can see for serious numerical work is to forego vector as
well
as valarray and implement one's own dynamic array class.

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

John Aldridge <jpsa@jjdash.demon.co.uk> wrote:
: In article <6e7oco$r7a@marianna.psu.edu>, Oleg Zabluda
: <zabluda@math.psu.edu> writes
: >Olivier Galibert <galibert@pobox.com> wrote:
: >: Is there a way to portably get  an pointer on a C-like  array out of a
: >: vector ?
: >
: >vector<int> v(....);
: >int* array = new int[v.size()];
: >copy(v.begin(), v.end(), array);

: That's my understanding too, unfortunately.  Does anyone know why the
: standard does not define that

:    a-b == (&*a) - (&*b)

: for any two iterators a, b to the same vector<> object?


Because the standard does not mandate that vector's elements be
located in a contiguous physical memory. There are many ways to
arrange the elements and still meet the complexity requirements.

In fact, for an appropriate allocator, they might be located on
the hard drive, and your right-hand side will not compile.


Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

John Aldridge writes:

> Does anyone know why the standard does not define that

>    a-b == (&*a) - (&*b)

> for any two iterators a, b to the same vector<> object?

AFAIK, an implementation of vector is not required to allocate a
single region of memory for contained objects.  It is not even
required to use arrays of objects at all.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil
---
[ 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              ]

Olivier Galibert <galibert@pobox.com> wrote:
>: Is there a way to portably get  an pointer on a C-like  array out of a
>: vector ?

Oleg Zabluda <zabluda@math.psu.edu> writes
>vector<int> v(....);
>int* array = new int[v.size()];
>copy(v.begin(), v.end(), array);

John Aldridge <jpsa@jjdash.demon.co.uk> writes:
>That's my understanding too, unfortunately.  Does anyone know why the
>standard does not define that

>   a-b == (&*a) - (&*b)

>for any two iterators a, b to the same vector<> object?  Does anyone
>know of an implementation where it's not true?

The reason is that it is legal to implement a vector not as a single
contiguous chunk, but as several separate segments (much in the same
way that deque<T> is implemented in the HP and SGI implementations of
STL).  Iterators would then have a segment and an offset (shades of Win16).
That may well be more efficient if vectors grow to very large
sizes, as it can reduce the amount of reallocation that must happen
when, say, a vector with 100k values is grown by another 50k.  Iterators
would then need to handle segment boundaries, but this can be done in
a way that they still meet the requirements for random access iterators.
It's pretty much the same as the code for far pointer arithmetic in Win16.

Just the same, it would have been nice to have a class like vector<T>
that *would* guarantee contiguous memory and that iterators are pointers.
If such a class existed, we would never need to use C-style arrays in C++
at all.  Since we must interface to C code and to physical memory (to
write drivers, embedded software, and such), we still sometimes need
that guarantee.





--
-- Joe Buck
See my daughter: http://www.byoc.com/homepage/130481/molly.html
Boring semi-official web page:
                 http://www.synopsys.com/news/pubs/research/people/jbuck.html
---
[ 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              ]

>>>>> =ABJohn=BB, John Aldridge <jpsa@jjdash.demon.co.uk> wrote:

John> That's my understanding too, unfortunately.  Does anyone know why t=
he
John> standard does not define that

John>    a-b =3D=3D (&*a) - (&*b)

John> for any two iterators a, b to the same vector<> object?

The Standard doesn't require that vector<> stores objects in
contiguous adresses, as it does for valarray<>  .

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

Is there a way to portably get  an pointer on a C-like  array out of a
vector ?  Or is basic_string  the only way  (through c_str()). This is
needed when  one want to  interface STL containers with low-level libc
calls like read or write.

If  it is impossible,  then the  argument against auto_ptr_array which
says "use vector" probably doesn't hold.

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