"Training a monkey would be easier"

TL;DR: Here’s some code to integrate system commands into vim. You can just drop it in your vimrc, create a small wrapper function in your vimrc and configure a few key binding to make it work.

Longer version:
We can extend our quick grep integration to other commands, quite easily. Since we defined a few wrappers to request input, get it from visual mode or just guess it, we can also have a helper function to create a scratch buffer and read a system command into it:

If you have a function that you use a lot, you may find it interesting to use a custom command for it. Try this:

:command Foo echo('Hola!')

Now invoke the command with ‘:Foo’ and Vim should say hello. Neat, huh? This is especially useful (and dangerous) when combined with cabbrev, like this:

:command! Foobar echo('Nope!')
:cabbrev close Foobar

If you try to :close a document, Vim will now say “Nope!”. Other than using this to mess with someone’s Vim session, you can replace builtin commands with your own tweaked functions. I tend to use that quite frequently in my own .vimrc.

Hacking away on a little side project of mine, I found myself checking Stack Overflow for implementation tips about things I don’t usually work with. Android UI stuff, mostly, which apparently is a very dynamic and ever changing ecosystem. After more than a few wasted hours, I noticed a worrying trend: in SO, answers tend to age horribly. If you are looking for “How to do X in platform Y”, you may find a 4 year old answer that solves the problem, but only for platform Y, version “ancient”.

Information ageing is quite a problem on its own. The answer is still valid, and, for people working on that specific platform, probably relevant. This will make it the first answer, leaving a lot of people (like myself) frustrated because the solution won’t work in newer platforms. Is there a solution? Implement some kind of ageing time-window for information? Make the date a more prominent search parameter? Explicitly specify your platform and environment’s version when asking a question? I have no idea.

While Stack Overflow seems to exacerbate the issue, this is a problem even for products with a company actively maintaining their documentation. A very annoying example; looking for ways to manage the media key I ended up in a page which (as of August 2016) points to a very outdated API (registerMediaButtonEventReceiver, in case you are wondering). If even Google encounters problems when managing documentation ageing for their own products, what can we expect of people like us, who only have a tiny fraction of that budget?

While I try to keep this blog to (more or less) original content I write, I liked this quote from the Embedded Muse so much that I had to steal it:

Norm Augustine, retired chairman and CEO of Lockheed Martin, wrote a book called Augustine’s Laws that documents observations he made as a government contractor. One of those was that by the year 2054 the entire US defense budget would buy just one aircraft, due to their spiraling costs. In the May 9-22, 2016 issue of Aviation Week and Space Technology (often called Aviation Leak and Secret Technology due to their outing of many programs) he wrote this revealing statement:

“Another law from the 1960s used historical data, fearlessly extrapolated, to show than an ever-increasing fraction of an aircraft’s weight was being devoured by electronics and in 2015 would leave no room for pilots. Thus, we have today’s dilemma wherein pilots must remain in Nevada while their aircraft burn holes in the sky all around the planet. The Wright Brother surely are doing barrel rolls in their graves.

“Of course, some observers have questioned how, as these laws seem to imply, it would be possible to endlessly add cost to an aircraft when nothing more can be added to an aircraft’s weight, not even a pilot. To do this would require a colorless, odorless, weightless substance whose cost – like entropy – would continue to increase forever. Fortunately, the industry’s engineers were up to the task: the elusive substance is software.”

I spent some time writing utility scripts for my Vim setup. I figured I can share them here, someone may even find them useful or at least get a laugh out of it. Last time I presented “Impl switcher”, and “Better Tab New” before that. Today it’s Findgrep & Fastgrep’s turn.

I wrote about Fastgrep a long time ago. The idea behind it is to speed up the slowest part in a grep command, the disk seek time, by creating a huge blob file with all the files in a project concatenated.

Fastgrep works great. But it requires a context switch, going from your IDE to your console just to grep. Findgrep fills the gap between the IDE and the command line: this utility provides a few key bindings to let you quickly run some common commands, like searching for a selected string or finding a file in the project directory.

I spent some time writing utility scripts for my Vim setup. I figured I can share them here, someone may even find them useful or at least get a laugh out of it. Last time I presented “BTN: Better Tab New“. Today it’s the turn for “Impl switcher”.

With its very imaginative name, “Impl switcher” has a very obvious purpose: it will just switch from a header file to an implementation file. So, between .h and .cpp. Surely there are lots of Vim plugins to do just that, why write another one?

Most impl-switcher plugins in the wild tend to, in my experience, require either a lot of configuration, a lot of dependencies, or a very specific project layout (or a combination of all three). They also seem to be huge and very complicated projects.

Impl switcher will recursively go up your directory hierarchy and use “find” to locate any files named like your base file but with a different extension. That makes it very simple and it requires minimal (if any) configuration: just drop it in your .vimrc file and you’re good to go. OK, not exactly: it requires a Linux-like system with utilities like “find”. Still, a good trade-off to keep the project’s dependencies as small as possible.

I spent some time writing utility scripts for my Vim setup. I figured I can share them here, someone may even find them useful or at least get a laugh out of it. The first one is called “Better Tab New” and you can get it from my Gihub repo or from the script’s Vim page.

Why would you want a better tab new, and what’s wrong with the default one? Simple: tabnew, in Vim, will just open a file. For that to happen you need to specify the exact path of a file. That’s usually perfectly fine, but sometimes you need tabnew to be a bit smarter: maybe you just grep’ed something and ended up with a path that looks like “/foo/bar/baz:my_text:42”. Or maybe you want to open a file and go to a specific line. Those are things for which the default tabnew implementation isn’t very good. BTN fills that niche and lets you create a simpler workflow when using grep.

Ahh, shared pointers! A nice, magical pointer type that will make all of your memory problems go away. Sprinkle some shared_ptrs here and there and, voilà, Valgrind is now happy. Sounds like a silver bullet, doesn’t it? That should be your first clue that something’s up with the promise of getting Java-like memory management in your c++ application.

Java and C(++) have a very different concept of memory management. My Java-foo, obviously enough to anyone reading this blog, is not that great, but, from experience, memory management is seen as a chore better left to the bowels of your system, something you don’t need (nor want) to care about. Sure, you can tweak and somewhat manage memory allocations if you really want to; the default mindset, however, is to ignore those concerns. The garbage collector will, eventually, find any unused resource and deal with it accordingly.

C++ programs, at least those that have been more or less successfully designed as opposed to organically grown, tend to have a radically different approach. Memory management is an integral part of a program’s design and it can’t be left to some automagic memory manager. This leads, again, for those more or less successful designs, to programs with a tree-like hierarchy in which a child or dependent object must live at least as long as its parent scope. This hierarchy leads to easier to understand programs. Some idioms (RAII!) depend on this hierarchy. Some tools (like scoped and unique pointers) make its implementation much simpler. I’ve seen that Rust really builds on this idea (and seems to take it to 11! I’m still trying to figure out if that’s a good or a bad thing, but so far I quite like it).

The tree-like structure of the scopes in C++ also implies single ownership (again something Rust seems to be very idiosyncratic about). While you may “use” someone else’s objects (for example, via a reference) there is always one single owner. If this owner goes away while someone holds a reference to one of its children… well, you get a bug. But sure enough this bug is clear as long as you can visualize the tree scope structure of your program. Shared pointers completely obliterate this tree.

A shared pointer means an object can have multiple owners. Whoever goes out of scope last needs to clean it. Why is that bad? In my (highly subjective but experience based) opinion:

It becomes harder to reason about your program. You never know if all the “pieces” you need are in scope. Is an object already initialized? Who is responsible for building it? If you call a method with side effects, will any of the other owners be affected by it?

It becomes harder to predict whether going out of scope is trivial, or an operation that can take a minute. If you’re the last one holding a reference to an object through a shared pointer, you may be stuck running its destructor for a long time. That’s not necessarily a bad thing, but not being able to predict it can lead to all sort of obscure bugs.

There are also many ways to avoid shared pointer usage:

Try restructuring your code. This will usually yield the biggest benefits, you’ll end up with a clearer structure and less clutter.

Try to use scoped pointers from boost or unique pointers if you can. Way too often shared pointers are used when a scoped pointer would be enough.

Don’t be scared of copies! Sometimes you can just copy your object and end up with cleaner (and maybe even faster) code. Are you really sure you need to share state?

Does that mean you should never ever use shared pointers? Of course not. In some cases it’s unavoidable. Some algorithms are probably impossible to implement without them (or even impossible without GC). A shared pointer is just one more tool. Just like gotos. And, just like gotos – although not quite as dangerous – they have some appropriate use cases. Just try not to make it your default goto (lol) tool for memory management.

// TODO: There is a very good reason I found to use shared pointers: to create weak_ptr’s. Is there a good solution without actually using shared_ptr’s? I don’t know!

Luckily so far I’ve never seen anyone argue about this one: we all know we’re dealing with undefined behavior and that it’s bad. Things get a bit more tricky when the example is not so trivial.

C’s abstract machine

In a way, C and C++ describe a “virtual machine”. This is what the standard defines: what kind of operations are valid in this VM. This VM resembles an old single-thread mono-processor architecture. Most often, the code will run in a modern architecture that will resemble very little the design of C’s VM. “New” features (like caching, vectorization, atomics, pipelining, etc) implemented by the target architecture make the process of mapping our code (in the VM that C defines) much more difficult. The compiler needs to map instructions in C’s simple architecture to a much (*MUCH*) more complex design. To do that, it needs to analyze the code to guarantee certain constrains are met.

Let’s see how these constrains and undefined behavior relate to each other with this snippet:

template <typename T>
bool always_true(T x) {
return (x < x+1);
}

From a math perspective, and assuming that T is a numeric type, always_true should always return true. Is that the case for C’s virtual machine?

If we call always_true with a type like “unsigned int”, then x+1 may overflow and wrap around. This is fine because unsigned int’s are allowed to wrap around. What happens if instead we use a signed type? Things get more interesting.

Signed types are not allowed to overflow. If they do, the standard says the behavior is undefined. And the standard also says that our program can not invoke undefined behavior. This is a very important phrase: the standard says undefined behavior can NOT occur. There is no “if it does”: it just can’t, so the compiler will assume that UB will never happen. What if it does happen? Nasal demons, that’s what!

Knowing that UB can’t happen, and in our example above, the compiler can assume that x+1 will never overflow. If it will never overflow, (x<x+1) will always be true.

The compiler, by analyzing our program, can detect what conditions might trigger undefined behavior. By knowing that undefined behavior is not allowed, it can assume those conditions will never happen. That’s why, for the sample above, any optimizing-compiler will just produce code similar to “return true”, at least for -O2.

Undefined behavior is not (only) to make programmer’s lives miserable, it actually is needed to create optimizing compilers.