Thanks for the reviews! I merged the code.

I had a look and don't have any comments.

Sounds good. Silvan, can you review the code? If you're happy to merge it, then
from my side it can be merged.

I don't think that we necessarily should use OperatorID instead of int, since I
personally associate OperatorID with the task interface classes (AbstractTask or
TaskProxy). Here, however, we have a custom class AbstractOperator and could use
any identifier to these operators. Actually, with the intended change of this
issue, MatchTree will not know anything about AbstractOperator at all, but only
on "regression preconditions", so I'm fine with it using plain ints as IDs.

Regarding the dump method, I don't think dumping the operators separately and
having to manually map the operator IDs from the MatchTreep dump to separate
output of operators makes debugging easier. I see how the tree output gets more
compact, but that's it. Anyway, I don't think breaking/changing this method is a
good reason not to do the suggested changes, because I see the dump method
rather as a service for developer than a core part.

Malte noticed that the patch removes some debug output that maybe requires
discussion: 
https://bitbucket.org/jendrikseipp/downward/pull-requests/120/issue894/diff#comment-93029783

Where we used to call AbstractOperator::dump() (which prints the regression
preconditions and hash effect), the patch now only prints the AbstractOperator ID.

Personally, I think users can simply dump the MatchTree and the
AbstractOperators separately, which might even be more compact and therefore
easier to debug.

I left a few comments.

> It would be a different story if we had a nice way of using OperatorID to
> index into vectors, but that's a different issue, I think.

If we really want that, it should be a one-liner to add to operator_id.h
(although we'd write it in four lines ;-)):

    operator int() const {return index;}

I agree it's a different issue, just pointing it out in case someone is
interested in making this happen.

Florian and Silvan, what do you think?

I had the same thoughts. I'm leaning towards using ints since all code
(including unmerged code) uses ints, since it has to index into vectors.
Requiring OperatorIDs here would require some boilerplate code for packing and
unpacking ints into and from OperatorID without any big benefit as far as I can
see. It would be a different story if we had a nice way of using OperatorID to
index into vectors, but that's a different issue, I think.

Looking at the code briefly, it uses "int". Is this better than "OperatorID",
which sounds more obvious given the issue title?

I am not saying it should be OperatorID; I don't know.

I made a pull request at
https://bitbucket.org/jendrikseipp/downward/pull-requests/120 . Any volunteers
for reviewing?

Currently, PDB match trees operate on AbstractOperator objects. If we let them
work on operator IDs instead, reusing pdbs::MatchTree becomes easier and the
saturated cost partitioning code from issue780 doesn't have to touch any code in
the "pdbs" directory. The proposed change also reduces the memory footprint of
code that permanently stores MatchTrees.