%%c++code keeps crash` I keep grow`stronger as c++hacker #Ashish

My current c++ project has high data volume, some business logic, some socket programming challenges, … and frequent crashes.

The truly enriching part are the crashes. Three months ago I was afraid of c++, largely because I was afraid of any crash.

Going back to 2015, I was also afraid of c++ build errors in VisualStudio and Makefiles, esp. those related to linkers and One-Definition-Rule, but I overcame most of that fear in 2015-2016. In contrast, crashes are harder to fix because 70% of the crashes come with no usable clue. If there’s a core file I may not be able to locate it. If I locate it, it may not have symbols. If it has symbols the crash site is usually in some classes unrelated to any classes that I wrote. I have since learned many lessons how to handle these crashes:
* I have a mental list like "10 common crash patterns"
* I have learned to focus on the 20% of codebase that are most convoluted, most important, most tricky and contribute most to debugging difficulties. I then invest my time strategically to rewrite (parts of) that 20% and dramatically simplify them. I managed to get familiar and confident with that 20%.

* I have learned to pick the most useful things to log, so they show a *pattern*. The crashes usually deviate from the patterns and are now easier to spot.

* I have developed my binary data dumper to show me the raw market data received, which often "cause" crashes.

* I have learned to use more assertions and a hell lot of other validations to confirm my program is not in some unexpected *state*.
* I figured out memset(), memcpy(), raw arrays are the most crash-prone constructs so I try to avoid them or at least build assertions around them.
* I also figured signed integers can become negative and don’t make sense in my case so I now use unsigned int exclusively.
* I also gained quite a bit of debugger (gdb) hands-on experience

Most of these lessons I picked up in debugging program crashes, so these crashes are the most enriching experience. I believe other c++ programs (including my previous jobs) don’t crash so often. I used to (and still do) curse the fragile framework I’m using, but now I also recognize these crashes are accelerating my growth as a c++ developer.


##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.


[[optimized c++]] with a slight win32 slant

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.


c^c++:SAME debugg`/trac`/instrumentation skills #ZZ

This skillset is more like C and less like java.  90% of the java/py/c/… “tough systems” I required the same code tracing.

See  ##transparent^semi-transparent^opaque languages



##boost modules USED ]finance n asked]IV

#1) shared_ptr (+ intrusive_ptr) — I feel more than half  (70%?) of the “finance” boost usage is here. I feel every architect who chooses boost will use shared_ptr
#2) boost thread
#3) hash tables

Gregory said bbg used shared_ptr, hash tables and function binders from boost

Overall, I feel these topics are mostly QQ types, frequently asked in IV (esp. those in bold) but not central to the language. I would put only smart pointers in my Tier 1 or Tier 2.

—— other modules used in my systems
* tuple
* regex
* noncopyable — for singletons
** private derivation
** prevents synthesized {op= and copier}, since base class is noncopyable.

* polymorphic_cast
* numeric_cast — mostly int types, also float types
* bind?
* scoped_ptr — as non-copyable [1] stackVar,
[1] different from auto_ptr


##some benefits@learning c++, even if no salary increase

  1. After learning c++, i am fairly confident I could if I must pick up c# in a few (4?) months and start passing interviews. C++ is inherently tougher than java and C#. Java and C# both have large libraries, but the core languages are significantly simpler/cleaner than c++.
  2. After learning C++, i have found python and perl easier to understand and master since both are written in C/C++. I now believe some people who claim they could pick up a new language in a few months. Those languages have their roots in C/C++.
    • The basic challenges of scope+namespace, object lifetime, heap/stack, pointers, memory allocation, object construction, pass-by-ref/value, arrays, function pointer, exceptions, nested struct+array+pointer… are faced by every language designer. Many of these challenges depend on basic library, which is invariably C.
    • The common OO challenges of inheritance, virtual, static/non-static, HAS-A/IS-A, constructor, downcast, … are faced by every OO language designer. Many of them borrow from java, which borrows from C++ and smalltalk
  3. threading — java remains the gold standard but c++ currency support is more complex, harder to understand and offers some low-level insight
  4. memory management — c++ offers insight into JVM and CLR
  5. c++ gave me other insight into java, esp. GC, JVM, overriding, references, heap/stack, sizeof, …

[[api design for c++]]

pimpl – adv/disadv

scripting support by boost::python

API wrapping/layering — extremely common technique

api styles:

– flat C style

– OO

– template


[[c++common knowledge]]

Has shorter, simpler treatment than [[effC++]]:

* placement new

* class-specific op-new

* restrict heap allocation of my class


##GTD topics for c++ coding practice

After I gain confidence with the basic tasks and move on to higher tasks, i frequently found gaping holes in my foundation. I then face a scary choice. If I admit and shift to the lower gear, I subconsciously feel fake and deeply disappointed with my progress — “after so many years, still at Level 1”. Well, truth is, even after 10 years of java (or c#, SQL or perl) most developers would lack some of the Level 1 skills, because they didn’t need to use them. Basics such as equals/hashCode, wait/notify, interrupt, most basic operations on threads, bigO of collection operations (basic), overriding vs overloading…

— Here are some __coding__ practice areas for GTD (not IV) improvement in c++:
* basic array, pointer/reference, free functions, func pointers. No classes. Plain C
* basic class inheritance, virtual function, new/delete, big3
* string manipulation? understated in books but heavily quizzed.
* basic IO using console and files
* consumption of existing templates. Vast majority of Wall St c++ teams don’t create templates (or design thread constructs). That’s the job of specialists in the bank.
* STL – basic and advanced.
* basic macros including assertion
* a lot of multi-unit compilation topics — much trickier than you think
* static
———-See separate blog posts on the most essential skills with STL

** containers are the real reason to use STL. Iterators and algos are reluctantly adopted.
** remove isn’t common. Add, lookup, find and interation are popular.
** …

–less quizzed
* basic operator overloading
* basic smart pointers