Fabric methods in c++ DTO classes (STL etc

The insert(),pop(),erase() etc are actually easy for most developers. Clear semantics. More tricky are the implicit “fabric” methods that convert from one type to another —

* Constructors esp. conversion constructors (cvctor)
* regular methods that converts *THIS to another type
* mysterious implicit type converters
* operator-overload converters
* operator[](), operator()()

You need to know them well for writing and esp. reading code. Remember the Millennium manager’s comment about implicit, context…? Seldom covered in phone interviews.

don’t explicitly clean up a stack object in c++

don’t explicitly clean up a stack object — let system do it.

“clean up” includes both destruct or delete.  Don’t explicitly delete a stack pointee or call destructor on a stack object.  http://www.cembedded.com/2009/07/c-c-interview-questions-part-6.html says

The destructor will get called again at the close } of the block in which the local was created. But you can get really bad results from calling a destructor on the same object a second time!

raw arrays and raw ptr still abound in c++

I doubt developers really follow this

Advice #1: Treat raw pointers and arrays as obsolete; favor smart pointers, vectors and string objects 99% of the time.

Look at any production code.
Look at any library code.
Look at any func param and return types.

C++, like C, is a low-level language. Pointers and addresses are the basic tools for a low-level language. Arrays are low-level too. However, c++ is often used as a high-level application language, just like java and c#. In that case, Advice #1 might apply.

Even in java, arrays are heavily used, often more than ArrayList.

Stored proc in an informatica pipe

2 common uses:

A) as a source qualifier. Overwrite the query with “exec yourSP param1, param2 ..”. Resultset will appear in the pipe

B) Stored Procedure transformation. The SP’s input parameters become the in-ports. Output params become out-ports. If you are the
SP’s author, result set columns can be “redirected” to out params. One input record coming down the pipe can produce multiple
records — active transformation.

each method call belongs to a thread^object

a j thread is essentially a call stack. Methods on the stack can belong to diff obj or (in the case of static methods) classes.

Each method call in a jvm
1) belongs to a thread (same thread as the caller method) AND
2) it also belongs to an obj/class.
3) By the way, it often has a caller obj.

WHO (which obj, not which class) calls WHOSE (which obj’s or class’s) method in WHICH thread largely defines the multi-threading architecture. This interaction can be complex but there are some patterns, esp. in GUI

CIP illustrated

Jargon: “forward-points” are bid/ask quotes. These are added on top of spot quotes
Jargon: full-forward-rates are the bid/ask quotes after the adjustments.
Sound byte: if my currency “drops”, then my interest rate should compensate that.

Q1: Suppose AUD (or USD…) spot interest rate is 200 bps [1] for a 1-year term. Yen spot rate is 150 bps. Suppose spot USDJPY = 100. What can you say about today’s AUDJPY forward rate with far date a year from now?
A1: this is Covered-Interest-Rate-Parity in action. Formula below gives F = 100*1.015/1.02 = 99.5098.

A more basic question is
Q2: will AUDJPY rate rise or fall?

We need to be thoroughly familiar with Q2 — AUD must WEAKEN (to 99.***) to reduce the high AUD return of 200bps!

[1] don’t care about Libor or treasury rate. Just consider it a measurable interest-rate

In practice, the 2 IR, the spot and forward fx rates always follow the equation. convert-deposit == deposit-convert. Otherwise, there will be arbitrage. This is described in both my bank online learning and [[complete guide]]

——textbook eg—–
USD 1 mth IR = 418 bps/year
GBP 1 mth IR = 480 bps/year
Spot cable = 1.7249
Number of days in the month = 31
Days basis GBP = 365
Days basis USD = 360

Let’s calculate 1-mth GBPUSD forward rate.

418 * 31/360 = 35.99444 bps of interest in USD
480 * 31/365 = 40.76712 bps of interest in GBP

Option A: 1 GBP invested today becomes #1.004076712 in a month
Option B: 1 GBP converted to USD and invested today becomes $1.7249 * 1.003599444 = $1.731109. Formula is S*(1+IR)

To make these 2 investments equally appealing to an investor, forward GBPUSD rate must be

1.731109/1.004076712 = 1-mth forward GBP/USD = 1.72408, which represents a depreciation of 8.2 pips.

Intuitively, GBP pays more interest, so GBP must depreciate. If GBP were to appreciate, then it’s too good to be true.

Textbook answer — Forward points = -0.00082

[ Formula is Spot-GBPUSD * (1 + IR-on-USD) == Forward-GBPUSD * (1 + IR-on-GBP)]
[ GBP convert to USD then deposit =========== GBP deposit then convert to USD ]
[ convert then deposit ==================== deposit then convert ]

—– a similar textbook example —–
AUD 3-mth 550 bps (high-yielder)
USD 3-mth 425 bps
Spot AUD/USD = 0.7326
Days = 92
Days basis AUD = 365
Days basis USD = 360
Forward AUD/USD = 0.7626 * (1 + 425 bps/360*92)/(1 + 550 bps/365*92) = 0.730431
Textbook answer — Forward points = -0.002169

guessing IR differential from FX fwd points

See post on the equation between forward/spot FX and IR differential.

Q2: why do you subtract in the descending case but add in the ascending case?
A2: because offer price must exceed bid price. If we were to add in the descending case, then spot bid (lower) + forward bid points (larger) might EXCEED spot offer (higher) + forward offer points(smaller)

Q1: If you see positive forward points like eur/usd 1mth = 11/12 (ascending order [1]), which currency earns higher interest for the next month?

A1: remember IR parity principle {{{ convert-deposit = deposit-convert }}}. Remember Euro is now cheaper and appreciating.

A1a: Say you start with a bunch of Euros. converting now (unfavorable) then deposit (must be favorable to compensate). So USD interest must be higher.
A1b: deposit (?) then convert (favorable). So the Eur deposit return must be lower to even up.

A1c: Say you start with a bunch of dollars. convert (economical) then deposit (must be unfavorable), so Eur deposit must be inferior
A1d: deposit (?) then convert (costly). So USD deposit return must be higher to compensate.

Conclusion — either deposit->convert or convert->deposit, the 2 legs must cancel out each other’s advantages.

Important observation — When forward points are ascending, FX rate is rising. Therefore first currency (the “silver”) appreciating. In such a context, first currency IR is lower than 2nd currency.

Intuitively, deposit->convert will even out since it’s unfavorable->favorable.

[1] If you see descending order like 12/11, then forward is lower than spot [2] i.e. First currency (the “silver”) is now expensive and depreciating. First currency IR must be higher than 2nd currency.

Intuitively, depost->convert is  favorable->unfavorable

[2] subtract points from spot bid/ask to get forward bid/ask.


Delete invokes pointee dtor [1] implicitly b_u_t dtor never implicitly calls delete.

[1] See P64 ARM.

I feel delete is a 2-stepper — destruction and reclaim. Reclaiming the heap space of the pointee, not any real estate outside the pointee.

“Reclaim” is more accurate than “free”. Reclaim means this real estate could belong to new objects. Even reading it could trigger disasters.

Now, suppose your object has a pointer field. You should program your dtor to call delete. Default dtor never calls delete. Dtor bulldozes the real estate of the host object. A 4-byte pointer lives on that real estate, but the pointee object lives somewhere on heap.

^ delete reclaims pointee’s heap space, but the 4-byte pointer is not reclaimed. People can still use this pointer field/stackVar, that’s why we need to set it to null.
^ in contrast, dtor bulldozes the 4-byte pointer field but doesn’t touch the heap real estate of the pointee.

For a smart pointer, dtor and operator delete are somewhat decoupled. “Coupled carefully” is how i put it. Smart pointer must carefully decide when to call operator delete.

At a high level, delete is responsible for reclaiming HEAP memory of a pointee; destructor is responsible for bulldozing real estate (stack or heap) of host object.

Another sound byte —
default dtor never calls delete on a ptr *field*;
default dtor implicitly calls dtor of fields and parents; P277 ARM.
container dtor implicit calls dtor of elements. See P36 eff STL