share variables between methods within a class

* a special map instance field to hold all such data. Map of Objects, so casting needed everywhere.

* (laziest) instance field? reserved for instance attributes. Don’t abuse.
* (laziest) static field? reserved for class attributes. Don’t contaminate.
* return a collection? A bit clumsy but recommended by many.
* best option: avoid sharing. Stick to local vars if possible.
* 2nd best: sometimes the shared variable really belongs to another class. That class/object perhaps is already shared between your methods. Essentially use that object as a courier. More work than the laziest.

hibernate — essential techniques to SELECT query

* Technique: standard associations (m:1,m:n etc) — You need not write the query to SELECT the “associated” objects. If you load Students and want the associated Course loaded, Hibernate automatically constructs the Course query based on the Course.hbm.xml.

* Technique: HQL — You may need to write HQL to select students.

* Technique: views — Completely outside and unknown to hibernate, you can implement complex SELECT in a view and mention its name in a hbm.xml file, as if it’s a table.

* technique: native sql —

* technique: proc — existing logic in proc? This would be the ultimate. most powerful and customized.

2 FX interbank broker ^ 2 interdealer treasury broker

Treasury Inter-dealer brokers are the backbones of treasury market. BrokerTec and Espeed…

FX interbank brokers are the backbones of currency market. In Spot FX, EBS and Reuters (see separate blog) are the only 2 big brokers. See and the investorpedia article. Big banks handle very large transactions often in billions of dollars. These transactions cause the primary movement of currency prices (in the short term?) In the long term, fx is influenced not by the big bank’s actions, but economies.

Reuters’ system for Spot is a the electronic version of traditional voice execution. A screen-based “conversational” system so both sides know each other. Trades execute in the conversation, much like voice execution.

In contrast, EBS is anonymous. Trades execute when market-takers hit a button on screen.

For FX Forward, Reuters (see the other post) is dominant, but Tullet Prebon is popular too.

top 3 key nlg pearls on thread methods

A: wait(), lock()

#1. Each of the Thread object’s static/non-static methods must execute in a call stack — ie a real thread, and this real thread can be unrelated to the Thread. You should always ask “Is this Thread method affecting the call stack (ie the real thread) ?”

#2 Q: Many other methods (sometimes designed to) affect their call stack, but are not defined in Example?

v-table and v-ptr in pseudo code is a one-pager with pseudo code. Here are some of my comments
tanbin – one v-table per class in the hierachy, shared by all instances. Parent’s v-table, child’s v-table…
tanbin – one v-ptr per instance. Since a child instance wraps a parent, the entire “onion” has a single v-ptr
tanbin – the v-ptr is reseated once when each “onion” layer is added during construction. Each child constructor in the hierarchy can reseat the v-ptr to point to the child’s own v-table

Let’s work an example. Suppose class Base has 5 virtual functions: virt0() through virt4().

// Your original C++ source code

class Base {
arbitrary_return_type virt0(…arbitrary params…);
arbitrary_return_type virt1(…arbitrary params…);


Step #1: the compiler builds a static table containing 5 function-pointers, burying that table into static memory somewhere. Many (not all) compilers define this table while compiling the .cpp that defines Base‘s first non-inline virtual function. We call that table the v-table; let’s pretend its technical name is Base::__vtable. If a function pointer fits into one machine word on the target hardware platform, Base::__vtable will end up consuming 5 hidden words of memory. Not 5 per instance, not 5 per function; just 5 for the class. It might look something like the following pseudo-code:

// Pseudo-code (not C++, not C) for a static table defined within file Base.cpp

// Pretend FunctionPtr is a generic pointer to a generic member function
// (Remember: this is pseudo-code, not C++ code)
FunctionPtr Base::__vtable[5] = {
&Base::virt0, &Base::virt1, &Base::virt2, &Base::virt3, &Base::virt4

Step #2: the compiler adds a hidden pointer (typically also a machine-word) to each object of class Base. This is called the v-pointer. Think of this hidden pointer as a hidden data member, as if the compiler rewrites your class to something like this:

// Your original C++ source code

class Base {

FunctionPtr* __vptr;
supplied by the compiler, hidden from the programmer


Step #3: the compiler initializes this->__vptr within each constructor. The idea is to cause each object’s v-pointer to point at its class’s static v-table, as if it adds the following instruction in each constructor’s init-list:

Base::Base(…arbitrary params…)
: __vptr(&Base::__vtable[0])
supplied by the compiler, hidden from the programmer



Now let’s work out a derived class. Suppose your C++ code defines class Der that inherits from class Base. The compiler repeats steps #1 and #3 (but not #2). In step #1, the compiler creates a new hidden v-table for class Der, keeping the same function-pointers as in Base::__vtable but replacing those slots that correspond to overrides. For instance, if Der overrides virt0() through virt2() and inherits the others as-is, Der‘s v-table might look something like this (pretend Der doesn’t add any new virtuals):

// Pseudo-code (not C++, not C) for a static table defined within file Der.cpp

// Pretend FunctionPtr is a generic pointer to a generic member function
// (Remember: this is pseudo-code, not C++ code)
FunctionPtr Der::__vtable[5] = {
&Der::virt0, &Der::virt1, &Der::virt2, &Base::virt3, &Base::virt4
}; ^^^^----------^^^^---inherited as-is

In step #3, the compiler adds a similar pointer-assignment at the beginning of each of Der‘s constructors. The idea is to reseat each Der object’s v-pointer so it points at Der class’s v-table. (This is not a second v-pointer; it’s the same v-pointer that was defined in the base class, Base; remember, the compiler does not repeat step #2 in class Der.)
Finally, let’s see how the compiler implements a call to a virtual function. Your code might look like this:

// Your original C++ code

void mycode(Base* p)

The compiler has no idea whether this is going to call Base::virt3() or Der::virt3() or perhaps the virt3() method of another derived class that doesn’t even exist yet. It only knows for sure that you are calling virt3() which happens to be the function in slot #3 of the v-table. It rewrites that call into something like this:

// Pseudo-code that the compiler generates from your C++

void mycode(Base* p)

On typical hardware, the machine-code is two ‘load’s plus a call:

  1. The first load gets the v-pointer, storing it into a register, say r1.
  2. The second load gets the word at r1 + 3*4 (pretend function-pointers are 4-bytes long, so r1+12 is the pointer to the right class’s virt3() function). Pretend it puts that word into register r2 (or r1 for that matter).
  3. The third instruction calls the code at location r2.


  • Objects of classes with virtual functions have only a small space-overhead compared to those that don’t have virtual functions.
  • Calling a virtual function is fast — almost as fast as calling a non-virtual function.
  • You don’t get any additional per-call overhead no matter how deep the inheritance gets. You could have 10 levels of inheritance, but there is no “chaining” — it’s always the same — fetch, fetch, call.