In extreme cases, I combine templates and macros to achieve the desired conciseness of code. Templates are powerful, but often a lot of verbosity/boilerplate is still needed, where macros may come in. That is usually in a basic form as described in this article (one can do much more advanced stuff with macros e.g. google X macros).
Before becoming suitably annoyed at your preprocessor magic, which I will examine shortly, I would like to point out one example I had in the back of my mind when I wrote my comment: just google lttng/tracepoint.h. It just seems to me like a terrible hack.
Of course, if you want to criticize templates and meta-programming (as an alternative to pre-processor), there are many jaw-dropping examples in Boost, V8, etc. I can remember several late-night sessions wrangling with (Boost) serialization code, and the cryptic multi-level warnings that ensue. Those were bad times.
I always figured that the answer would be a language/tool simple enough that a serious programmer could, without heroic effort, manage to customize to his needs over a weekend.
Sadly, it appears that the language lawyers have gone insane, and the trend appears to be entirely opposite (with the recent developments in C++0x/C++11/C++14).
For background: I was a big fan of Visual Studio (when working in games and finance), but my most recent posting precludes developing in Windows, and then porting to Linux for deployment. Looks like most people (at this posting) are doing printf-programming, relying on logs to see what happened (in debug builds). It's hard (within our current heterogeneous environment) to setup gdbserver + Eclipse or some other gdb client on a Windows front-end (which we need for administrativia).
The point is I miss being able to just set breakpoints, launch the program and inspect program state on the fly, as a means of learning the behaviour.
I have cared enough about all this, and used to eagerly await the day that MS would open-source the C++ AST/Intellisense engine, opening the door for programmers being able to perform complexe refactorings with relative ease. Maybe I should just but the whole-tomato software, or some other tool. These days, I am following Clang developments with interest and hope.
FYI, I think the ultimate annoyance is some Linux fanboy who doesn't "believe" in C++ or IDEs, but who is too young to remember when GUIs were not even an option, that text mode was all you had. I am surprised at the resurgence in TUIs (and the longevity of some CLIs). Sure, C++ has its warts, but RAII is better than gotos (here, I am conflating the kernel developer's aversion to C++ with the likelyhood that he/she uses vi, or some other console-based editor).
Sorry for the confused monologue. I'll check out the code later.
Inspecting program behaviour via the debugger has always been an uphill battle in C/C++. Sometimes you're working on something where the bug only surfaces in release builds (because the debug build isn't optimised enough and the program runs too slowly to trigger it). Good luck debugging when half the function arguments read "optimised out" and program execution jumps around randomly because the compiler reordered your code for efficiency.
One thing I've always dreamed of is having the compiler emit source for the assembly it generated. So you can attach the debugger and see the code as it actually is, rather than as it was when you wrote it. I love how in Java my code gets optimised by the JIT, but once I start debugging all the optimisations come off (but only once I need to see the source) and what I see is what is running.
I see zero problem with using SSH, which happens to be a pretty secure protocol. In fact I would prefer it to HTTPS since it is not by default vulnerable to malicious CAs. Note for example that GitHub allows Git access over SSH.
When the author says that the system "exposes the private key", well, it's by design that the user can see it - since they need to use it to identify themselves to the SSH server. It's not much different from being assigned a password by the server. What could be improved is if it was transferred over HTTPS rather than HTTP, and of course also the install script.
(I only speak about the usage of SSH, it's possible that they still do something insecure..)
This has nothing to do with "accumulating crud", it's a trivial thing, there's probably less code needed to not treat 0.0.0.0 differently. Also, the amount of people who have ever typed 0.0.0.0 into a browser is so small that it is virtually irrelevant what they do, and whether there is consistency between browsers.
But this is treating 0.0.0.0 differently. Did you not read the bug report, or the comments here, or anything? 0.0.0.0 is not a valid address. In fact, navigating to 127.0.0.1 when 0.0.0.0 is given in the URL is neither expected nor desirable.
Just don't sign in? I don't feel being pushed into anything. If you're annoyed by that new button near the window management buttons, there's a chrome:flags thing to disable it (enable the new avatar).