practice STL

[Darshan]

Hi everyone,

Can anyone suggest a good practice to learn and practice C++ STL?

Darshan

 

[Juha Nieminen]

Can anyone suggest a good practice to learn and practice C++ STL?

Impletent std::list from scratch. If after that you don't understand
STL inside and out, I don't know how you will.

(Ok, maybe it is a bit too laborious of an exercise. But I have
learned quite a lot by doing that.)

 

[Alan Woodland]

Impletent std::list from scratch. If after that you don't understand
STL inside and out, I don't know how you will.

(Ok, maybe it is a bit too laborious of an exercise. But I have
learned quite a lot by doing that.)

A more practical suggestion might be force yourself to:

1) Never use arrays, use STL containers instead
2) Use <algorithm>, <numeric> whenever you want to do anything with an
STL container. Use <functional> too here probably.

The single thing that most improved my knowledge of the STL (which is
still lacking in quite a few areas, I know) was using <algorithm>
instead of rolling my own every time. I found this to be helpful in
moving me away from C (and Java) style thinking more generally too. For
the most part it's quite useful once you learn to realise when it's
appropriate or not. It did push me towards boost though several times
though as well!

Alan

 

[Brian Wood]

  Impletent std::list from scratch. If after that you don't understand
STL inside and out, I don't know how you will.

  (Ok, maybe it is a bit too laborious of an exercise. But I have
learned quite a lot by doing that.)

Container-wise I suggest using Boost Intrusive containers
where possible -- http://www.boost.org/doc/libs/1_39_0/doc/html/intrusive.html.

They have a number of advantages over the STL containers.

Also Ebenezer Enterprises has exclusive Intrusive marshalling
support. Neither Boost Intrusive nor Boost Serialization
offers serialization support of these containers.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Juha Nieminen]

Container-wise I suggest using Boost Intrusive containers
where possible -- http://www.boost.org/doc/libs/1_39_0/doc/html/intrusive.html.

I don't quite get what's so great about them. Especially this listed
downside seems to defeat the whole purpose of it being a data container
in the first place:

"The user has to manage the lifetime of inserted objects independently
from the containers."

The whole idea of a data container is to *store* data. In other words
the container takes care of managing the lifetimes of the stored data.
Now if you use a boost intrusive container, the container is not going
to manage the data at all, but you have to do it yourself. How? The only
possibility for managing dynamic data is to use a container such as the
ones offered by the standard C++ library. (How else are you going to
manage dynamic data? Doing direct news and deletes on the objects is
hazardous and certainly not recommended, especially not for someone who
is still learning C++ and STL.)

So it sounds like it would defeat the whole purpose. Why have the same
data in two different containers? What's the point?

 

[Brian Wood]

I don't quite get what's so great about them. Especially this listed
downside seems to defeat the whole purpose of it being a data container
in the first place:

"The user has to manage the lifetime of inserted objects independently
from the containers."

I'm sure you read the "Summary of intrusive containers advantages
and disadvantages." Besides the advantages listed there, another
advantage of Intrusive containers is the option to turn off keeping
track of the number of elements in the containers with
constant_time_size<false>. If you don't need to know the size
of a container, why pay for maintaining the count?

The whole idea of a data container is to *store* data. In other words
the container takes care of managing the lifetimes of the stored data.
Now if you use a boost intrusive container, the container is not going
to manage the data at all, but you have to do it yourself. How? The only
possibility for managing dynamic data is to use a container such as the
ones offered by the standard C++ library. (How else are you going to
manage dynamic data? Doing direct news and deletes on the objects is
hazardous and certainly not recommended, especially not for someone who
is still learning C++ and STL.)

I use direct news and deletes. I tend to agree with
your views on smart pointers and don't use them much.
Using Intrusive containers after getting used to STL
containers is a bit of an adjustment, but from what
I can tell, the benefits outweigh the risks.

So it sounds like it would defeat the whole purpose. Why have the same
data in two different containers? What's the point?

I don't follow you very well in the last two paragraphs,
but I don't need to store the same data in two different
containers.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Juha Nieminen]

I don't follow you very well in the last two paragraphs,
but I don't need to store the same data in two different
containers.

The only alternative to storing your objects in a data container is to
"manually" allocate them with 'new' and destroy them with 'delete'
(while keeping the handles to them in the intrusive data container).
However, if you are going to manually allocate and destroy your objects,
you are begging for trouble unless you also use some garbage collection
engine. It's way too easy to make mistakes which will result in memory
leaks, double deletions or accessing deleted memory.

Since doing "raw" news and deletes is hazardous and asking for
trouble, it's safer to store the objects in a managed data container,
such as the ones offered by the STL. But if you do that, you are
defeating the whole purpose of using the boost intrusive containers.

 

[Brian Wood]

  The only alternative to storing your objects in a data container is to
"manually" allocate them with 'new' and destroy them with 'delete'
(while keeping the handles to them in the intrusive data container).
However, if you are going to manually allocate and destroy your objects,
you are begging for trouble unless you also use some garbage collection
engine. It's way too easy to make mistakes which will result in memory
leaks, double deletions or accessing deleted memory.

The following is from the Intrusive documentation:

"Object lifetime
Even if the interface of list is similar to std::list, its usage is a
bit different: You always have to keep in mind that you directly store
objects in intrusive containers, not copies. The lifetime of a stored
object is not bound to or managed by the container:

When the container gets destroyed before the object, the object is not
destroyed, so you have to be careful to avoid resource leaks."

I use valgrind and other programs to make sure memory isn't
leaking. Also, the way I use the containers they live as long
as the program does, so the containers aren't destroyed before
the objects they are holding. I've not used Intrusive
containers in a multithreaded context and am not sure I'd
recommend using them there for reasons related to this
discussion. But in single threaded applications, they
work well and provide a number of advantages over the STL.

  Since doing "raw" news and deletes is hazardous and asking for
trouble, it's safer to store the objects in a managed data container,
such as the ones offered by the STL. But if you do that, you are
defeating the whole purpose of using the boost intrusive containers.

I agree with the last sentence, but disagree that raw news
and deletes should be avoided in this case.

This discussion makes me wonder if Boost has considered
adding a policy that would indicate the container will
manage the object lifetimes. It might be possible to have
what you want and then it would be up to users to make
sure they don't accidentally insert non-dynamic objects
into the container.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net