Effective stl notes

Effective STL Notes

UTTAM GANDHI,
SOFTWARE DEVELOPER

Pre-requisites

—  C++
—  Data Structure
—  Templates
—  Smart Pointers
—  Constant Time, Logarithmic, Linear

Uttam Gandhi, Software Developer
http://www.linkedin.com/pub/uttam-gandhi/21/7aa/24 Content last revised on 1/4/13

Acknowledgments

—  This presentation is based on Scott Meyers well
known book ‘Effective STL’


Why STL

—  Contains most useful algorithms and data structures
—  Established programming techniques, idioms and
styles
—  Usually very-well tested
—  Usually highly optimized (might use optimizations
that are not available to ordinary programmer)
—  Ref-- http://www.cs.helsinki.fi/u/tpkarkka/alglib/
k06/lectures/stl_intro.html


STL Intro duction

—  STL consists of
¡  Containers

¡  Algorithms

¡  Iterators


Containers

—  Types of container
¡  Sequence containers
÷  vector
÷  list
÷  string
÷  deque
¡  Associative Containers
÷  set
÷  multiset
÷  map
÷  multimap
÷  unordered_map (C++ 11)


Containers

—  Container type based on allocation
¡  Contiguous-memory containers
÷  Insertion and deletion causes movement of elements
÷  vector, string, deque

¡  Node-based containers
÷  Insertion and deletion changes pointers, not nodes
÷  list and all associative containers


How to choose your container

—  Insert element at an arbitrary position
—  Ordering of elements in the container
—  Category of iterators
—  Is it important to avoid movement of existing
container elements when insertions or erasures take
place?
—  Layout compatible with C
—  container uses reference counting


Containers do Copy

—  Containers make copies of object
¡  Storing

¡  Retrieving

¡  Insert/Delete causes movement of objects by copying

¡  Sorting algorithms

—  Copying is done using copy constructor and copy
assignment operator
—  Copying should be efficient
—  Copying can lead to slicing


Making Copy Efficient

—  Use pointers
¡  Efficient, as bitwise copy will be made

¡  No slicing

¡  But possibility of memory leak

¡  Use smart pointers (self managed/shared/intrusive)

¡  Ref http://onlamp.com/pub/a/onlamp/2006/05/04/smart-
pointers.html?page=5
—  Still STL containers are better than C data structure
¡  Widget w[maxNumWidgets];

¡  vector<widget> vw;

¡  vw.reserve(maxNumWidgets)


Use empty than size==0

—  Use empty, rather than checking size == 0
¡  For some list implementation, size takes linear time

¡  Why
¢  Splice operation moves elements from one list to other without
copying elements
¢  If, size operation has to be constant then every list operation
should update size
¢  This means, splice operation will take linear time

¢  One of the two can be constant but not both

¡  empty() will always be constant


Prefer range member functions 1/3

—  vector<Widget> v1, v2;
for ( vector<Widget>::const_iterator ci =
v2.begin(); ci != v2.end(); ++ci)
v1.push_back(*ci);
¡  lengthy code
¡  for loop

—  copy(v2.begin(), v2.end(), back_inserter(v1 ));
¡  For loop is inside copy implementation

—  v1 .insert(v1 .end(), v2.begin(),v2.end());
¡  Short code
¡  Clear to understand



—  Efficiency Hits
¡  Inserting one element at a time, makes numValues calls of
insert
÷  Range function will make single insert call, so numValues-1 less
calls
÷  Inlining could have saved, but its not guaranteed
÷  Range insert will always be efficient
¡  Inserting element will cause movement of elements by copying
them
÷  Every element will be shifted at least numValues times
÷  Shifting of primitive will require bitwise copy
÷  For user defined type, calls to assignment operator or copy
constructor



—  Efficiency Hits
¡  Inserting element in vector can cause reallocations
÷  In case of range insert, reallocation would be 1 at max
÷  inserting numValues new elements could result in new memory
being allocated up to log2numValues
÷  inserting 1000 elements one at a time can result in 10 new
allocations


Use delete for new element in container 1/3

void doSomething()
{
vector<Widget*> vwp;
for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)
vwp.push_back(new Widget);
… // use vwp
}
This is a leak



void doSomething()
{
vector<Widget*> vwp;
… // as before
for (vector<Widget*>::iterator i = vwp.begin();
i != vwp.end(),
++i) {
delete *i;
} still there can be leak because of exception


void doSomething()
{
typedef boost::shared_ ptr<Widget> SPW;
vector<SPW> vwp;
for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)
vwp.push_back(SPW new Widget)
… // use vwp
} // no Widgets are leaked here, not
// even if an exception is thrown
//in the code above

Choosing Erasing Options

—  Erase remove for sequence containers
¡  c.erase( remove(c.begin(), c.end(), 1963), c.end());

¡  remove function being receives only iterator (no container)

¡  remove takes linear time

—  List
¡  c. remove(1963);
—  Associative container
¡  c.erase(1963);

¡  Takes logarithmic time



—  Erase remove for sequence containers
¡  c.erase( remove_if(c.begin(), c.end(),badValue), c.end());
¡  badValue is the predicate

—  List
¡  c. remove_if(1963);

—  Associative container
¡  simple but does not work due to iterator invalidation
¡  The iterator pointing to erase becomes invalid, after execution of erase
AssocContainer<int> c;
......
for (AssocContainer<int>::iterator i = c.begin();
i!= c.end(); ++i) {
if (badValue(*i)) c.erase(i);
}



AssocContainer<int> c;
for (AssocContainer<int>::iterator i = c.begin(); i !=
c.end(); ){
if (badValue(*i)) c.erase(i++);
else ++i;
}
¡  If there is a match erase is done using i
¡  i is incremented as a side-effect (before erase is executed)

¡  Effectively i is incremented before invalidating


Prefer vector and string

—  Dynamic Allocation
¡  Ensure delete is called for every new, else leak
¡  Ensure delete[] is called for array
¡  Ensure delete called only once
—  Vector and string advantages
¡  Manage own memory
¡  Offer useful member functions like size, iterators, erase
¡  Can be used with legacy C code using array and char*
—  Drawback
¡  string uses ref counting
¡  Causes overhead of concurrency control in multithreaded
environment
¡  http://www.gotw.ca/publications/optimizations.htm

Prefer vector and string

—  Solution
¡  Disable ref counting by changing pre-processor variable, may
not be portable
¡  Find alternative string implementation

¡  Use vector<char>
÷  stringfunctions will not be available
÷  But STL algorithms will serve the purpose J

—  Avoiding reallocation in vector
¡  Use reserve


Pass vector and string to legacy API

—  Vector
¡  void doSomething(const int* pInts, size_t numlnts);

¡  doSomething(&v[0], v.size());

¡  Frankly, if you're hanging out with people who tell you to use
v.begin() instead of &v[0], you need to rethink your social
circle.
¡  v can be modified but no new element should be added

¡  size_t fillArray(double *pArray, size_t arraySize);

¡  vector<double> vd(maxNumDoubles);

¡  vd.resize(fillArray(&vd[0], vd.size()));
¡  list<double> l(vd.begin(), vd.end());


Pass vector and string to legacy API

—  String
¡  void doSomething(const char *pString);

¡  doSomething(s.c_str());


Use swap to trim excess capacity

—  class Contestant {...};
—  vector<Contestant> contestants;

—  vector<Contestant>(contestants).swap(contestants);

¡  Temporary vector gets created using copy constructor
¡  It is created by the existing size (shrink)

¡  Swap happens, now temporary holds excess capacity

¡  At the end of statement temporary is destroyed


Equality and Equivalence 1/3

—  Equality is based on ==, “x==y”
¡  Widget w1, w2

¡  w1 == w2 returns true

—  Equivalence is based on operator <
¡  !(w1 < w2) && !(w2 < w1)

¡  Equivalence is based on the relative ordering of object values
in a sorted range
¡  Used in storing, retrieving in associative container

¡  two values are equivalent (with respect to some ordering
criterion) if neither precedes the other (according to that
criterion)


—  !c.key_comp()(x, y) && !c.key_comp()(y, x)
struct CiStrCom:public binary_function<string, string,
bool> {
bool operator()(const string& lhs, const string& rhs)
const {
return ciStringCompare(lhs, rhs);
}
}
set<string, CiStrCom> ciStringSet;



—  ciss.insert("Persephone"); // a new element is added
to the set
—  ciss.insert("persephone"); // no new element is
added to the set
—  if (ciss.find("persephone") != ciss.end())... // this test
will succeed
¡  Uses equivalence, so works
—  if (find( ciss.begin(), ciss.end(), "persephone") !=
ciss.end())... // this test will fail
¡  Uses equality, fails in this case

Overriding default comp function

—  When you declare set of string pointer
¡  set<string*> ssp;

¡  ssp.insert(newstring("Anteater"));

¡  ssp.insert(newstring("Wombat"));

¡  ssp.insert(new string(“Lemur"));

¡  ssp.insert(newstring("Penguin"));

—  Default sort function is provided by STL
¡  In this case default function will do pointer value comparison

¡  For string comparison, you must provide own functor

¡  set<string*, less<string*> > ssp;


Functor for string dereference

struct StringPtrLess: public binary_function<const
string*, const string*, bool> {
bool operator()(const string *ps1, const string *ps2)
const {
return *ps1 < *ps2;
}
};
typedef set<string*, StringPtrLess> StringPtrSet ;
StringPtrSet ssp;


Templatized functor for de-reference

struct DereferenceLess {
template <typename PtrType>
bool operator()(PtrType pT1, PtrType pT2) const
value, because we expect them
{
return *pT1 < *pT2;
}
};


Comp should return false for equal value 1/2

—  set<int, less_equal<int> > s; // s is sorted by "<="
—  s.insert(10); //insert the value 10
—  Now try inserting 10 again:
—  s.insert(10);
—  !(10A<= 10B)&&!(10B<= 10A) //test 10Aand 10B for
equivalence
—  set concludes that 10A and 10B are not equivalent


Comp should return false for equal value 2/2

—  multiset<int, less_equal<int> > s; // s is still sorted
by "<="
—  s.insert(10); //insert 10A
—  s.insert(10); // insert 10B
¡  equal_range on it, we'll get back a pair of iterators that define a
range containing both copies
¡  equal_range identifies a range of equivalent values


In-place modification of set/multiset value1/2

—  Map/multimap key modification will not compile
—  Set object is not const because you still want to
modify other properties of object
—  If property/value used for sorting is modified, the
container is corrupt


In-place modification of set/multiset value2/2


Sorted vector v/s associative container 1/3

—  Standard associative container
¡  Typically implemented as balanced binary trees

¡  optimized for mix of lookup, insertion and deletion

¡  No way to predict the next operation

—  Typical application usage of container
¡  Setup
÷  All operation are insert/delete, hardly any lookup
¡  Lookup
÷  Almost all operations are lookup
¡  Reorganize
÷  Modify, insert/delete, sort


—  For such usage, sorted vector can provide better
performance
¡  Size
÷  Less size per element in vector, so storing takes less space
÷  Will lead to less page fault
÷  As vector offer better locality of reference
÷  Insertion/deletion can be costly, so not useful if application
requires too many of these


map::operator[] and map-insert 1/2

—  map::operator[]
¡  Provides add/update functionality

¡  Returns reference to value

¡  If object does not exists,
÷  creates default constructed object
÷  insert in map
÷  Destructor of temporary object
÷  Assignment

¡  If insert is called directly, 3 function calls are saved


map::operator[] and map-insert 2/2

—  Update
¡  m[k] = v;
÷  Requires no object creation, deletion
¡  m.insert( IntWidgetMap::value_type(k, v)).first->second = v;
÷  Temporary object of Widget is create, destroyed


Iterators

—  Prefer iterator over const_iterator
¡  Many functions use iterator

¡  iterator insert(iterator position, const T& x);

¡  iterator erase(iterator position);

¡  iterator erase(iterator rangeBegin, iterator rangeEnd);

—  Conversions


const_iterator to iterator 1/2


const_iterator to iterator 2/2

—  It won’t compile
¡  Distance(InputIterator it1, InputIterator it2)
¡  Cannot accept two different types
¡  Need to specify type of template
¡  advance(i, distance<ConstIter>(i, ci));
—  Efficiency
¡  For random access iterators in vector, string, deque – const
¡  For others its linear
—  Read unformatted char data
ifstream inputFile("interestingData.txt");
string fileData((istreambuf_iterator<char>(inputFile)),
istreambuf_iterator<char>());


Destination Range should be big enough 1/3



—  back_inserter, calls push_back
¡  Works with sequence container (vector, list, string deque)

—  front_inserter can also be used
¡  List, deque

—  Inserter
¡  Insert at specified position


Sorting Options 1/3

—  Applicable on sequence containers
¡  vector, deque, string, array

—  sort and stable_sort
¡  stable_sort maintains position of equivalent elements

—  partial_sort
¡  e.g. Get best 20 widgets sorted

—  nth element
¡  e.g. Get best 20 widgets, in any order

—  partition/stable_partition
¡  Partition on a criterion


Sorting Options 2/3


Sorting Options 3/3


Remove algorithm on container of pointers


After remove is called


After erase is called


Algorithms expecting sorted ranges

—  binary search algorithms
¡  binary_search
¡  lower_bound
¡  upper_bound
¡  equal_range
—  Set Operations
¡  set_union
¡  set_intersection
¡  set_difference
¡  set_symmetric_difference
—  Mege Sorted Ranges
¡  merge
¡  implace_merge
—  Includes
¡  Check if range is present in other range
—  unique
—  unique_copy


Use same algo for sort and search


Copy_if implemented


Function Objects

—  Passed by value
¡  Should be small

¡  Monomorphic (non-polymorphic)


Make functors adaptable


ptr_fun


Adaptable Functors


not1 and bind2nd


ptr_fun, mem_fun and mem_fun_ref

—  3 ways to call C++ function


for_each usage


for_each implementation

—  for_each is written in a way, its only compatible with
call#1


mem_fun example


Prefer algorithm to hand-written loop 1/2

¡  Algorithms are often more efficient than the loops
programmers produce.
—  Correctness
¡  Writing loops is more subject to errors than is calling
algorithms.
—  Maintainability
¡  Algorithm calls often yield code that is clearer and more
straightforward than the corresponding explicit loops.


Prefer algorithm to hand-written loop 2/2

¡  Check of end() is done only once

¡  Call to begin, end are generally inlined inside for_each

¡  Have knowledge about internal implementation of container
÷  E.g. using pointers for vector traversal
¡  Implementers use more sophisticated algo than avg c++
programmer


Prefer member function to algorithm 1/2

—  Why
¡  Member functions are faster

¡  They integrate better with container(especially associative)

—  Example


Prefer member function to algorithm 2/2

¡  Member find: About 40 (worst case) to about 20 (average case)
¡  Algorithm find: 1 ,000,000 (worst case) to 500,000 (average
case)
—  Equivalence and eqality
¡  std::find uses equality, set::find uses equivalence

—  list functions
¡  remove, remove_if. unique, sort, merge, and reverse

¡  each std version copy objects

¡  list members do not copy objects

¡  remove_erase is needed if std version used, list::remove works
directly

Search options 1/2

—  Logarithmic complexity
¡  binary_search

¡  lower_bound

¡  upper_bound

¡  equal_range

¡  Uses equivalence

—  Linear Search Complexity
¡  find

¡  count

¡  Use equality


Search options 2/2

—  find v/s count
¡  find stops at match of value

¡  count looks till end

¡  find is efficient for check of existence

—  binary_search
¡  Widget w; //value to search for

¡  if (binary_search(vw.begin(), vw.end(), w))

—  lower_bound
¡  Returns iterators to first match, if not found returns position,
where the element should be inserted


equal_range

—  equal_range
¡  Returns pair of iterator pointing to first and last occurrence of
match
¡  If not found, both iterator return same position, where the
element should be inserted


lower_bound v/s upper_bound


Use functor over functions


Function v/s Functor performance

—  Function v/s functor performance
¡  Functor version was 50% to 160% efficient than function

¡  This is because of inlining

¡  std::sort beats C qsort
÷  Sorting of a vector of million doubles was 670% faster


Write – only code

—  get rid of all the elements in the vector whose value is
less than x, except that elements preceding the last
occurrence of a value at least as big as y should be
retained


Make it simple

—  v.f1 (f2(f3(v.f4(), v.f5(), f6(f7(), y)),.f8(), v.f9(),
f6(f10(), x)), v.f9());


Effective stl notes

More Related Content

What's hot

Viewers also liked

Similar to Effective stl notes

Recently uploaded

Effective stl notes