Joe Buck <jbuck@best.com> wrote:
: Oleg Zabluda  <zabluda@math.psu.edu> wrote:
: >Two more (inadvertent) things:

: (re vector<T>)

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

: There is no direct guarantee, but the standard doesn't specify all the
: conversions that *don't* exist.

But it does gurantee that there is no conversion from
``T*'' to ``const T*''. Althought the standard does not
specify _all_ the conversions that don't exist, there are
some important conversions that warrant explicit prohibition.
I think this is the one which warrants an explicit prohibition,
because of the way and frequency container<T>::iterator is
typically used. I have experimantal data supporting this.
See later.

: In practice, this is only an issue for
: language lawyers, in that I cannot imagine that any implementor would
: provide such a conversion.

Thank God, I don't know any vendors which do it for the vector.
However, Microsoft + Plauger ship the library which allows
such conversion for map/set and their multi counterparts.
Check it out, it's still there. In fact, they allow
free implicit cross-casts between map<T>::iterator and
set<U>::iterator. You can add const as desired.

: Given this, there is no type safety issue
: here.  (I suspect that this hypothetical conversion is indirectly
forbidden).

As you see, the actual real-life standard-compliant horrors
go beyound the wildest imaginable nightmares.

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

: Yes there is.  Rather, for all iterators on standard containers, there
: must be a conversion from iterator to const_iterator.  This guarantees
: that you can compare a const_iterator to an iterator for any
container.
: (Some older compilers may give you trouble, but we're talking about
the
: standard here).

CD2 is pretty vague on which iterators == is defined, that's why I
said ``seems''. However, assuming, that it does not directly
require

``convertible to bool''
operator == (vector<T>::const_iterator, vector<T>::iterator) // (1)

and only requires

``convertible to bool''
operator == (vector<T>::iterator, vector<T>::iterator) // (2)

and

``convertible to bool''
operator == (vector<T>::const_iterator, vector<T>::const_iterator) //(3)

It does not follow that (1) exists only because there is a conversion
from vector<T>::iterator to vector<T>::const_iterator. [1]
If operator == is a template function, such a conversion
will not be considered for template parameter deduction.

Althought chances of operator == to be a template function
are not that great, chances of operator != to be a template
function are much greater.

template<class T> bool operator != (T a, T b) { return !(a==b); }

So, until this is clarified for me, I consider the following
code to be non-portable:

vector<int> v(10);
for(vector<int>::const_iterator i = v.begin(); i != v.end(); ++i);

:-(

[1] BTW, I don't see such a conversion in CD2. I was complaining
about it some time ago, and was told that the requirement for
such a conversion will be put into FDIS. Could someone quote
FDIS on that?

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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              ]

Tim Ottinger <ottinger@oma.com> wrote:

: Oleg Zabluda wrote:

: > Valentin Bonnard <bonnardv@pratique.fr> wrote:

: > : For contiguous storage, you have valarray. But it's a strange
: > : animal, not designed to replace built-in arrays.


: > Obviously, neither was vector<>. Or at least it doesn't do a very
: > good job at it.

: Such a statement requires a "because". Why do you feel that the vector
: is a poor replacement?

Sorry. Me and others were bitching about this for some time, and
I arrogantly assumed that it's a common knowledge by now.

Here is a summary of what I've already written on the subject:

Vector is superior to the build-in array in mahy respects.
I won't be posting a list, since it's slightly off-topic.
However, the build-in array is superior to vector in
many respects too. See the list below. Therefore, we can not
say that a vector does very good job at replacing build-in
arrays.

On the other hand, the build-in array is hopelessly broken,
and fits poorly into C++ programs, except on the very, very
low level. See below for the list of why.

Therefore there is a need for a really good replacement for
a build-in array. Really good means that there is no disadvantages
compared to a build-in array whatsoever. It's not hard to
write such a class yourself, but I'd much prefer a standard
one, even if it were inferior for my purposes then the one
I can make myself.

The big reason is that a home-grown class must be known to those
reading your code, and this creates a huge barrier to using it. When
choosing between an inferior vector<T>, and superior array<T, n>,
I must justify putting an additional burden on the reader. It's very
rarely that I can justify it. Another problem is that everybody writes
their own array<T, n>-like classes, and it's just as bad as all
those home-grown ``bool'' classes for C89.

On the other hand, by using vector<>, when, in fact, I mean
array<T, n>, I nevertheless put an additional burden on the
reader. because I say not what I want, and an additional
information is lost.

I don't see a satisfactory solution to all this, so I was
bitching and bitching and bitching here for a while.

-=-=-=---=

>From:         Oleg Zabluda <zabluda@math.psu.edu>
>Date:         1998/03/17
>Message-ID:   <6eh5le$9dk@marianna.psu.edu>

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.


>From:         Oleg Zabluda <zabluda@math.psu.edu>
>Date:         1998/03/17
>Message-ID:   <6ek534$nso@r02n01.cac.psu.edu>

[...]

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)


-=-=-=-=-=

From: Oleg Zabluda <zabluda@math.psu.edu>
Message-ID: <6iv44o$bv7@netlab.cs.rpi.edu>,
Date: 09 May 98 08:52:18 GMT
Newsgroups: comp.lang.c++.moderated,comp.std.c++

Advantages of a hypothetical array<T, n> class compared to
a build-in array:

1. Ability to pass by value.
2. Absense of implicit DCD -- Deadly Conversion of Death (to pointer).
3. Proper interaction with inheritance.
4. No need to remember to use delete[] instead of delete. No need
   to introduce auto_array<>
5. Ability to supply useful constructors (iterator range, default value).
6. Ability to initialize in the contructor initializer lists.
7. Copy constructor, copy assignement.
8. Readable begin(), end() methods.
9. as well as other vector-like parts of the interface.
10. Less shocking syntax. No f(int(&)[10]).
11. Ability to modify the implementation within the constraints
    of the interface.
12. No need to know if a particular type is a typedef for
    an array or not. See 1, 2, 3, 4, 7.

-=-=-=

Hope this is a good enough `because'' :-)

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ 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:
>Two more (inadvertent) things:

(re vector<T>)

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

There is no direct guarantee, but the standard doesn't specify all the
conversions that *don't* exist.  In practice, this is only an issue for
language lawyers, in that I cannot imagine that any implementor would
provide such a conversion.  Given this, there is no type safety issue
here.  (I suspect that this hypothetical conversion is indirectly forbidden).


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

Yes there is.  Rather, for all iterators on standard containers, there
must be a conversion from iterator to const_iterator.  This guarantees
that you can compare a const_iterator to an iterator for any container.
(Some older compilers may give you trouble, but we're talking about the
standard here).

--
-- Joe Buck
   work: jbuck@synopsys.com, otherwise jbuck@welsh-buck.org or jbuck@best.net
http://www.welsh-buck.org/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


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