I can't get the index page now. Sorry, I think the traffic from HN may have killed it. :(
950 karma · joined May 25, 2010
Not sure if you are aware of this, but if you are not entitled to Medicare, you are exempt from paying Medicare levy (and surcharge), which the rest of the residents do have to pay. Though, you have to get it back with tax refund at the end of the financial year (it is paid with PAYG taxes) after you apply for a letter from Medicare that you weren't eligible.
Private hospital insurance should cost you about the same per year, so it's a fair arrangement, I think.
http://www.commandlinefu.com/commands/browse/sort-by-votes
Most of my time savers that I've never thought of were found there.
GCC: http://gcc.gnu.org/projects/cxx0x.html
Clang: http://clang.llvm.org/cxx_status.html (currently down)
MSVC: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...
Notably lacking in current production versions:
1. explicit overrides in GCC
2. lambdas in Clang
3. Variadic templates, range loop in MSVC
A few examples:
1. Implicit lambdas ("[=]") capture "this" pointer for data members, if you capture a shared pointer and let the lambda object leave the scope, the shared pointer won't be copied (http://stackoverflow.com/q/7764564/23643), which may create unpleasant results, like code blowing up in your face.
2. Overuse of "auto" (not exclusive to C++) may make the code harder to read, especially if storing a result returned from a function. You can't tell if the return value is a smart pointer or a raw pointer, value or a reference, so you can't figure ownership semantics just by looking at the local code.
3. Move constructors/assignment operators are a bit of a black magic, especially with regard to suppressing default implementation (http://mmocny.wordpress.com/2010/12/09/implicit-move-wont-go) and exception safety (http://cpp-next.com/archive/2009/10/exceptionally-moving). I would refrain from using it, until I fully understand it.
With that said, most of C++11 is a welcome change and makes C++ more pleasant to write, but, as always, you have to have your guard up and use new features judiciously.
By conflating "its" and "it's", you are overloading the meaning of "its", making the language more ambiguous.
Perhaps this also has to do with me being accustomed to more formal (programming) languages.
In fact, if you are learning C++, you better start it as a new language, rather than a tumor grown on the side of C. These languages are too idiomatically different.
I can't comment on the RFC part of your comment.
I admit, the main reason for me to develop in Vim these days is to simply minimize the number of keystrokes I have to press (and the number of times I have to reach for the mouse), because, due to RSI, I experience a mild, but constant, and noticeable discomfort in my wrists (...and triceps, and shoulder) whenever I type (I distinctly remember I developed it in Eclipse during my Symbian C++ development internship). I honestly tried Emacs a few times because of superior Lisp editing, but it just didn't stick, I just can't bring myself to press more keys than I use to in Vim. Force of habit? Maybe.
I have never expected to be "hooked up" on Vim, but I was. In my first job out of the university I was writing Linux-based embedded software almost exclusively. I could never get used to Linux GUI editors after Visual Studio: the lack of any built-in IDE features and constant switching from the editor to the shell made me switch away to something closer to the shell. The initial discomfort of modal editing was less annoying than the lack of features and the accessibility of shell in Linux GUI editors (Eclipse CDT was a pain to set up and use back in these days). Then the discovery of split windows, regex replacement, folds, macros, ex-mode commands, and extensions made my experience what I then thought tolerable.
The mechanical memory had set in, and, upon moving on to my next job, I discovered that I could no longer use Visual Studio with as much comfort as I used Vim! It was curious, since I've "grown up" as a programmer with Visual Studio in the 4 years at the university.
It has snowballed further since then: remapping ';' to ':', ZQ and ZZ shortcuts, quickfix window, copy-paste registers, more motions with text objects ("delete between {}", "move to next ','", replace "()" with "[]", indent 4 line with "4>>"), sorting selected lines, coming up simple with ad-hoc refactoring functions and macros on the fly, marks, buffer greps, jumping between files with LustyExplorer an NERDTree, plugins (VimScript must die, but while it's there, it does the job), and falling back to the shell where Vim falls short. A few vimgolf (there is a site for this) challenges also added some tricks into my toolbox.
Right now I use Vim whenever I can. It does show its age, especially in areas like REPL, IDE features and code completion (it'll get there, eventually, I hope), but I just don't feel at home using anything else at the moment. I'm always on the lookout on the future of Vim or its next successor.
PS: Disclaimer: I don't necessarily advocate for everyone to learn Vim, it really requires a non-trivial investment of time to establish the necessary mechanical memory, but it was worth it for me personally (I do C, C++ and Python almost exclusively). Depending on your domain and the technology you use, you may be better off using Emacs (Lisp) or VS with Resharper (C#).
98% chance of default makes them essentially expensive lottery tickets at this point.
I'd also like some more build system integration hooks (e.g. provide project-specific include dirs and CXXFLAGS on a per-file basis).
1. ABI is a set of rules for interaction between multiple code units (functions, translation units, libraries) running sequentially and calling each other, e.g. how arguments are passed to the functions, how return values are passed back, how exceptions are thrown and handled.
2. Memory model is a set of rules for interaction between multiple (potentially) concurrently running threads, e.g. how a compiler can reorder load/store instructions to main memory, which operations imply memory barriers.
C++, for all intents and purposes, supported multithreading before C++11 via extensions and libraries that are vaguely similar to each other on different platforms, but you can never be sure that your multithreaded code will work when ported to another platform (see "volatile" keyword semantics in standard C++ as opposed to MSVC).
But now,
1. it's officially mandated, and
2. you have more tools in your concurrency toolbox (for example, compiler-independent atomic variables with the ability to fine-tune memory order).
I'd love someone with the experience of building compilers to chime in.
This was my problem when I started with Vim. But then I learned to love GDB and other command-line development tools. At first it seemed a bit archaic to me, a Visual Studio user at the time, but when I got a hang of it, I stopped missing IDE debugging. Now I'm at the point where I feel crippled trying to develop in an IDE (no split windows, to vim-style macros, inefficient use of screen space, constantly have to switch between mouse and keyboard).
For example, GDB can be scripted, so you can repeat debugging sessions, your entire debugging session is printed, so you can always go back and see the history of changed values. It supports pretty-printing STL containers and you can add your own pretty-printers in python.
There are a lot more to these tools than you can discover by poking and trying things like you would with an IDE, they have a steeper learning curve, but I wouldn't dismiss them immediately as a waste of time.
But then I learn that not all compilers behave exactly the same way, or implement only a subset of a standard for a variety of reasons (every compiler would implement different subsets), and I return full circle back to experimentation with individual implementations.
- get(): auto_ptr retains the ownership
- release(): auto_ptr loses the ownership
1. Extensive use of asserts in release builds terrifies me. It's meant to check for conditions that shouldn't happen, but I see users complaining about their apps aborting with assertion failures on ZMQ mailing lists and it comes up fairly frequently in Google. There are a fair bit of asserts for error codes returned from system calls. I don't want a critical process crash because I've used library in a wrong way in a completely different part of the application.
2. Only in 2.1 they've fixed the problem where some messages would not be flushed and be lost if you terminate the process too early. This seems like a fairly common bug for younger projects. Recommended workaround is... calling "sleep" before you exit, which is one of the deadly sins of multithreaded programming! This and above point convinces me that ZMQ isn't as mature enough for me to be comfortable with.
3. Transparent reconnection is good, but some of our applications need to quickly detect that other nodes in the system are missing, which forces me to implement off-band heartbeat mechanism.
4. Threading model seems a bit awkward to me (last I checked). First of all, let me state that I personally believe that a library starting threads behind your back is a Bad Thing (unless it's a framework). ZMQ uses a sender thread that you queue your messages into, yet it forces you to dispatch your receive loop by either blocking read or zmq_poll. If it already starts threads by itself, why not provide a callback?
5. Not really a problem, but a missing feature: no way to demultiplex messages from a stream of messages, so you have to implement it yourself. You can subscribe to a subset of messages on a socket, but can't subscribe to multiple subsets from a single socket.
I can't edit my post anymore, but I remembered that there is a similarly named site for command line tricks: