«

rokia wrote:

> and what does 'home-brewed d/s' mean ?

Data structures.

(Give Dave a break - typing the extra several letters would have doubtless
pushed him over his edge..

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

On Mon, 26 Jul 2004 13:19:42 +0800, rokia <>
wrote:

> yeah, I know this.
>
> I want to know which way is the better one?
>

Well of course it depends on what you want to do.

But certainly I would avoid pointers most of the time. And even when I
wanted pointers I would usually use smart pointers not raw pointers.

john

sorry for my poor english.

I didn't got what you do mean.

can you give me a simple answer?

Yes or NO?
Should I use list<A> or List<A*> ??

Thanks A lot!



"Phlip" <> дÈëÓʼþ
news:6N0Nc.18$...
> [top-post fixed - please take pride in your posts and clean each one]
>
> Dave Townsend wrote:
>
> > > STL containers work by making copies of objects, so push_back(a)
> > > makes a copy of a in the container. When you access a, say by
> > > vector at(), it gives you a copy of the object. Make sure that
> > > you have the appropriate constructors implemented however, otherwise
> > > you'll end up with garbage...
> > >
> > > You can also store pointers in the STL container, but you have
> > > to declare the container as a container of pointers, ie, list<A*>
rather
> > > than list<A>
>
> rokia wrote:
>
> > yeah, I know this.
> >
> > I want to know which way is the better one?
>
> Premature optimization is the root of all evil. STL wouldn't exist if it
> weren't as fast as the alternative (raw arrays for std::vector, raw linked
> lists for std::list, etc.).
>
> What you gain by using STL is clean interfaces that are very easy to use
> right and frequently hard to use wrong. That frees your time up to
> concentrate on program logic.
>
> The most important resource to optimize is programmer time. If you write
> clean code (and unit tests on each feature), you will have time to then
> profile your code and see if it really is slow. The odds are very good
that
> your code will perform acceptably with obvious implementations.
>
> > > > and which method should I use If THERE ARE 5000 class A OR MORE?
>
> The only only only way to tell is put 5,000 class A objects in and see.
> Different STLs have different performance profiles, but many other aspects
> of your code, even the vaguarities of your CPU cache and pipelining, can
> affect performance.
>
> --
> Phlip
> http://industrialxp.org/community/bi...UserInterfaces
>
>

[snips]

On Mon, 26 Jul 2004 05:38:10 +0000, Phlip wrote:

> Premature optimization is the root of all evil. STL wouldn't exist if it
> weren't as fast as the alternative (raw arrays for std::vector,

Simple local testing reveals that inserting objects into a vector via
push_back is approximately 8 times slower than simply storing them into an
array and a simple loop and increment ( for i = 0 to nelems; inc elem )
runs a good three times slower with vectors.

Speed isn't the key to the STL. The fact that it provides reasonable
speed, plus a very rich set of operations and relieves the coder from
managing all the gory details seems a little more significant.

Kelsey Bjarnason wrote:

> Phlip wrote:
>
> > Premature optimization is the root of all evil. STL wouldn't exist if it
> > weren't as fast as the alternative (raw arrays for std::vector,
>
> Simple local testing reveals that inserting objects into a vector via
> push_back is approximately 8 times slower than simply storing them into an
> array and a simple loop and increment ( for i = 0 to nelems; inc elem )
> runs a good three times slower with vectors.

Set the capacity first. That's cognitively the same thing you do with a
fixed-size array. You compared a vector to calling new over and over again.

> Speed isn't the key to the STL. The fact that it provides reasonable
> speed, plus a very rich set of operations and relieves the coder from
> managing all the gory details seems a little more significant.

Speed is the key. Vendors may implement containers however they see fit, but
each container type has a performance profile guaranteed to match an
equivalent "manual" data structure. vector iterates as quickly as an array,
and accesses randomly as quickly as an array. list can delete a middle
element as quickly as a linked list can pull out an inner node. Etc.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

"Phlip" <> wrote in message news:<Bs5Nc.2639$ m>...
> Kelsey Bjarnason wrote:
>
> > Phlip wrote:
> >
> > > Premature optimization is the root of all evil. STL wouldn't exist if it
> > > weren't as fast as the alternative (raw arrays for std::vector,
> >
> > Simple local testing reveals that inserting objects into a vector via
> > push_back is approximately 8 times slower than simply storing them into an
> > array and a simple loop and increment ( for i = 0 to nelems; inc elem )
> > runs a good three times slower with vectors.
>
> Set the capacity first. That's cognitively the same thing you do with a
> fixed-size array. You compared a vector to calling new over and over again.
>
> > Speed isn't the key to the STL. The fact that it provides reasonable
> > speed, plus a very rich set of operations and relieves the coder from
> > managing all the gory details seems a little more significant.
>
> Speed is the key. Vendors may implement containers however they see fit, but
> each container type has a performance profile guaranteed to match an
> equivalent "manual" data structure. vector iterates as quickly as an array,
> and accesses randomly as quickly as an array. list can delete a middle
> element as quickly as a linked list can pull out an inner node. Etc.
>
> --
> Phlip

Hi guys. I read this thread with interest. I program as a hobby and
migrated to C++ from BASIC about 2 yrs ago and have been wondering
about using STL. I find myself using arrays rather than vectors even
when I need to put the data on the heap, although I don't advocate
others do the same...for me it just seems simpler. As an example of
where I do this, I have a data-holding class that over-writes the
memory (for security reasons, using memset()) in the destructor before
releasing the memory. When I was designing the class, I couldn't
think of an easy way to get a vector to do the same. Does this
particular requirement (that no data remains in ram once it is
released) necessitate the use of arrays, or can the same be achieved
using vectors?

The data size is unknown at compile time, so the class goes through
the rigmarole of newing and deleting itself upon initiation, copy, and
destruction.

Thanks for this helpful thread.

> As an example of
> where I do this, I have a data-holding class that over-writes the
> memory (for security reasons, using memset()) in the destructor before
> releasing the memory. When I was designing the class, I couldn't
> think of an easy way to get a vector to do the same. Does this
> particular requirement (that no data remains in ram once it is
> released) necessitate the use of arrays, or can the same be achieved
> using vectors?

Assuming your vector is called vec

memset(&vec[0], 0, vec.size()*sizeof vec[0]);

The trick is that &vec[0] can be used to get the address of the first vector
element (and also that the C++ standard guarantees that a vector elements
occupy contiguous memory).

john

"John Harrison" <> wrote in message
news:...
>
> > As an example of
> > where I do this, I have a data-holding class that over-writes the
> > memory (for security reasons, using memset()) in the destructor before
> > releasing the memory. When I was designing the class, I couldn't
> > think of an easy way to get a vector to do the same. Does this
> > particular requirement (that no data remains in ram once it is
> > released) necessitate the use of arrays, or can the same be achieved
> > using vectors?
>
> Assuming your vector is called vec
>
> memset(&vec[0], 0, vec.size()*sizeof vec[0]);
>
> The trick is that &vec[0] can be used to get the address of the first
vector
> element (and also that the C++ standard guarantees that a vector elements
> occupy contiguous memory).
>
> john
>
>

Thanks John. What about if the vector reallocates itself (ie the data is
concatinable)? Is there a way to make certain that the pre-reallocated
vector is over-written?

Thanks for the reply.

Joe

Joe C wrote:

> "John Harrison" <> wrote in message
> news:...
>
>>> As an example of
>>>where I do this, I have a data-holding class that over-writes the
>>>memory (for security reasons, using memset()) in the destructor before
>>>releasing the memory. When I was designing the class, I couldn't
>>>think of an easy way to get a vector to do the same. Does this
>>>particular requirement (that no data remains in ram once it is
>>>released) necessitate the use of arrays, or can the same be achieved
>>>using vectors?
>>
>>Assuming your vector is called vec
>>
>>memset(&vec[0], 0, vec.size()*sizeof vec[0]);
>>
>>The trick is that &vec[0] can be used to get the address of the first
>
> vector
>
>>element (and also that the C++ standard guarantees that a vector elements
>>occupy contiguous memory).
>
> Thanks John. What about if the vector reallocates itself (ie the data is
> concatinable)? Is there a way to make certain that the pre-reallocated
> vector is over-written?

You could use std::vector::reserve() to prevent reallocations. Or you
could use a different allocator with the vector; one that clears memory
before deallocating it. Such an allocator could also be used with other
container classes.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl