When is std::list more effective than the other containers?

[Josh Mcfarlane]

Just out of curiosity:

When would using std::list be more efficient / effective than using
other containers such as vector, deque, etc?

As far as I'm aware, list doesn't appear to be specialized for
anything.

Thanks,
Josh McFarlane

[Axter]

ro**********@gm ail.com wrote:

Axter wrote:

roberts.n...@gm ail.com wrote:

I don't agree. Every container serves a particular purpose. It could
be that in YOUR case most development domains seem to be least served
by the list container there are certainly a lot of cases when a list is
a very appropriate choice. The best thing is to understand the
implementations of the different containers and where those kind of
algorithms are best used. Take a class or read a book on data
structures and implement your own list, vector, map, etc...and then you
will be able to understand their value and when to use what.

As a contractor, I've worked in many locations, and it's been my
experience when finding std::list used in code, that 9 out of 10 times,
std::list is being used inappropriately , and std::vector or std::deque
would have done the same job faster.

I'm sorry but I just don't buy your "credential s". Anyone that would
call that dynamic_array class of yours an example of how TO do
something doesn't meet my requirements of an expert. Judging by the
single code example I have seen from you I am not at all impressed.

Don't take my credentials. As I've previously recommended to you, you
should read more advance books like that of Sutters and Meyers.
These two authors have very well known established credentials.
It's a mistake to base your opinions just on online information,
because anyone can write an FAQ or a web site, and claim authority on
the subject.
It's also a mistake to base your opinions on out dated beginner's C++
books.
If you're going to advocate a position that contradicts others, you
should at least make the effort to be well informed by more respectable
sources.
Otherwise garbage in, garbage out.
You read garbage, and you're going to end up reiterating the same
garbage, which is what I've mostly seen from your previous posting.

Here are the top 10 programming books that I recommend to all C++
programmers:
Effective C++ by Scott Meyers
More Effective C++ by Scott Meyers
Exceptional C++ by Herb Sutter
More Exceptional C++ by Herb Sutter
Effective STL by Scott Meyers
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices {Herb
Sutter, Andrei Alexandrescu}
Programming languages - C++ STANDARD ISO/IEC 14882:1998(E)
C++ Programming Language Special Edition, The by Bjarne Stroustrup
Efficient C++ by Dov Bulka & David Mayhew
Modern C++ Design by Andrei Alexandrescu

And you don't have to take my word for it. Instead look them up in the
following well known respected site:
advanced c++
http://www.accu.org/bookreviews/publ...vanced_c__.htm

[roberts.noah]

Axter wrote:

It's also a mistake to base your opinions on out dated beginner's C++
books.
You sure make a lot of assumptions little boy.

Thinking in C++ V2 is (c) 2003. The standard was altered in this one
little way just before publication apparently. This is really no big
deal, it happens. This is a very good book in every other way. I
refer to it quite often in fact, along with "The C++ Standard Library",
which is equally "outdated" by your standard. I have quite a few
"beginner" books I use as reference when I need to.
If you're going to advocate a position that contradicts others, you
should at least make the effort to be well informed by more respectable
sources.
By "contradict others" I think you must mean yourself? I don't need my
degrees, my experience, or my references to know that the code sample
you keep touting around is trash.
Otherwise garbage in, garbage out.
Well, if that is true then I would have to assume the books you read
are garbage. Luckily it doesn't work that way.
You read garbage, and you're going to end up reiterating the same
garbage, which is what I've mostly seen from your previous posting.

Thinking in C++ is not garbage. The first volume is a great
introduction to the language. The second volume is very good
instruction on how to USE the language at several levels. The second
volume is one of the best C++ books around.

[Niklas Norrthon]

Neil Cerutti <le*******@emai l.com> writes:

Nothing prevents a standard compliant implementation from always
reserving 100,000,000*siz e(T) bytes for each vector, either, but
mostly we don't need to worry about that unless the vendor of our
compiler is named Snidely Wiplash. ;-)

But reserving space for 100,000,000 items by default would be deemed
as unreasonable by most people, while I think it's perfectly
reasonable for a copy constructor to reserve the same amount of
memory as the source vector has reserved. Especially since it's
trivial to call another constructor if one doesn't need that
amount of reserved space in the copy.

/Niklas Norrthon

[Neil Cerutti]

On 2005-12-16, Niklas Norrthon <do********@inv alid.net> wrote:

Neil Cerutti <le*******@emai l.com> writes:

Nothing prevents a standard compliant implementation from
always reserving 100,000,000*siz e(T) bytes for each vector,
either, but mostly we don't need to worry about that unless
the vendor of our compiler is named Snidely Wiplash. ;-)

But reserving space for 100,000,000 items by default would be
deemed as unreasonable by most people, while I think it's
perfectly reasonable for a copy constructor to reserve the same
amount of memory as the source vector has reserved.

I don't agree. Copying capacity makes unsuppported assumptions.
At extremes, it's making the same assumption that you find
unreasonable in a default constructor.

--
Neil Cerutti

[Alf P. Steinbach]

* Neil Cerutti:

On 2005-12-16, Niklas Norrthon <do********@inv alid.net> wrote:

Neil Cerutti <le*******@emai l.com> writes:

Nothing prevents a standard compliant implementation from
always reserving 100,000,000*siz e(T) bytes for each vector,
either, but mostly we don't need to worry about that unless
the vendor of our compiler is named Snidely Wiplash. ;-)

But reserving space for 100,000,000 items by default would be
deemed as unreasonable by most people, while I think it's
perfectly reasonable for a copy constructor to reserve the same
amount of memory as the source vector has reserved.

I don't agree. Copying capacity makes unsuppported assumptions.
At extremes, it's making the same assumption that you find
unreasonable in a default constructor.

Well, the reason I used assign (I should really have used the constructor
taking iterators) was that this was once asked about in clc++m, but there
concerning std::string, and I posted code using the copy constructor and was
quickly corrected by someone noting that with their compiler, the
std::string copy constructor actually did copy the capacity.

So whether it's an unsupported assumption or not, it's Out There.

Waiting for a chance to grab you... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?