Category: Tech

Firefox keyword search for finding C++ keywords

I often want to search the SGI C++ reference for a keyword. The best way I have found to jump straight to the page I want is to use Google’s “I’m Feeling Lucky” search limited to searching within sgi.com.

You can create a Firefox keyword search to allow you to do this quickly from the location bar. Now I just type Ctrl-L then e.g. “c vector” to jump straight to the page about std::vector.

To do this, make a bookmark (to anything) and then right-click it in the Bookmarks menu and choose Properties. Edit it to look like this:

Firefox C++ search keyword bookmark

The Location field is set to http://www.google.com/search?as_q=%s&as_sitesearch=sgi.com&btnI=1, and the Keyword field is just c.

This post was largely for my own benefit to remember this next time I need to set it up, but I thought it might be useful to others as the information about how to set these searches up is not easy to find.

If you want to go to a google search results page, instead of jumping to the “I’m Feeling Lucky” result, remove the &btnI=1 part.

Flaws in the software patents system

Note: I am in favour of patents on inventions.

I believe the current software patents system has a number of flaws (in decreasing order of importance to me):

  1. They attempt to close off the use of knowledge rather than open it up. If we were not filing patents for our work, we could be writing papers or books to share that knowledge. What would have happened if the Gang of Four had filed patent applications instead of writing Design Patterns?
  2. They can verge on the dishonest. Describing most software development work as “novel” and “non-obvious” is simply incorrect. There is a huge community of software developers, and the idea that none of them would find what I am doing “obvious” beggars belief.
  3. They are a tool that big companies can use to squash small companies. Small companies can’t afford to develop a large defensive patent portfolio. Patents don’t even need to be valid or high-quality: if there are enough of them, a company that can afford a lot of lawyers can destroy one that can’t.
  4. They are a tool that big companies can use to squash open source projects. Many open source projects have no money at all. If a large company doesn’t like some project, they can simply sue for patent infringement (even for patents that are blatantly irrelevant) and the project will be toast.

So I don’t want to be involved in patent applications at my work, even though my employer is keen on patents.

I am now considering how I should act on this opinion. I don’t want to screw my colleagues but I think I want to refuse to be a part of any patent applications as far as I can do that without screwing them.

IGCC – a real-eval-print loop for C/C++

When you first hear about the Read-Eval-Print Loop you might well think “So what?” as I did.

What’s so great about being able to type commands interactively?

But the thing is that it creeps up on you.

Everyone already knows programming is an interactive thing – we need constant feedback to validate our ideas. Programming on paper is incredibly frustrating because you have to plough on with assumptions that are probably wrong.

It’s just so comfortable to be able to try out ideas in an interactive interpreter.

Foosball

I mean, it’s really not much hassle to create a new directory, make a new file, edit the file to contain the code you want to try, remember the right command to compile it, then run the program and see the results, is it?

Well, no, it isn’t, but it’s enough of a hassle that sometimes you don’t bother and you try it out in the code you are really working on, and if your work is like mine that means a minimum of 5 minutes to compile and link, and there you are playing foosball again when you could be getting something done.

The REPL gives you a place to try throwaway things extremely quickly, and when you’re working with something beautiful like Python it’s easy to get addicted.

So my mind started to wander and it struck me that a pale imitation of the REPL could be made for us poor C++ programmers, and it would generally serve the purposes I’ve described above.

So IGCC was born. Its name means “Interactive GCC” and it’s a read-eval-print loop for C++ (and, for most cases it will work for C too).

It uses the real GCC underneath, so you know you are running the exact code you would be (and it’s somewhat easier to write than a custom C/C++ interpreter) and all it does is take away the hassle of creating a simple program and compiling it with GCC.

It wraps your code in a standard C program, includes some common dependencies, and compiles it, printing the results of running them immediately. Using it looks like this:

$ ./igcc 
g++> int a = 5;
g++> a += 2;
g++> cout << a << endl;
7
g++> --a;
g++> cout << a << endl;
6
g++>

Apart from all the sugar that I’d love to add, the main missing features are some kind of equivalent of the Python dir command, and code completion.

It’s not rocket science, but it might make you a little bit more interactive in your C and C++ coding, which might save you valuable foosball time.

Enjoy, improve, etc. IGCC.

Foosball image taken from http://en.wikipedia.org/wiki/File:Baby_foot_artlibre_jnl.jpg

Diffident – command line side-by-side diff editor

I really like Beyond Compare, which is a proprietary diff program with all those little touches that make it a joy to use*. The way I write code at work generally involves a bit of hacking in jEdit, checking the code myself, and then reviewing the code with a colleague.

*Recently, though, they’ve brought out a newer version that seems to overcomplicate things.

Both my own checking and the code review with a colleague generally involve comparing the code with the previous version in the (perforce) repository. Beyond Compare integrates nicely with the perforce tools and allows you to see a change as diffs of each file involved.

None of this is anything new to the Free Software world, of course. All the version control programs I’ve used allow you to do the equivalent of cvs diff and see what changes you’ve made. Git has a particularly good git diff mode which by default colours your diff and pipes it to less, making it easy to read and use.

What I have found myself missing recently, though, is the ability to edit the files as you diff them. The whole point of reviewing what you’ve done is to make changes as they occur to you, and with perforce + Beyond Compare it is really natural to make those changes within the diff tool.

Incidentally, I also really like the side-by-side style of Beyond Compare. By default it inserts “missing” lines so that all the similar lines are aligned, rather than trying to indicate with balloon-like lines that code has been inserted or transformed. I find those balloons very annoying and confusing (and they take up space on my screen, grr).

Having a side-by-side view also makes copying lines from one side to the other much easier. I often copy from one side to the other – especially when I realise what I have done is stupid and I want to revert a section back to how it was.

So, to curtail an already-long story, I decided there was yet another area of my life where the only solution was to run software I had written, rather than relying on the shoddy stuff put out by others, so I wrote a diff tool.

Diffident is a diff tool inspired by Beyond Compare and git. It shows you a side-by-side diff of your files in a terminal (one day it may have a GTK+ interface too) and allows you to edit them. The editing part is in development – expect a release fairly soon, or get the code from the git repository. The output is coloured, and you can see the whole of both files, using keyboard shortcuts to jump to the next and previous differences.

You might ask “Why not just use Beyond Compare?” For a number of reasons:

  1. It is not Free Software. I can’t improve it or trust it.
  2. It’s sort of Windows-y. I know there is a Linux version, but I bet it’s not very Linux-y. (Disclaimer: I’ve never tried it ;)
  3. It doesn’t work in a terminal.
  4. The inline editing support is not great. Its real strength is copying from side to side.
  5. It doesn’t feel right when used with git. I have got this set up in my Cygwin environment – it works, but it’s no fun.
  6. It isn’t written by me.

I’d really like Diffident to become the de-facto diff tool for git people (and everyone else). That proves to be a bit trickier than I’d like because of the way git interacts with diff tools, but I’ve got a decent solution for using it as the GIT_EXTERNAL_DIFF tool, and I hope to improve it in the future. (For those who are interested, the kind of thing I’m thinking about is how to get git diff --cached to allow me to edit the files in the index.)

So anyway, check out Diffident and if you like it, help me make it better.