q[static thread_local ] in %%production code

static thread_local std::vector<std::vector<std::string>> allFills; // I have this in my CRAB codebase, running in production.

Justification — In this scenario, data is populated on every SOAP request, so keeping them as non-static data members is doable but considered pollutive.

How about static field? I used to think it’s thread-safe …

When thread_local is applied to a variable of block scope, the storage-class-specifier static is implied if it does not appear explicitly. In my code I make it explicit.

error stack trace: j^c++

Without stack trace, silent crashes are practically intractable.

In my java and python /career/ (I think c# as well) , exceptions always generate a console stack trace. The only time it didn’t happen was a Barclays JNI library written in c++..

In c++, getting the stack trace is harder.

  • when I used the ETSFlowAsert() construct I get a barely usable stack trace, with function names, without line numbers
  • [[safeC++]] described a technique to generate a simple stack trace with some line numbers but I have never tried it
  • the standard assert() macro doesn’t generate stack trace
  • In RTS and mvea, memory access errors lead to seg-fault and core dump. In these contexts we are lucky because the runtime environment (host OS, standard library, seg-fault signal handler ..) cooperate to dump some raw data into the core file, but it’s not as reliable as the JVM runtime … Here are some of the obstacles:
    • core files may be suppressed
    • To actually make out this information, we need gdb + a debug build of the binary with debug symbols.
    • it can take half an hour to load the debug symbols
    • My blogpost %%first core dump gdb session describes how much trouble and time is involved to see the function names in the stack trace.


pass in func name^func ptr^functor object

Let’s set the stage — you can either pass in a function name (like myFunc), or a ptr to function (&myFunc) or a functor object. The functor is recommended even though it involves more typing. Justification — inlining. I remember a top c++ expert said so.

I believe “myFunc” is implicitly converted to & myFunc by compiler, so these two forms are equivalent.


##c++dev tools for GTD+zbs

The primary tool chain (IDE, gcc, gdb…) often provides similar features. Therefore, some of these are no longer needed.

  • c++filt
  • [so] ctags, cxref, cflow
  • depend and cppdepend
  • [s] lint — outdated and no longer popular
  • [x] prof/gprof
  • [x] valgrind
  • [o] nm and objdump
  • [s=works on source files]
  • [o=works on object files]
  • [x=works on executables only]

##some c++REAL productivity skills seldom covered by IV

pre-processor tricks
debugger — graphical or command line
remote debugging
(quick) navigating manpages
gcc (troubleshooting) command line
make (troubleshooting)
linker (troubleshooting)
core dump analysis — not too tough. Just know the basics
memory leak detection
scripting to automate dev-related processes to minimize mistakes and avoid rerunning something 30 times mannually.
text processing to analyze input/output text files and logs

With debugging c++ or others, I think many times you don’t need in-depth knowledge. Many of these tools have the intelligence to probe the runtime/binary and extract insightful data, often presented in a mountain of ascii text (at least human readable:). You just need to search and search in it.

Often one tool is unable to extract some critical data on one platform but another tool works better. You don’t really need to know in-depth though it often pays to be a bit curious. Just keep trying different tricks until you find a break through.

returning handle to class internal data #effC++

Never quizzed in QQ, but how about BP? Might be a code smell.

Since c++ compiler is permissive and assumes you know what you wrote I believe it will compile.

Returning a handle (ref/ptr) to a class’s internal data is an everyday reality and inevitable, but tricky (– like online shopping) [[EffC++]] has a nice chapter /devoted/ to this topic. I don’t have the book now so here are my personal views.

Note — in contrast returning by value (pbclone) is safe.

java programmers feel safe to return “internal data”. I know from experience it’s seldom an issue. Therefore most of those c++ issues below are somehow “fixed” in java, largely because java is a simple_clean language, compared to the other 2 superpowers — C# and c++.

Issue: java immutable classes should not expose fields (except final primitives??). Ditto for c++, but more fine prints … C++ immutable is almost impossible. Constness can be cast away. A double-pointer field… (Java “final myField” means a field of either const-object or const-pointer to non-const object)

Issue: if an object is const or a method is const, then exposing that handle can break that “promise”. Apparently, c++ compiler can’t detect the “leak”. Java doesn’t make this kind of const “promise”

Issue: Once a handle is returned and “cached”, the original object had better (but often can’t) stay clear of the bulldozer, either on the stack or the heap. Fixed in java…(obviously)

Issue (java too): if a field is an integral and inseparable half of a pair which must be manipulated as a whole, then exposing the field alone is questionable. (Let’s not go into details) Any example?

non-trivial financial data structure in C/C++

Use a struct to represent an umbrella object like an IRS contract. One of the members could be another struct for a schedule. In this case the inner struct is embedded physically in the umbrella struct’s memory footprint. Size of the umbrella includes the inner struct. I believe this is like C# value type. No such thing in java.

You can also use pointer to link the 2 structs, in the java HAS-A fashion. Size of the umbrella object could be smaller than the nested struct.

I think in some cases boost::tuple might be more manageable and more productive.

Note STL is not mentioned!