unique_ptr and move()

When I use a unique_ptr instance, I frequently copy it around. Unique_ptr ‘s copying is actual moving.

The are different ways to code it.

  • sometimes you need to use someFunc(move(myUniquePtr));
  • sometimes you can omit move() and the semantics remain the same.

http://stackoverflow.com/questions/9827183/why-am-i-allowed-to-copy-unique-ptr has some examples. Note none of the functions have a parameter/return type showing “&&”. That’s because there is pbclone in play. The copying uses the move-constructor, which does have a && parameter.

I think some developers simply copy sample working code, without understanding why, like an ape. Some use threading constructs the same way. Nothing shame. I feel interviewers are interested in your understanding.

##10c++coding habits to optimize perf

Many of these suggestions are based on [[optimized c++]]

· #1 Habit – in c++ at least, ++counter performance is strictly “better or equal to” counter++. If there’s no compelling reason, I would prefer the former.

· #2 Habit – in a for loop, one of the beginning and ending values is more expensive to evaluate. Choose the more expensive one as the beginning value, so you don’t evaluate it over and over. Some people object that compiler can cache the more expensive end value, but 2016 tests show otherwise.

· If a method can be static, then make it static. Good for performance and semantics.

· For a small if-else-if block, put the most likely scenario first. May affect readability. Worthwhile only in a hot spot.

· For a long if-elif-elif-elif-elif block, a switch statement performance is strictly “greater or equal”

· For-loop starts by checking the condition (2nd component in header). If this initial check is redundant (as often is), then use a do-while loop

· Call a loop in a function, rather than call a function in a loop. Another micro-optimization.

%%c++IV weaker cf java#2017introspection

https://bintanvictor.wordpress.com/2017/04/02/c-and-java-iv-tend-to-beat-us-in-2-ways-high-end/ shows my self-rating in job interviews for c++ vs java. (For real projects, I think the gap between my c++ and java is slightly smaller.)

I did spend lots of time reading and blogging about c++, not less than java, so

Q: why the persistent gap in my QQ IV performance?

  • –A #1: biggest reason — I feel a disproportionate number of my c++ interviews come from high end teams, They go slightly more low-level than my java interviews. Imagine if I get more high end java interviews from the likes of Millennium, HSBC … I feel most (like 80%) of the java jobs in finance are “regular”; for c++, it’s below 50%. See the post on the c++ job offers I received.
    • If I avoid the high-end jobs, then my batting average will probably increase significantly.
  • –A #3: [QQ] significantly simpler in terms of QQ — java as a language, when we ignore the add-on packages.
  • –A #2: [QQ] Some of these interviewers basically treat c++ as a wrapper over C. In contrast, Java insulates you in a pure-java world on the Virtual Machine, so you don’t need to deal with the messy “borders” as c# and c++ developers do. A lot of the tough C++ IV questions are about
    • linux,
    • [C] sockets,
    • [C] *alloc function, memory leak detectors
    • [C] IPC
    • [C] other command line developer tools … mostly designed for the “system programmer”.
  • –A: [QQ] STL containers — is much more complicated than java containers in job interviews, even if we ignore iterators, stl algorithms.
    • I spent more time studying STL than java collections but always failed to impress interviewers.
    • eg: in java container of T is always implicitly container of well-managed pointer  to T
  • –A: [QQ] halos — in my “java show” include threading, collections, GC tuning … which make up for my weaknesses. No such halo in my “c++ show” I guess some people have a halo in templates, memory mgmt, shared_ptr, threading…
  • –A: unable to describe c++ projects.
  • Suggestion: Start from this blog and my books. Focus on a small subset of core topics in c++, /burn through/ the essential literature and develop a first halo —
    1. smart pointers (beyond shared_ptr)
      1. usage in big5
      2. usage in containers
    2. data structures in STL and boost, including c-str life-cycle management excluding the str* functions
    3. traditional big 3(dtor,op=, copier) but not rvr and move-semantic
    4. pbclone^pbref but not return-value-optimization
    5. const
    6. vptr, slicing, dynamic_cast
  • (Note this is all about QQ book knowledge, not coding skill!)
  • suggestion: secondary focus topics —
    1. c++11 threading
    2. heap memory management;
    3. socket tweaking;
    4. interface classes, pure virtual;
    5. design patterns
  • suggestion: continue to ignore some of the high complexity low leverage topics such as move semantics; iterators; const-correctedness; singleton; design patterns; operator overload … and many [[effC++]] topics

socket lingering briefly after host process exits

[[tcp/ip sockets in C]] P159 points out that after a host process exits, the socket enters the TIME_WAIT state for some time, visible in netstat.

Problem is, the socket still binds to some address:port, so if a new socket were to attempt bind() to the same it might fail. The exact rule is possibly more complicated but it does happen.

The book mentions 2 solutions:

  1. wait for the dying socket to exit TIME_WAIT. After I kill the process, I have seen this lingering for about a minute then disappearing.
  2. new socket to specify SO_REUSEADDR.

There are some simple rules about SO_REUSEADDR, so the new socket must be distinct from the existing socket in at least one of the 4 fields. Otherwise the selection rule in this post would have been buggy.

(server)promiscuous socket^connected socket

[[tcp/ip sockets in C]] P100 has a diagram showing that an incoming packet will be matched against multiple candidate listening sockets:

  • format: {local address:local port / remote address:remote port}
  • Socket 0: { *:99/*:*}
  • Socket 1: {10.1.2.3:99/*:*}
  • Socket 2: {192.168.3.2:99/ 172.1.2.3:30001} — this one has the remote address:port populated because it’s an Established connection)

An incoming packet need to match all fields otherwise it’s rejected.

However it could find multiple candidate sockets. Socket 0 is very “promiscuous”. The rule (described in the book) is — the more wild cards, the less likely selected.

(Each packet must be delivered to at most 1 socket as far as I know.)

IV^CV is real battle

(Adapted from a Mar 2017 letter to Lisa Wang… )Let me share my observations and reflections on this tough job hunt. Another stock-taking. Focus here is non-finance jobs in the U.S.

For months I used a slightly tweaked CV for non-banking (“main street”) tech positions, but it’s not working — Out of the 30 to 40 non-finance positions I applied, precious few (15%??) recruiters were interested. Suppose 5 recruiters showed interest, I guess not all of them submitted my resume. Suppose 4 did submit. So far, no hiring manager was impressed with my non-finance CV. (Response from financial firms are better but not my focus today.)

So different from my prime time (from 2010 to 2012) when my finance-oriented resume was selling like a hot cake. I would estimate more than 50% of the recruiters were impressed and many hiring managers showed interest.

Of course, I’m comparing my “main street” resume against my Wall-St resume. Not a fair comparison but it does highlight these key issues:

Recruiter engagement is the #1 issue and hiring manager engagement is #2 issue. Interview competence is a distant #3 and not a key issue. Many people disagree — “you need no more than one successful interview.” They believe a 50-80% interview success rate is the silver bullet needed. Well, how long must you wait before you fire your silver bullet?

I feel much better if my interview pass rate is only 20% (or 10%), but I get 5 times more interviews! I learned from experience that my interview performance improvement is limited without sufficient interviews. So it’s far more effective and strategic to work on getting more interviews. I don’t want to be one of those guys who need 6 months to find a job. I see them starved of oxygen. Steady flow of interviews keep me motivated and focused, too.

In conclusion the key issue is crafting a compelling resume to engage recruiters and hiring managers. (A more pressing issue on main-street front than on the Wall-st front.)

Therefore, I count each interview scheduled as a success. In contrast, an offer is less significant an achievement. Analogies:
* as a singer, each TV appearance is a success; Winning a singing contest is less significant.
* as a growing basketballer, each time I get to play on court is a success; winning a game is less significant.

I have always told my peers that 90% of the job candidate competition is on the resume, and 10% on interviews. (Now I feel 95%/5%) Many candidates can pass interviews if given the chance. The chance is given to winning resumes. I say this to my friends because I learned from experience to invest much more effort improving the resume, until it can impress a large percentage of recruiters and hiring managers.

For the “main street” positions, I hope to engage 33% of the recruiters and 10% of the hiring managers. With that, if I were to try 30 opportunities, I could expect to get 3 interviews!

condition.signalAll Usually requires locking

Across languages,

  • notify() doesn’t strictly need the lock;
  • wait() always requires the lock.
    • c++ wait() takes the lock as argument
    • old jdk uses the same object as lock and conditionVar
    • jdk5 makes the lock beget the conditionVar

—- original jdk
100% — notify() must be called within synchronized block, otherwise exception. See https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#notify()

—- jdk 5 onwards
99% — https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html#signal() says that An implementation may (and typically does) require the lock acquired by the notifying thread.

Not 100% strict.

— compare await():
100% — On the same page, the await() javadoc is 100% strict on this requirement!

====c++
0% — notify_all() method does NOT require holding the lock.  See http://en.cppreference.com/w/cpp/thread/condition_variable/notify_all

–compare wait()
100% — wait(myLock) requires a lock as argument!

====c#
100% — Similar to old JDK, the notifying thread must hold the lock. See https://msdn.microsoft.com/en-us/library/system.threading.monitor.pulseall(v=vs.110).aspx

 

std::lock_guard simple idiom]coding IV

Since this data type is designed as a stack object i.e. scoped variable, simply declare (and initialize) this object within curly brackets. When this variable goes out of scope, the object behind the variable gets destructed.

In fact, the compiler sets up this sequence of events.

{
std::lock_guard<std::mutex> aLocalLock(sharedMutex);
someMutableShared ++;
}