This has implications on code portability of C++11 code in general. I am talking about having a new code generation stage akin to the C/C++ preprocessor stage wherein we can make the generated C++ code more "friendly" to a larger family of compilers. I thought perhaps this can potentially have a effect on how feasible it is to move people over to coding in C++11.
Game consoles are an example of a type of platform where you may be stuck on a limiting compiler that perhaps may not support nice C++11 features. Another example could be Intel's C++ compiler. I'm very glad to see that Intel has been working hard on this and it looks like this is a non-issue on the latest version, but suppose for some reason one needed to use an older version of the compiler!
Another semi-concrete example, is one of my recent projects has been to build a diff tool for front-line use in development; I became dissatisfied with the traditional line-based diffs so I built a little command-line tool that uses a diff_match_patch implementation in C++. C++11 has "permeated" into the glue code because auto is just too cool, but the consequence was that I basically had to go and build LLVM, Clang, and libc++ on Linux in order to start using my tool on linux. It's not really clear how to even distribute C++11 projects to Linux in source form because it is a bit of an ordeal to set clang up on Linux. This is not to say that it can't be done, but it's just too bleeding edge, and one has to spend a few hours to get that toolchain set up there. (Update: Well, a few months/years later, that same little tool now builds perfectly fine with GCC provided by centos 7's packages, so that's a relief.)
So, if I had a magical way to auto-refactor the C++11 tool to generate old-school C++ code that an older compiler would accept out of the box, this can potentially make life a little easier for some people maybe.
There's been some amazing progress on automating code refactoring with clang, and this is well-presented in David's answer here, and so it has got me thinking that perhaps there's the possibility of setting up a specific self-contained tool based off of this technology that can effectively transform C++11 code patterns into corresponding non-C++11 equivalents. The idea here being that instead of using that for general purpose automated refactoring (e.g. isolating and refactoring code where strings are converted to C-strings and back to strings), we might be able to use that for isolating the use of unsupported C++11 features and refactoring them into some code that does the same thing but would actually successfully compile.
Is this something that is possible? I'm not too familiar with the capabilities of C++11 and what the consequences would be in terms of down-grading to "old" C++ that implements the same functionality. It certainly seems like if this sort of thing was possible, I couldn't do it, because I don't have (neither do I expect I will ever have) enough of a grasp on the language to know how to implement this.
I suppose a more appropriate question would be, is this worth the effort? It is hard to see how (given that LLVM clearly is very capable at cross-compiling to ARM) one might be prevented from the use of clang to get the job done using more direct methods such as cross-compiling to the target paltform. My guess is that this is simply my paranoia speaking and I won't really need to worry in the future about getting my C++11 code running smoothly across all conceivable target platforms as they should all be either x86, x86-64, or ARM anyway. But who knows what my job will be in a few years.
boost.configthat will handle the compiler differences. – Hasletboost.configmight help for this? – Tappet