[Effective-cpp] Item 1: Uses and Abuses of vector

[Paul Grenyer]

Hi Tim

Well done and thank you for posting your item! Early is good. If anyone else 
wants to post their item a few days early, that is fine, as long as it 
doesn't eclipse anyone else's item that is being discussed at the time.

I've have added your item to the website: 
http://www.paulgrenyer.dyndns.org/cppstyle/items.php#item1

> There are two accessors for the vector container that have slighty 
> different meaning.  v[0] gets the zeroeth element of the vector.  If there 
> is not any elements in the vector, then we don't know what will happen. 
> The standard allows bounds checking but does not require it for this 
> function.  Bounds checking is not required so it can be efficient and 
> replace the old array.  The other element accessor, v.at(0), does require 
> bounds checking and is guaranteed to throw a std::out_of_range exception. 
> Understand when you want to use at() verses [].

I found Herb's discussion in this chapter very interesting and easy to 
follow. I think that the JG and Guru questions would make very interesting 
interview questions.

> o) Be const correct. In particular, use const_iterator when you are not 
> modifying the contents of a container. Personally I struggled with the 
> idea of const for years.  I think it is just one more helpful tool to make 
> life easier and you do it when you can.

Personally, and only slightly different, I always follow the general rule 
"use const except when you can't."

> o) Prefer comparing iterators with != , not <.  The book mentions that 
> this is allowed for all iterators so it is easy to change containers. 
> However, as stated in Effective STL, it might be more complicated than 
> just != to switch containers in the code and it might be too costly to 
> keep that avenue open.  But != is a easy price to pay, it works for 
> everyone.

This section is good, because remembering exactly why != should be used 
instead of < is always difficult for me and now I have (another) reference 
to remind me.

> o)  Get in the habit of using the prefix forms of -- and ++ by default, 
> unless you really need the old value.

Interestingly the "unnecessary temporary" is not mentioned.

Tim, what about "Avoid needles recalculations" and "Prefer '\n' to endl"?

I see for(; idx != x.end(); ++x) in peoples code a lot and it's depressing. 
However, I wasn't aware that some compilers did the optimisation for you, 
still, as suggested in the text, it should not be replied upon.

> o) Practice reuse:  Prefer reusing existing algorithms, particularly 
> standard algorithms (e.g. for_each) instead of crafting your own loops. 
> Reuse might prevent the possibility of introducing more errors like prefix 
> forms, != etc.

I have become more and more disillusioned with this particular idea 
recently. It's fine for the examples in the book, where standard library 
predicates such as, ostream_iterator are used (although I hate having to 
look things up!), but for custom predicates I don't think it's so good. 
Also, I'm not convinced by Meyers saying that if can be more efficient. The 
three main problems I have using algorithms and my own predicates are:

1. Coming up with a good descriptive name that describes what the predicate 
does in order to remove the need for the maintainer to look for its 
implementation.

2. Where to put the predicate so it's easy for the maintainer to find. If 
it's in an anonymous namespace at the top of the file the maintainer has to 
scroll up for it, if it's above the (for arguments sake) member function 
definition, it's untidy.

3. Often using a predicate results in more code.

> I hope I covered the major points.Regards

I certainly think so!

Paul

Paul Grenyer
email: paul at paulgrenyer.co.uk
web: http://www.paulgrenyer.co.uk
articles: http://www.paulgrenyer.dyndns.org/articles

Jensen should have gone to Williams.
Ecclestone is killing the sport.