On the agenda for the next team meeting.

Should we discuss which of the cool new features we want to use in new code
(e.g. when to use auto) and which of them we want to change in existing code
(e.g. hash sets/maps)? (Steps 5. - 7. in Jendrik's msg3022)

I've changed the text a bit -- we don't support C++98 *and* C++11, that way lies
madness. (Also, we don't have any way at the moment to test C++98 compatibility.)

Merged and pushed. Awesome :) 

I added a small section on language support at 
http://www.fast-downward.org/ForDevelopers/CodingConventions.

There is perhaps a slight negative tendency, but I don't think this is an
obstacle to merging this.

The experiment is finished, here are the results (huge files as always):

sat:
http://ai.cs.unibas.ch/_tmp_files/seipp/issue425-sat-compare-core-configs.html
http://ai.cs.unibas.ch/_tmp_files/seipp/issue425-sat-compare-portfolio-
configs.html

opt:
http://ai.cs.unibas.ch/_tmp_files/seipp/issue425-opt-compare-core-configs.html
http://ai.cs.unibas.ch/_tmp_files/seipp/issue425-opt-compare-portfolio-
configs.html

> [Update: we should defer this a little bit; I still have to fix a little issue
> with the LP code.]

No, this looks unrelated. I think we can go ahead with this one. Here's a link
to the code on bitbucket:

https://bitbucket.org/malte/downward/commits/issue425

Reopening this one instead of creating a new issue.

The current code is ready for use with C++11, i.e. Step 1. in Jendrik's msg3022
already works.

So I suggest we move on to Step 2. and test the performance. I've started a
branch for this on my Bitbucket repository which changes the Makefiles to use
-std=c++0x (-std=c++11 doesn't exist for g++ 4.4).

Jendrik, can you set up a whole-planner experiment to compare the head of that
branch to the base? (Other volunteers welcome too, of course.)

[Update: we should defer this a little bit; I still have to fix a little issue
with the LP code.]

The way the issues is phrased ("Allow using"), it's a policy question, not an
issue to work on, so I suggest moving it off the tracker (where people don't see
it) and onto the downward-dev mailing list or one of our meetings. Hence I'm
marking this resolved, but please do bring this up with the others.

Regarding no 7., the main reason we're using GNU's hashed containers instead of
the standard library's (which should be identical to the TR1 types) is because
in our most recent tests, GNU's containers were more compact. It would indeed be
good to experimentally quantify the actual time and memory differences. So far,
we have only done artificial benchmarks to test memory consumption in the limit,
but these don't really matter if hash table overhead isn't a large factor in our
overall memory usage.

As we discussed per mail previously in a thread I can't find now, we would like to allow using C++11 
features in Fast Downward. The question is how we want to go about this. I would propose the following 
course of actions:

1. Make FD compile with -std=c++11 (previously the CEGAR branch used this flag and little to no action was 
needed to make this work)
2. Make sure that this change introduces no performance regressions
3. Make our buildbot compile FD with gcc 4.4 (as on maia)
4. Allow using all features from the C++11 stdlib that are implemented in gcc 4.4
5. Select some c++11 core features implemented in gcc 4.4 that we want to allow (e.g. "auto" keyword, 
strongly-typed enums) (http://gcc.gnu.org/gcc-4.4/cxx0x_status.html)

Separate issues could handle the following tasks:
6. Look through the code and use C++11 features where they make the code easier
7. Check if replacing obsolete types (from TR1, __gnu_cxx) preserves performance