2

I am learning C++ STL and one thing that not sure is how to safely use STL.

For example one thing, I am constantly catching myself is using container, without doing if (!container.empty()). Seems a trivial thing to do, but is source of bugs.

Are there any rules or guides on how to safely use STL ?

Edit: So far, I found one such guide JSF Air Vehicle - C++ Coding Standards - Joint Strike Fighter, but it seems to be outdated by now (or at least was not updated, though most rules are applicable to this day)

TemplateRex
  • 69,038
  • 19
  • 164
  • 304
newprint
  • 6,936
  • 13
  • 67
  • 109
  • 3
    Scott Meyer's Effective STL is a good guide – Arun Oct 03 '13 at 05:01
  • Take a look at this link. Different language (Java), different idiom (checking for null pointer) ... but same basic issue: "How much 'defensive programming' is *TOO MUCH* defensive programming?" http://stackoverflow.com/questions/271526/avoiding-null-statements-in-java – paulsm4 Oct 03 '13 at 05:02
  • I agree with Arun: [Effective STL, Scott Meyers](http://www.amazon.com/Effective-STL-Specific-Standard-Template/dp/0201749629). I'd read [Effective C++](http://www.amazon.com/Effective-Specific-Improve-Programs-Designs/dp/0321334876) first, though :) – paulsm4 Oct 03 '13 at 05:04

3 Answers3

3

You can read Effective STL.

Instead of checking for empty containers you should generally write code that works without needing a check.

Many implementations have debug modes that will flag usage errors. Learn what your lib provides. Also some interfaces are specified as checked, such as .at() instead of the index operator.

bames53
  • 86,085
  • 15
  • 179
  • 244
  • Cool, had no idea that libraries have debug modes. – newprint Oct 03 '13 at 05:31
  • 2
    @newprint: fair warning, the debug mode of a standard library can substantially alter the running time of a program; for the most expensive checks a 20x factor is not unheard of. – Matthieu M. Oct 03 '13 at 06:58
  • @newprint: Your main takeaway should be "Instead of checking for empty containers you should generally write code that works without needing a check." IMHO.. – paulsm4 Oct 03 '13 at 15:21
2

Here are a few coding guidelines that make container.empty() checks mostly superfluous

  • properly initialize your containers, preferably with initializer-lists. This will get you off with a good start and a non-empty container :-)
  • if you need to fill a container with values from a input stream, use a std::back_inserter (sequence containers) or std::inserter (associative containers). This will take care of properly expanding your container.
  • if you need to process a container, prefer to use a Standard Library algorithm that accepts the container iterators. These algorithms behave gracefully for empty input.
  • if you need to write your own algorithm, use the container iterators begin() and end() and make sure an empty container is caught by a statement like it != end(). This will avoid things like pop_back() or erase() on an empty container.
  • hand-written modifying algorithms can run into iterator invalidation. Make sure you understand those rules.

The last items are perhaps the most tricky ones to get right. You really want to write your algorithms as general as possible so that the empty case is encompassed naturally without special casing.

Effective STL by Scott Meyers is the recommended guide for beginning/intermediate users of the Standard Library.

Community
  • 1
  • 1
TemplateRex
  • 69,038
  • 19
  • 164
  • 304
1

Here are a few, from my experience:

  • Use const_iterator while traversing containers, and you don't need to modify any elements
  • If using the [] operator to access elements in sequential contains, always verify the array bounds first
  • Don't add/remove elements to a container while traversing it, unless you know what you are doing
  • In a design using containers, model your functions to accept iterators rather than containers themselves. This way, your code could possibly be much more generic.

Will add more as I remember them.

Nikhil
  • 2,298
  • 13
  • 14
  • If you are going to use [] operator with additional bound checking then why not use at() method? – magor Oct 03 '13 at 09:27