I'm marking this as resolved for now, because we now recommend to do native
builds with Visual Studio 2013 on Windows instead of using Cygwin. We don't test
the build with Cygwin regularly, as we do with Visual Studio, so we cannot
guarantee that new changes that we merge are compatible with it.

If this doesn't work for you Zebreu, feel free to reopen this issue or open a
new one.

Sorry, I can't check it now as we're not using Fast-Downward at the moment and I'm 
currently not working on a Windows machine, but we plan on doing more with it so I can 
report back when we do.

Zebreu, is this still an issue for you, now that we support native Windows builds 
(http://www.fast-downward.org/ObtainingAndRunningFastDownward)?

Well, I think we can certainly add a workaround, even if it's Cygwin's fault.

Someting like an #ifdef that checks the OS and compiler version and adds a
definition of stoi for compilers that don't have it. We just have to be careful
to add the correct conditions, though, because if it's too general, we will get
errors about duplicate function definitions on compilers that have stoi.

The version is 4.8.3, but I've read that it was a cygwin bug (or rather an 
incomplete port) that's been there for a year.
Since this is the case, I'm guessing this issue is not really a bug and maybe 
should have been added to the mailing list instead to help other Windows users?

stoi is a standard library function added in c++11. We have started requiring
c++11 recently, so if some compiler has problem with that in general, I'm afraid
there will soon be hundreds of related issues when we use more c++11 features.
Can you tell us a bit more about the compiler is included in the Cygwin
toolchain you're using? (If it's a variation of gcc, "gcc --version" would
display the information.)

I just built Fast-Downward through Cygwin and because stoi wasn't found, I had to 
change option_parser.cc, by including cstdlib and replacing stoi(value) with 
strtol(value.c_str(),0,10).