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: 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 more like 50%.
  • –A #3: significantly simpler — java as a language, when we ignore the add-on packages.
  • –A #2: 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”.
    • 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: 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.
  • –A: 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;
  • 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 [[effectiveC++]] 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.)

Improving socket knowledge for IV

Background — The QQ/ZZ framework was first introduced in this post on c++ learning topics

Only c++ positions need socket knowledge. However, my perl/py/java experience with socket API is still relevant.

Socket is a low-level subject. Socket tough topics feel not as complex as concurrency, algorithms, probabilities, OO design, MOM … Interview is mostly knowledge test; but to do well in real projects, you probably need experience.

Coding practice? no need. Just read and blog.

Socket knowledge is seldom the #1 selection criteria for a given position, but could be #3. (In contrast, concurrency or algorithm skill could be #1.)

  • [ZZ] tweaking
  • [ZZ] exception handling in practice
  • —-Above topics are still worth studying to some extent—–
  • [QQ] tuning
  • [QQ] add basic reliability over UDP (many blog posts)
  • [QQ] how is TCP transmission control implemented
  • [QQ] select() multiplexing
  • [QQ] buffer management

 

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!