blargg wrote:
>
> In article <37A5D56D.1310@wanadoo.fr>, Valentin Bonnard
> <Bonnard.V@wanadoo.fr> wrote:

> > The point here is that contiguous vector gives real benefits
> > while vector with unspecified contiguity gives hypothetical
> > benefits.
>
> So constant-time insertion at the beginning and end is hypothetical?

Of course having constant-time insertion at the beginning
IS hypothetical. For example, using SGI STL, I don't have
it.

--

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

Alain Miniussi wrote:

> Valentin Bonnard wrote:

> > Alain Miniussi wrote:

> > I wouldn't go as far as standardizing if vector<T>::iterator
> > is a T* or not.
>
> Why ? It's not such a bad implementation. And every one implement
> it that way.

Of course I reject the second part of the argument. And the first
part too.

> > > > I am in favor of contiguous vectors, not because it's the
> > > > obvious implementation and everyone do it this way, but
> > > > because it's useful in some cases.
> > >
> > > This justify addition some kind of c_buffer, those
> > > implementation would probably be similar to the one used by
> > > vector, and that could be used in these cases, without
> > > (possibly) interfering in the cases where vector was not
> > > used with continuity in mind.
> >
> > rsh alain rm vector # forget about the general purpose vector
> > rsh alain mv c_buffer vector
>
> No, I still want a general purpose vector, free from the C
> constraint :-)

rsh alain mv std::vector alain::vector

Why impose your preferences to all users know need
to interact with C code ?

Seriously, one shouldn't restrict the usefulness of
std::vector just for some hypothetical implementations:
with vector leaving unspecified the contiguity of
elements, users who want portability get the worst
of both worlds: they can't rely on contiguity, nor
can they rely on fast reallocations, non invalidating
reallocations, fast insertion near the beginning,
large max_size on segmented architectures.

--

Valentin Bonnard


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

Valentin Bonnard wrote:
>
> Alain Miniussi wrote:
>
> > I think that over specification + encapsulation disrespect
> > (that is, over specification of the implementation) is the
> > best way to have a standard that become useless in a few
> > years (but since this is a general opinion, with nothing
> > specific to a standard, that's not the important point)
>
> Somebody> Let's make vectors contiguous ?
>
> Alain> Why ?
>
> Somebody> Because of existing C code
>
> Alain> This kind of things will be useless in a few years

I did not say that. "useless in a few year" was not refering
the "kind of thing" you are mentionning (but to a kind of behavior
that could lead to something useless, well, the text is still
here).

> There are two possible reasons for C/C++ interraction
> to become useless:
>
> - C will have disappeared in a few years   :-)
> - C++ will have disappeared in a few years :-(
>
> > So it would be simplier and it would save a lot of argument
> > to provide the implementation or to put some library provider
> > source code in the standard.
> I wouldn't go as far as standardizing if vector<T>::iterator
> is a T* or not.

Why ? It's not such a bad implementation. And every one implement
it that way.

> > > I am in favor of contiguous vectors, not because it's the
> > > obvious implementation and everyone do it this way, but
> > > because it's useful in some cases.
> >
> > This justify addition some kind of c_buffer, those
> > implementation would probably be similar to the one used by
> > vector, and that could be used in these cases, without
> > (possibly) interfering in the cases where vector was not
> > used with continuity in mind.
>
> rsh alain rm vector # forget about the general purpose vector
> rsh alain mv c_buffer vector

No, I still want a general purpose vector, free from the C
constraint :-)

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              ]

Valentin Bonnard wrote:
>
> Alain Miniussi wrote:
>
> > I don't accept that argument. It implies that if, at some point (ie
> > today), an implementation is considered "good enough", you can throw
> > away the notion of encapsulation, and not just for today. I think
> > encapsulation should be more respected than that.
>
> I don't think that encapsulation deserves respect.

Well, I do (well, in the same way a hamer deserves respect in some
situation, I am not planning to build a religion on top of that).
I am just saying that the "private" has a set of legitimate uses.

> I think that the STL as a whole is over-specified and
> that's a Good Thing.

I think that over specification + encapsulation disrespect
(that is, over specification of the implementation) is the
best way to have a standard that become useless in a few
years (but since this is a general opinion, with nothing
specific to a standard, that's not the important point)

> As for freezing implementation:
>
> - stating that ``all current implementation do it this way''
>   is _not_ a sufficient reason
>
> - other possible implementations should be considered (for
>   their benefits and their costs)
>
> - likely uses should be considered
>
> - ``we intended it this way'' arguments are hard to accept
>   for people who didn't understoud/intended it this was
>
> - standardizing an implementation because it's the most
>   obvious one is completely wrong

These are basicaly the arguments I did used (just checking)

> > I am
> > not sure that the purpose of a standard is to decide the best
> > implementation for a general purpose template.
> I am sure that it should be its purpose.

So it would be simplier and it would save a lot of argument
to provide the implementation or to put some library provider
source code in the standard.

> I am in favor of contiguous vectors, not because it's the
> obvious implementation and everyone do it this way, but
> because it's useful in some cases.

This justify addition some kind of c_buffer, those
implementation would probably be similar to the one used by
vector, and that could be used in these cases, without
(possibly) interfering in the cases where vector was not
used with continuity in mind.

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              ]

Alain Miniussi wrote:

> I think that over specification + encapsulation disrespect
> (that is, over specification of the implementation) is the
> best way to have a standard that become useless in a few
> years (but since this is a general opinion, with nothing
> specific to a standard, that's not the important point)

Somebody> Let's make vectors contiguous ?

Alain> Why ?

Somebody> Because of existing C code

Alain> This kind of things will be useless in a few years

There are two possible reasons for C/C++ interraction
to become useless:

- C will have disappeared in a few years   :-)
- C++ will have disappeared in a few years :-(

> So it would be simplier and it would save a lot of argument
> to provide the implementation or to put some library provider
> source code in the standard.

I wouldn't go as far as standardizing if vector<T>::iterator
is a T* or not.

> > I am in favor of contiguous vectors, not because it's the
> > obvious implementation and everyone do it this way, but
> > because it's useful in some cases.
>
> This justify addition some kind of c_buffer, those
> implementation would probably be similar to the one used by
> vector, and that could be used in these cases, without
> (possibly) interfering in the cases where vector was not
> used with continuity in mind.

rsh alain rm vector # forget about the general purpose vector
rsh alain mv c_buffer vector

--

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

Alain Miniussi wrote:

> I don't accept that argument. It implies that if, at some point (ie
> today), an implementation is considered "good enough", you can throw
> away the notion of encapsulation, and not just for today. I think
> encapsulation should be more respected than that.

I don't think that encapsulation deserves respect.

I think that the STL as a whole is over-specified and
that's a Good Thing.

As for freezing implementation:

- stating that ``all current implementation do it this way''
  is _not_ a sufficient reason

- other possible implementations should be considered (for
  their benefits and their costs)

- likely uses should be considered

- ``we intended it this way'' arguments are hard to accept
  for people who didn't understoud/intended it this was

- standardizing an implementation because it's the most
  obvious one is completely wrong

> I am
> not sure that the purpose of a standard is to decide the best
> implementation for a general purpose template.

I am sure that it should be its purpose.

I am in favor of contiguous vectors, not because it's the
obvious implementation and everyone do it this way, but
because it's useful in some cases.

--

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