C++ concurrency learning curve has lower /leverage/ higher effort.
* well-established — Java is designed with concurrency at its core so its memory model is mature and sound. There are a few very well-respected books on java concurrency (and some secondary books). As a result, concurrency best practices are more established in java than arguably any other language as of 2017.
* templates — Many concurrency constructs use templates with possibly specializations.
* C — Java developers never need to deal with the system-level concurrency library (invariably in C), the c++ developer may need to descend to the C level.
* multiple libraries — See post on c++ concurrency libraries. https://bintanvictor.wordpress.com/2017/04/05/common-cconcurrency-libraries/
* Low-level — C++ is a lower-level language than java.
** The concurrency classes must deal with the big 4.
** Memory management also complicate concurrency.
** Not only heap objects, but primitives on the stack are also accessible from multiple threads thanks to pointers.
** The atomic class templates are also more low-level than java’s, and much harder to get right.
* There are many mutex constructs.
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.
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
Many of the topics are interviewers’ favorites. This is really my main focus and by itself enough of a justification to spend time on this book.
Most of the examples were tested on Windows and MSVS.
The long chapter on concurrency is reasonably practical to real projects.
Be ready to explain them in details
- smart pointers
- threading library
pimpl – adv/disadv
scripting support by boost::python
API wrapping/layering — extremely common technique
– flat C style
Has shorter, simpler treatment than [[effC++]]:
* placement new
* class-specific op-new
* restrict heap allocation of my class