The old saying goes: When writing a conversion operator or a constructor that can be called with one argument, make it explicit by default.
By the way, according to comments from the author, the buggy compiler he used was C++ Builder, from Embarcadero, sigh.
- Performance is not efficiency. // ?? I still can’t get this clear in a programming context.
- Improve performance after having profiled your system.
- Make sure use of correct data structures and algorithms
- By default write code for maintainability.
- Know and use your libraries, unless your profiler showed them to have bad performance.
when implementing spinlock unlock: a simple atomic store is enough. no need for using a heavy CAS operation.
- test only new/delete (or malloc/free)
- use realistic statistic distributions; both for allocated sizes and for lifetime of allocated items
- access all memory at least once
all for emulating real-world uses.
- for cpu cycle test, every allocator is not too far from each other. each of them can outperform another one under certain conditions. benchmark is highly recommended when you decide to change your allocator.
- some allocators behave not so good in memory overhead, like Hoard.
lsoffor listing open files; while
netstatfor displaying network related information, like connections .etc
lsof has issues on locating half-closed sockets.
ptrace relates with linux process states.
SIGCONT to control a process’s state and parent process receives
SIGCHLD when child process state changes.