decorating a c++ class to add converters

In java, i usually extend a bean class B to add data fields.

When using STL (P203 [[STL tutorial and ref]]), we often subclass a basic data class just to add conversion features. You can do the same using has-a decoration.

In STL, data classes need converters more often than in java. Java is more strict, more orthogonal — there’s often just one right way to do something. Perl, javascript and c++ data manipulation is more flexible. —————-}  Therefore more conversion is needed and implicit.

adapters for STL 1) container 2) iterator and 3) functor

You know the STL planet has (at least) 3 continents — containers + iterators + algorithm. Now, most of these have adapters.
1) Container adapter? Obvious!
2) iterator adapter? simplest example is back_inserter.
(How about reverse_iterator? I think so.)
3) functor adapter? simplest example is bind1st() and bind2nd()
The adapter not2() is actually quite simple but understand not1() first.
4) algorithms? I don’t think algorithms have adapters because
…algorithms aren’t objects!
5) allocators? I don’t think so.

OutOfMemory retry loop of "new" (c++

We know c++ keeps retrying when a “new” operation encounters OOM condition (no such exception in c++ actually)

Q: what are the very few (therefore important) ways to break out of the loop?
A1: more memory becomes available and retry succeeds
A1a: new-handler releases a secret “stash” of memory
A1b: install a more resourceful new-handler, which releases some special memory block

A2: new-handler turns out null -> std::bad_alloc -> abort()
A2a: set new-handler to null
A2b: directly throw bad_alloc and pass on the hot potato
A2c: directly call abort()

short term influences on FX rate – ML perspective

* (Above all, IR has the most direct impact on FX rate, at least in the short/mid term.)

* Positions in the FX futures and options market — For eg, high volumes around contract expiry dates can move FX rates
* Activities in the FX options market — for eg, large orders as a result of option excise can move spot prices.
* Fund manager activities — they can move in/out of Euro zone or America. Look at international portfolio managers, not small investors. If these managers want to trade and hedge globally and diversify the portfolio, then they need to invest not only in the domestic market but markets denominated in other currencies. They need FX as a means to an end. They must pay the FX transaction fee. In this sense, I believe FX importance and value-add is smaller than Eq and FI, but it does grow.
* Stock market — a country’s currency rises with its stock market
* commodity prices

What derivatives might be curtailed by post-2008 regulations

(A foolhardy prediction by a greenhorn…)

These are the potential casualty but in reality, i don’t know if any of these were curtailed.

IRS – set to grow further, across continents. I don’t think will be curtailed.

Listed derivatives — are all safe and may grow further.

Reasons/justifications for the tighter regulation include —
– systemic failure
– contagion of default, domino effect
– [tv] obstacle to risk assessment
– [v] poor liquidity
– [t] unreliable credit rating

Underlying “defects” in the product set-up —
[t = poor transparency]
[v = opaque pricing, disparate valuations]

ifstream /with-f/ and istream — typedef specializations revealed

Background — “cin” is an instance of istream (no “f”); whereas ifstream is the most common file input utility.

“istream is a specialization (not a template instantiation) of the class template basic_istream” — many people say that but if the generic template is named “basic_istream” a specialization can’t have a different name! When you look at the code you realize it’s yet another typedef —

typedef basic_istream istream

Therefore, istream is an alias to a specialized basic_istream.

Now back to basics. Stripping layers of typedef and template specialization, the core structure is

———> basic_ifstream extends basic_istream extends ….

-) ifstream is a typedef of a specialization of basic_ifstream
-) istream is a typedef of a specialization of basic_istream

typedef basic_istream istream;
typedef basic_ifstream ifstream;

stronger]Perl than java though i spent more years]java (theory^GTD)

Q: what elements make me Feel strong in c# or c++ or perl…?
A21: passing a large number of non-trivial interviews
A36: discussion with veterans. Can follow. Can contribute.
A78: help veterans solve problems
A96: independently solve non-trivial problems (colleagues couldn’t help you solve)
A01: hands-on skill with the tough and core parts of the language, like threading, generics, Reflection …
A10: tools, tools and tools

Q: what elements make me Look strong in c# or c++ or perl…?
A63: track record – a wide range of non-trivial mainstream projects, often with substantial (or impressive) volume and performance
A81: certification or the type of knowledge therein
A56: insight into strange errors that other veterans don’t dig into

For c#, I have A36, A01, A96
For java, I can improve A78, A10
In any programming language there’s a body of abstract theory (including design principles, language features…) on one hand, and practical how-to on the other hand. I’m a theory guy meaning I understand theory faster. Practical on-the-ground problem solving skill is ….mediocre.

Now, Why am I stronger in Perl than java even though I spent more years writing java? Here’s my new answer — I understand java fundamentals better than Perl fundamentals; but I know more Perl how-to than java how-to. Most practical Perl problems I can resolve faster than others. (Well, not many people spent that many years using Perl.) I have worked with many Perl developers and many of them tell me I know a lot of little tricks.

Here’s one example of a killer java skill — Multithreading is the most complex part of java (followed by generics and reflection, IMO). Complex in the JVM ie “theory”. In practice, app developers stick to code idioms and proven constructs. These “best practices” shield programmers from the underlying complexities. If you know some of these “best practices”, then you don’t need a deep understanding of the JVM internals. What I just said is all within my comfort zone. However, when threads meet swing, messaging, distributed cache, app servers…, we are challenged. Not much theory. Just a lot of code on the ground. You need resourceful, quick problem solvers. Good understanding of java fundamentals can help to some extent.

Another example – eclipse IDE. Never tested in interviews. No theory. But can really make a programmer so much faster or slower.