1. Grab a bunch of text (Shakespeare's Hamlet, the lyrics to Baby got Back, etc.)
2. Generate probabilities of which letters will follow other letters in that text
3. Randomly pick new letters using the probabilities you just generated

The result is something that looks like the original text, but is nonetheless random.

How random is it? One interesting knob you can turn when running this algorithm is how many letters you use to figure out the probability of a subsequent letter.

Let's look at a little example of this using the current C++ language standard. We'll generate a new language (call it C++14!) and see how turning this knob affects the output.

Basing our probabilities off of one letter gives us this version of C++, apparently sung by Sigur Ros:

A tiss cop(18) sted 1 vathecv-titeceteand ig blld: al, s) YZ fistauctoshatd, r) ce uliten 33.4 (C 24) tis ioitrome t, atingof s<clare rtinisherairTh t C 2); coruranond ubuns cowhaueme prendocatst Ty, frularelaisspate ons op().

Upping to three letters switches genres to Edgar Allan Poe:

Two set typed ways poweversions // 20
defining res perfor_type id; stdardle nevel programe shower therence at bool volving: I1, or eachin the bming& wherwise, the double>, an tempty arent_everencess but cons [b.conver defix-expres: the function over.

Six letters begins to sound frighteningly plausible:

join(c, d) in_between the hash_function or a type openmode model reflects throughout the associated from the sequently left squared memory for facets, and 
Key, respectively): — If T is defining object used with *this has that has a nested class error.

And here is the result with nine letters:

Note: This guarantee is not zero, the functions F returns the null pointer to an integral conversion specified belongs is implementation-defined native character string literal, 29
boolean literal, 29, 1165
Boolean type, 71
bound argument must be used to represents a BLAS-like slice out of the standard C library, how a well-formed.

Well look at that -- I believe we have a new language.

Match the language standard (C, C++, C#, Go, Java, or Javascript) to the tag cloud:

answer: C++

answer: Javascript

answer: Java

answer: C

answer: C#

answer: Go

If you got all six right, then I'm impressed. Get thee to a law firm!

Observations

• Unsurprisingly, C is a popular target to compile to.
• Popularity doesn't necessarily correlate with cross-compiler interest. Look at Objective-C and Javascript, for example -- Javascript isn't as hot as Objective-C, but everybody wants to compile down to Javascript.
• Nobody wants to compile to Bash.

About the visualization

Popularity is represented by color, with data from good ol' TIOBE 2013.

Interest in cross-compiling between languages is represented by node and edge size, using data based on the number of results from search engine queries like "compile c++ to ada" or "c++ to ada compiler".

int main() {
  enum Result {
    LOSE = 0,
    WIN,
    DIE_TRYING
  } result;

  switch (result) { 
   case LOSE:
    break;
   case WIN:
    break;
   case DIE_TRYING:
    break;
   default:
    // can't get here?
  }
}

How many possible values can result hold?

...

The answer, of course, is four. In addition to LOSE, WIN, and DIE_TRYING, WIN | DIE_TRYING is a valid value for result.

A rule of thumb is that enums can hold any value that fits into the smallest bit pattern required by the enum. Since the Result enum needs two bits to store 00b, 01b, and 10b, one valid value is 11b, a.k.a. WIN | DIE_TRYING.

There are two things going on here

• An rvalue reference is a type. Everyone knows what types are. Examples include T&&, const T&, and T.

• The term rvalue is a property of an expression. In C++11, rvalues were renamed to prvalues, and every expression is either a prvalue, an lvalue, or an xvalue. The official names for these terms are value categories.

To reiterate: value categories (prvalues, lvalues, xvalues) are properties of expressions, whereas rvalue references (T&&) are types.

So what are prvalues, lvalues, and xvalues?

Every expression is either a prvalue, an lvalue, or an xvalue. In fact, there's a whole taxonomy that C++11 defines:

• lvalues represent objects that will stick around for a while. Examples include named objects and functions calls that return references to objects. Because they're not going anywhere, you can assign things to them and take their address.

• prvalues represent temporary objects, i.e. objects that will not persist past the outermost expression that they appear in. Examples include temporary objects explicitly created inline and function calls that return objects by value.

• xvalues represent objects that are about to expire. A function call that returns an rvalue reference (like std::move(foo)) is an example of an xvalue.

glvalues are expressions that are either lvalues or xvalues. rvalues are expressions that are either prvalues or xvalues.

Here's an annotated example that shows value categories and types:

#include <string>

template <typename T>
void swap(T& t1, T& t2) {
//        --     --     types (T&)

   T tmp(std::move(t1));
// -                    type (regular T)
//                 --  lvalue
//       ------------- xvalue

   t1 = std::move(t2);
// --             --   lvalues
//      -------------  xvalue

   t2 = std::move(tmp);
// --             ---  lvalues
//      -------------  xvalue
}

std::string get_greeting() {
   return "Good news, everyone!";
}

int main() {
   std::string s1, s2;
// -----------          type (regular std::string)

   s1 = get_greeting();
// --                  lvalue 
//      -------------- prvalue

   s2 = std::move(get_greeting());
// --                             lvalue 
//                --------------  prvalue 
//      ------------------------- xvalue

   swap(s1, s2);
//      --  --   lvalues
}

Next up: why std::move(get_greeting()) in the above example is unecessary.

There are only two hard problems in computer science:

1. naming things,
2. cache invalidation, and
3. off-by-one errors.
   

This is a post about naming things. Consider the following code:

template <typename T>
void foo() {
  T::iterator it;
}

int main() {}

Will this code compile?

No, because the compiler doesn't know that T::iterator refers to a type.

How do I fix it?

You need to use the typename keyword, like so:

template <typename T>
void foo() {
  typename T::iterator it;
}

int main() {}

Why is typename necessary?

T::iterator is called a dependent name, because it depends on what T is. Most of the time, dependent names in templates are not assumed to be types.

Why can't the compiler assume this dependent name is a type?

Because T::iterator might not refer to a type. Here's an example of a potential T where T::iterator isn't a type:

struct Bar {
  static int iterator;
};

Why can't the compiler figure out which names refer to types automatically?

Because the template definition might work either way -- with T::iterator as a type or with T::iterator as a variable:

int b;

template <typename T>
void baz() {
  T::iterator *b;
}

In the above code, does the body of baz:

• declare a variable named b that is a pointer to the type T::iterator, or
• multiply the global variable b with the static variable T::iterator, and ignore the result?

If all we've seen is the template, we don't know. It could be either.

Why doesn't the compiler delay processing the template definition until it sees an instantiation?

Good question. Here are some reasons why the compiler parses template definitions when it sees them:

• It allows the compiler to generate errors sooner.

• If the compiler waited until it saw an instantiation, it would have to decide if code that appears between definition and instantiation could be used in the template. For example, a better match for an overloaded function call might be introduced -- should it be ignored?

• Worst of all, different instantiations of the ambiguous template above would mean the same chunk of code could produce totally different parse trees, which seems unlikely to match programmer intent.

My head hurts.

TL;DR: Use the typename keyword with dependent names in templates to indicate those names are types.

His inability to shave was caused by a back injury, triggered by either (a) an extended session of applying polyurethane to newly-created office furniture or (b) the subsequent sloth of watching an Office Space marathon on the couch. Both events were exhausting.

On an unrelated note, after consulting on a live website that was littered with identical statements of the form:

<?php eval(base64_decode("DUshdagHsdhl...WEJxckl==")); ?>

...the engineer concluded that repeatedly evaling a fixed base64-encoded string is probably a sign that something is amiss.

For the first time in 7 months, the engineer spent most of the day out-of-doors trying to build something with his hands. The sun was brighter than the engineer remembered, but there were no cubicle walls to protect him from the elements.

Around noon, a lunch truck pulled up to the work site across the street and honked. On the bed of the truck perched a ridiculously large tin kitchen that was leaking steam from a thousand fissures. Everyone seemed happy to see the truck. The engineer wistfully remembered when delicious food trucks used to visit him at work.

The engineer's jigsaw became briefly sentient and attempted to perform ocular surgery on the engineer. The engineer could not recall windbg ever being so unexpectedly malicious.

Fortunately, the day ended with minimal injuries.

Can we have C#-style explicit outparams in C++? elcapaldo showed me a neat approach last week that I'll try to reproduce here. (Of course Logan supplied the cool stuff; any errors are all mine.)

How it looks in C#

In C#, everything defaults to pass-by-value. If you want to be able to modify an argument to a method, you have to attach either a ref or out modifier to the argument at both the method definition and at each call site:

// 'value' is marked as an outparam
public bool TryGetValue(string key, out string value) { ... }

public void SomeMethod()
{
  string value;
  if (TryGetValue("bar", out value))   // 'value' must be marked as an outparam
  {
    ...
  }
}

The out keyword implies a number of things, but the most noticeable effect is that consumers of methods with outparams have to explicitly acknowledge that they're using outparams.

Can we do something similar in C++?

How it looks in C++

Consider the following definition of the Out type, along with a couple of helper functions named out:

// parameters of type T can be passed as type Out<T>
template <typename T>
class Out {
private:
  struct OutRefHolder {
    T &ref_;
    explicit OutRefHolder(T &ref) : ref_(ref) {}
  };

public:
  Out(OutRefHolder &&oref) : ref_(oref.ref_) {}
  Out(Out &&o) : ref_(o.ref_) {}
  Out(const Out&) = delete;
  Out() = delete;

  template <typename Q>
  void operator=(Q &&q) {
    ref_ = std::forward<Q>(q);
  }

  template <typename Y>
  friend typename Out<Y>::OutRefHolder out(Y &ref);
  template <typename Y>
  friend typename Out<Y>::OutRefHolder out(Out<Y> &o);

private:
  T &ref_;
};

// helper functions to create something convertible to an Out<Y>
template <typename Y>
typename Out<Y>::OutRefHolder out(Y &ref) {
  return typename Out<Y>::OutRefHolder(ref);
}
template <typename Y>
typename Out<Y>::OutRefHolder out(Out<Y> &o) {
  return typename Out<Y>::OutRefHolder(o.ref_);
}

Given that definition, we can use the Out type and the out functions like so:

#include <iostream>
#include <string>
#include "Out.h"

bool get_prop(const std::string &key, Out<std::string> value) {
  if (key == "keymaster") {
    value = "gatekeeper";
    return true;
  }
  return false;
}

int main() {
  std::string value;
  if (get_prop("keymaster", out(value))) {
    std::cout << value << '\n';  // displays "gatekeeper"
  }
}

The definition of Out makes it hard to mis-use: an Out<T> isn't copyable and isn't easy to create, except indirectly via the out functions.

The result: if you write functions that take an Out<T>, the easiest path by far forces people to explicitly acknowledge that they're passing an outparam. Just like C#.

Yesterday, Logan pointed out that you can construct a shared_ptr<T> that manages some T but shares a control block with some completely different shared_ptr<U>:

template <typename T> class shared_ptr {
public:
  // constructs a shared_ptr that shares ownership with r and stores p
  template<typename U> shared_ptr(shared_ptr<U> const &r, T *p);
  // ...
};

This is a pretty cool use of shared_ptr that I had not seen before.

A Compelling Example

Say you have two objects -- one nested inside the other -- that need to be able to refer to eachother. If you give each object a shared_ptr to the other object, they'll leak-lock eachother until your program dies of consumption. You could break the symmetry by giving one a weak_ptr to the other, but then you run the risk of one object expiring before the other.

What we really want is both objects to stay alive as long as either is around:

#include <memory>
#include <iostream>

struct Foo;

struct Bar {
  Bar(Foo *f) : foo(f) { std::cout << "Bar\n"; }
  ~Bar() { std::cout << "~Bar\n"; }
  // goal: this Foo should be valid as long as this Bar is alive
  Foo *foo;
};

struct Foo : std::enable_shared_from_this<Foo> {
  Foo() : bar(new Bar(this)) { std::cout << "Foo\n"; }
  ~Foo() { std::cout << "~Foo\n"; }
  // give someone access to our Bar
  std::shared_ptr<Bar> getBar() {
    return std::shared_ptr<Bar>(shared_from_this(), bar.get());
  }
  std::unique_ptr<Bar> bar;
};

int main() {
  std::shared_ptr<Bar> bar;
  {
    std::shared_ptr<Foo> foo(new Foo);
    bar = foo->getBar();
  }
  std::cout << "foo is dead now...or is it?\n";
}

When run, the above code produces the following output:

Bar
Foo
foo is dead now...or is it?
~Foo
~Bar

The Thrilling Conclusion

By attaching the shared_ptr<Bar> to the control block for the shared_ptr<Foo>, we can enforce the idea that if we grab a Bar from a Foo, the Foo will live at least as long as the Bar does.