contents to keep in .C not .H file

1) Opening example — Suppose a constant SSN=123456789 is used in a1.cpp only. It is therefore a “local constant” and should be kept in a1.cpp not some .H file.  Reason?

The .H file may get included in some new .cpp file in the future. So we end up with multiple .cpp files dependent (at compile-time) on this .H file. Any change to the value or name of this SSN constant would require recompilation to not only a1.cpp but unnecessarily to other .cpp files 😦

2) #define and #include directives — should be kept in a1.cpp as much as possible, not .H files. This way, any change to  the directives would only require recompiling a1.cpp.

3) documentation comments — some of these documentations are subject to frequent change. If put in .H then any comment change would trigger recompilation of multiple .cpp files


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