Boost logo

Boost :

From: Craig Hicks (hicks_at_[hidden])
Date: 2001-02-19 12:16:17


Bernard wrote::
////////////////////////
  void reserve(size_t)
  [4] Reserve() causes a reallocation manually. The main reason for
  using reserve() is efficiency: if you know the capacity to which your
  vector must eventually grow, then it is
  usually more efficient to allocate that memory all at once rather than
  relying on the automatic reallocation scheme. The other reason for
  using reserve() is so that you can control
  the invalidation of iterators. [5]

  then push_back() should be cheap...

  Cheers,
  Bernard
////////////////////////

Hicks:
But push_back() causes a size check, so that is not a good option.
And yes, use of reserve() when the maximum vector size is known is a good
idea in general.

Dave wrote::
////////////////////////
  Bernard,

  I think you missed the OP's point. Each push_back causes a check to make
  sure the capacity() is at least enought to hold the new element.
  However, you can eliminate most of this cost by using
    v.insert(v.end(), first, last);
  where first and last are random access iterators.

  -Dave
////////////////////////

Hicks:
Am I incorrect in saying that
    v.insert(v.end(), first, last)
will incurr last-first copy operations? And thus be no cheaper than
initialization,
in addition to requiring the setup of data to be inserted. (Perhaps you
meant
    void insert(iterator position, size_type n, const T& x))

Christopher wrote a lot.

> You need to be more specific in your question. What is it you want to do?
Which
> operations do you need and which ones need to be efficient as possible?
Perhaps
> an std::vector is not the right data structure or container at all.

A std::vector i/f is right, I just don't want

std::vector<int> vi(onemega)

or
struct Foo { int foo; };

std::vector<Foo> vi(onemega)

to do any initialization. (As I originally stated as simply as possible.)

> or whatever operation the underlying vector memory is exhausted)? No class
> or structure has "no constructors", as you say, some just happen to have
only
> a standard default constructor (plus a copy constructor), but these might
be

No code initialization code execution takes place with
    new int[onemega]
or
    new Foo[onemega]

on my compilerer. So Foo and int have default constructors with zero
computation,
and this is what I meant by no constructors.

> ctor, copy ctor, or dtor) and if your compiler loves you, no code for
> initializing std::vector elements is generated, hence no overhead. What do
you

The problem is discerned with my debugger was that uninitialized_fill was
being called,
so that "onemega" copies were performed in a loop. The default (null)
constructor was called
only once for the master copy.

> mean by "Using push_back() would could a size check on each access"? There
is
> no std::vector bounds check, but reallocation of the underlying memory
might be
> triggered. Is it this that you mean?

By no means. I mean a size check, with an if statement, is performed

> Perhaps you could show us some code of yours to illustrate what you want
to do.

{
...
std::vector<Foo> vi(onemega) ; // no initialization loop desired
...

code containing setting and getting of vi
    vi[..] = ...
   ... = vi[...]

} // end of scope, no loop of explicit desctructor calls desired

> As I am relatively new to this list, I am not sure how relevant to the
boost
> libraries this request is at all, so you might want to contact me by
private
> e-mail.

Since this topic concerns a necessary feature of a template vector
I think it might be relevant, but I do not want to be guilty of creating
noise :).
The issue is certainly not resolved yet.

Cheer

Hicks

----- Original Message -----
From: Christoph Koegl <yahoo_at_[hidden]>
To: <boost_at_[hidden]>
Cc: <koegl_at_[hidden]>
Sent: Tuesday, February 20, 2001 12:50 AM
Subject: Re: [boost] no-fill vector initialization

> Hi Craig.
>
> You need to be more specific in your question. What is it you want to do?
Which
> operations do you need and which ones need to be efficient as possible?
Perhaps
> an std::vector is not the right data structure or container at all.
> What do you mean by "std::vector always initialized all the elements on
> resize()"? All the new elements? All elements in the vector? All elements
in
> the vector or reallocation (which happens if during an insert or an
push_back
> or whatever operation the underlying vector memory is exhausted)? No class
> or structure has "no constructors", as you say, some just happen to have
only
> a standard default constructor (plus a copy constructor), but these might
be
> protected/private; for use in an std::vector the element type must be
default
> constructible and assignable (hence must have a public default ctor and a
public
> copy ctor). If the default ctor is the standard one (which a class/struct
has
> if there is none specified in the class/struct definition) and if some
type
> traits class is used (as is internally in SGI's STL or in STLport for
speciali-
> zations of some templated functions that benefit from trivial-ness of
default
> ctor, copy ctor, or dtor) and if your compiler loves you, no code for
> initializing std::vector elements is generated, hence no overhead. What do
you
> mean by "Using push_back() would could a size check on each access"? There
is
> no std::vector bounds check, but reallocation of the underlying memory
might be
> triggered. Is it this that you mean? What is it you mean to say when you
ask
> "if perhaps there is an easy (no more than say 1 line of code) to make
> std::vector do the same thing"? Which "same thing"?
> Perhaps you could show us some code of yours to illustrate what you want
to do.
> As I am relatively new to this list, I am not sure how relevant to the
boost
> libraries this request is at all, so you might want to contact me by
private
> e-mail.
>
> Cheers, Christoph
> --
>
============================================================================
====
> Christoph Koegl, Dept. of Computer Science, University of Kaiserslautern
>
> E-Mail: christoph_at_[hidden] WWW:
http://www.familie-koegl.de/
> --------------------------------------------------------------------------
------
> There are no stupid questions, but there are a LOT of inquisitive idiots.
> --------------------------------------------------------------------------
------
>
>
>
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk