STL container erase during reverse iteration – map, list

Tip: reverseItr.base() is designed for insert-by-fwd-iterator. To emulate insertion at a position of a reverse_iterator named ri, insert() at the position ri.base() instead.

Now let’s be specific. When we say “insert at ri” we mean insert to the Right of ri, or insert “inFrontOf” ri in the iteration direction. That’s your goal, but not your code, because insert() can only use fwd iterators. So you use ri.base() to insert and it exactly inserts to the Right of ri. Therefore, For purposes of insertion, ri and ri.base() are equivalent, so to speak.

For the purpose of logical insertion, ri.base() is truly the fwd iterator corresponding to ri. See

Warning: For purposes of erasure, ri and ri.base() are Not equivalent, and ri.base() is Not the fwd iterator corresponding to ri.

Tip: After erase, the r-iterator value is less intuitive to predict. (I believe it points to ri + 1.) Better  continue/break the for-loop, rather than executing to end of the current iteration. It’s not always straightforward to directly “dump” the reverse-iterator.

Tip: after erasing, print all Keys to be sure.

Tip: instrument dtor to see which node is erased

Tip #1: if you need to continue looping, then don’t use for-loop. Use a while loop to gain control over exit condition and over increment on the reverse iterator.


for (MapType::reverse_iterator ri = bidBook.rbegin(); ri != bidBook.rend();){

ListType & li = ri->second;
if (li.empty()) {
} else {
bestBid = ri->first;

iterators – pbclone, not by pointer or ref

Iterators – generalizations of pointers – are expected to be copied cheaply. The copy cost is never raised as an issues.

Iterators are usually passed by value. Sutter and Alexandrescu recommended (P154 in their book) putting iterators into containers rather than putting pointers into containers. Containers would copy the iterators by value.

someContainer.end() often returns a temp object, so taking its address is a bug. The returned iterator object from end() must be passed by Value.

Someone online said that If an argument is taken by value, this makes it usually easier for the compiler to optimize the code. Look at the advantage of using function objects by value instead of taking function pointers. This is a similar reason for by-value parameters reasoned on the level of functions objects.

Note java/c# arguments are predominently passed by reference.

silverlight – Boris

SL runs on both client machine and server machine. SL always needs a serverside. Server must be windows, usually IIS, but can also be WCF services hosted in WinServices or consolt hosts.

SL can run standalone outside a browser, but is usually run inside a browser.

You write SL just like you write WPF. Rather different from ASP

essential FIX messages

Focus on just 2 app messages – new order single + a partial fill. Logon/Logout/heartbeat… LG2 — important session messages.

Start with just the 10 most common fields in each message. Later, you need to know 20 but no more.

For the most important fields – tag 35, exectype, ordstatus, focus on the most important enum values.

This is the only way to get a grip on this slippery fish

25-13:34:27:613440 |250—-> 16 BC_ITGC_14_CMAS_104 1080861988 |



— A NewOrderSingle followed by 2 exec reports —

25-13:34:27:802535 |<—-252 13 BC_ITGC_14_CMAS_104 1079105241 |



25-13:34:27:990564 |<—-253 13 BC_ITGC_14_CMAS_104 1079105241 |



c++/vol IV: FX risk (barcap?) mid2012

Q: basic exception guarantee
Q: stochastic vol vs local vol?
Q: what’s RAII? What are the major classes you know using RAII
%%A: smart pointers, locks, stl containers, strings??

Q: what synchronization classes are there in c++?
Q: can a static member function be const?
%%A: no. the const is on “this”

Q: is it ok to mark a field mutable
%%A: I think so. student.getAge() can modify lastAccessed timestamp.

Q: what are the option models you know

intrusive smart ptr — phrase book

* MI — P35 [[beyond c++ standard lib]] shows your pointee CLASS can be written to multiple-inherit from a general-purpose ref_count holder class. This is a good use case of multiple inheritance, perhaps in QA codebase.

* real-estate — The 32-bit ref counter lives physically on the real estate of the pointee. Pointee type can’t be a builtin like “float”. In contrast, a club of shared_ptr instances share a single “club-count” that’s allocated outside any shared_ptr instance.

* legacy — many legacy smart pointer classes were written with a ref count in the pointee CLASS like QA YieldCurve. As a replacement for the legacy smart pointer, intrusive_ptr is more natural than shared_ptr.

* builtin — pointee class should not be a builtin type like float or int. They don’t embed ref count on their real estate; They can’t inherit; …

* TR1 — not in TR1 (, but popular

* ref-count — provided by the raw pointee Instance, not the smart pointer Instance. Note the Raw pointER Instance is always 32 bit (assuming 32-bit bus) and can never host the reference count.

* same-size — as a raw ptr

* expose — The pointee class must expose mutator methods on the ref count field

single-stepping 4 stages of gcc compliation

First 3 stages are file-by-file; 4th stage merges them. You can use “file anyFileName” to check out each intermediate file, and cat it if ascii.
–1) preprocessor.
yourSourceCode => preprocessedSource — often 200 time larger.
Both ascii format.
to run this single step — gcc -E
–2) assembler. This is Before compiler.
preprocessedSource => assembledTextFile.
Both ascii format — yes for the assembler!
to run this single step — gcc – S
–3) compiler.
assembledTextFile => individualObjectFile
Ascii -> binary
to run this single step — gcc -c -x assembler
One object file for each original source file.
–4) linker.
individualObjectFiles => singleMergedObjectFile
Now executable.

yield CURVE ^ yield/price CURVE

There are many curves in bond math, but these 2 curves stand out as by far the 2 most useful.

* the yield curve and twin sister the discount curve, aka the swap curve
* the yield/price graph.

Note duration, convexity, dv01 are defined on the y/p curve.

For a given bond or for a given position, the y/p curve is fundamental. Most bond characteristics are related to or reflected on the y/p curve.