Sounds good -- setting this to "resolved" for now on the grounds that I'd rather
have us deal with the more substantial issues. If anyone disagrees, feel free to
switch to "deferred". :-)

I removed the enum option that we had in EHC search (because no matter how we
decide this, the previous code would have been replaced).

I have no strong opinion on this matter (all options have advantages and
disadvantages) but since this is not so important, I am fine with postponing
this issue.

For now, I'm for Gabi's option (a) because everything else would be a lot of
work. We should then also get rid of the enum option we currently have for
preferred_usage that Gabi mentions.

In the future, (b) or (c) sound good, but I think there's some more pressing
work to do first. :-) If we go down this route, here's an interesting link:

http://stackoverflow.com/questions/217549/which-typesafe-enum-in-c-are-you-using

In particular, check the first reply using Boost.Enum, which unfortunately isn't
part of the regular Boost libraries.

One option is to do something like here: 
http://www.codeproject.com/kb/cpp/C___enums_to_strings.aspx

It's very ugly, but since it's only for a small number of enums (only those that 
are used in command line parameters), it's not horrible. This has the advantage 
that the "help string" can be automatically generated.

However, I am fine with just using the integer values.

Erez would like to have the possibility to specify options that
have an enum value as domain by a string instead of a number.
Currently this is usually done by an integer value (for
some examples see in
http://alfons.informatik.uni-freiburg.de/downward/HeuristicSpecification
the options

- lm_type for landmark count heuristic
- merge_strategy for merge-and-shrink heuristic
- classifier for selective-max heuristic

In contrast to this we already have string values for one option:
http://alfons.informatik.uni-freiburg.de/downward/SearchEngine#ehc
Option preferred_usage.

If you have a look at the code (enforced_hill_climbing_search.cc, line 258, 
r4552), you see that this is currently done with an ugly implementation that 
relies on the assumption that the enum PreferredUsage will never change. This 
makes the code much harder to maintain, so I do not really like it.

I think the best way (from a user-perspective) would be that the options
can be specified as integer or as a string the corresponds to the enum
value name.

Two questions:
- which way of enum option specification do you prefer?
  (a) only integer values
  (b) only enum value names
  (c) both possibilities
- Does anybody have an idea, how we could implement (b) or (c) without 
  relying on a given set of enum values?