is using tons of stl a correct method?

R

rokia

in a project, I use many,many stl such as stack,list,vctor etc.

somewhere the vector's size is more than 2K. is this a efficient way?
 
P

Phlip

rokia said:
in a project, I use many,many stl such as stack,list,vctor etc.

somewhere the vector's size is more than 2K. is this a efficient way?

Using robust Standard Library gizmos is infinitely more efficient, in terms
of programming time, than using raw arrays, linked lists, 'new', etc. If you
use those, you will endlessly reinvent low-level details that Standard
Library things, and risk bugs as you reinvent. Using STL containers makes
C++ as cognitively efficient as a "high-level" language.
 
D

Dave Townsend

Yes, I concur. I've recently been able to use STL exclusively rather
than C-arrays and home-brewed d/s, I've had very few crashes and
clean up is a breeze - its done for me! Thank you Alex Stepanov, you da
man!!
 
R

rokia

thanks for your reply.

another question:

when you have a class A. will you push_back A to a list? or just the
pointer of A?

I mean which is the right one below:

1: class A;
list<A> la;
A a,b,c;
la.push_back(a); la.push_back(b),la.push_back(c);

2:class A;
list<A*> la;
A *pa;
A *pb;
A *pc;
la.push_back(pa);la.push_back(pb);la.push_back(pc);

and which method should I use If THERE ARE 5000 class A OR MORE?

thanks.:)
 
D

Dave Townsend

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>
 
P

Phlip

[top-post fixed - please take pride in your posts and clean each one]

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.

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.
 
P

Phlip

rokia said:
another question:

when you have a class A. will you push_back A to a list? or just the
pointer of A?

If A can have derived classes, push a shared pointer (such as the smart
pointers at www.boost.org).

If A can't have derived classes, push it in by copy.
 
P

Phlip

rokia said:
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.. ;)
 
J

John Harrison

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
 
R

rokia

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*> ??
 
R

rokia

Thanks A lot! :)



Phlip said:
[top-post fixed - please take pride in your posts and clean each one]

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.

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.
 
K

Kelsey Bjarnason

[snips]

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.
 
P

Phlip

Kelsey said:
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.
 
J

J. Campbell

Phlip said:
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 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.

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.
 
J

John Harrison

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
 
J

Joe C

John Harrison said:
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
 
P

Peter van Merkerk

Joe said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top