Funny queries: What Google thinks of me

It's been a long time since I used the metapost category. I've been taking a look at the queries received by Google for which this blogs shows up. Some of them are quite peculiar, some of them may give us an insight of what the search engine things of me. For example:

Query	Impressions
grumpy old man	2,000
grumpy	400
grumpy man	400
ugly old man	250
grouchy old man	110
grumpy old	35
old grumpy man	70
grumpy gnome	12

There was a long list of variations to these phrases, but I didn't want such a long post. Anyway, if you thought that grumpy is all Google considers me to be, brace yourself for a surprise:

Query	Impressions
trained monkey	90
no life	90
funny troll
monkey using computer
tool monkey
congratulations monkey
monkey using tools

Basically, a computer using trained-troll monkey, with no life. Pretty accurate, some people may say.

Query	Impressions
señal de muerte	12

Literally signal of death in Spanish. Tip: Lack of pulse.

Another common search:

hang yourself	200
how to hang yourself	90
rope to hang yourself	12

I guess those searches have a very low returning rate.

This is a query which sincerely surprised me:

Query	Impressions
eliphant
eiephant
elehant
elepant
eephant
elephanth

I'll do a public service here: it's written 'elephant', buddy.

Final classes in C++

Have you ever wondered what's the best way of having a class from which you can't inherit, say, like Java's final? Without any doubt, the best way is having a team capable of not doing things like inheriting from 'class NeverEverEverInheritFromThis'. The second best way involves some magic and lots of beer:

class Final {
    protected:
    Final() {}
};

So, what the hell does that evil device do? Easy, it defines a protected constructor, meaning only derived classes will be able to access it (i.e. no public construction of this object). How does this stop other classes from inheriting? It doesn't, unless we add one more keyword:

class Final {
    protected:
    Final() {}
};

class X : virtual Final {
};

The virtual inheritance is meant to be used to avoid the dreaded diamond in multiple inheritance designs. It does a lot of magic with the constructors and the memory layout of the object; amongst other things, it'll make any class which derives from X have only a single base class for Final and it'll also make this hypothetical class call Final's constructor without going through X first.

A complete explanation of virtual inheritance is beyond the scope of this article, but it's enough for our Final device to know that it forces the virtual base's constructors to be called first, thus now we can write this:

class Final {
    protected:
    Final() {}
};

class X : virtual Final {
};

class Y : public X {
};

int main() {
    X x;
    Y y;
    return 0;
}

Try it and watch it fail!

Update 2011-07-08: Amazing how time flies. This article has been written about a year before its publishing, and, believe it or not, it's already showing its age. What I would update on this article is the first paragraph: the best way of not having a problem with final classes is creating a design which doesn't have artificial restrictions to the growth and extensibility of the system (i.e: don't use final classes, they are usually a bad idea). I like that idea, I may write another article about it.