3 ms·

Move semantics opens up a new age where higher level STL-like containers (and types built from them) can perform as well as raw C pointer based implementations.

Move semantics opens up a new age where higher level STL-like containers (and types built from them) can perform as well as raw C pointer based implementations. The last real roadblock is the elephant in the room: compiler support. I've argued with John Lakos that all the guys at work on the C++ committee should take a break from the standards process now and devote themselves for a time to getting C++11 fully supported into all main compilers. Only having move semantics in gcc is not good enough :/

shin_lao 15y ago
It's there in clang and Visual Studio 2010.
- apaprocki 15y ago
  Only leaving CC (Oracle), xlC (IBM), aCC (HP) to name a few. I got 99 platforms and x86 is only one. :)
  - qdog 15y ago
    Yes, and ARM is everywhere.
  - nitrogen 15y ago
    On your large projects that must support Oracle, IBM, and HP's compilers, what prevents you from compiling your C++11 code with gcc and linking it in? Is it to difficult to maintain a consistent external ABI? Does gcc not support the other ABIs and/or mangling conventions?
    - lysium 15y ago
      Mangling is not standardized and every compiler does it differently. In general, you can't link files compiled by different C++ compilers.
      - apaprocki 15y ago
        And to make things even more fun, each individual compiler usually comes with baggage it has collected over the years. In xlC alone the -qnamemangling option can be set to: ansi (don't let it fool you), v11, v10, v9, v8, v7, v6, v5, v4, v3, or compat so even code build with the same compiler isn't always compatible.
    - apaprocki 15y ago
      The generated code is not compatible and there are other issues. We have some stubs vs dwarf debug information issues with gcc. The code generated by gcc is not as optimized as the vendor supplied compilers. This is if you are telling the compiler that you only want to support sparcv8+ or pwr5+ so it can take advantage of the newer CPUs. And even if gcc was the same or better, there is the issue of support. We only use the vendor compilers because we meet with them regularly and they will fix any bugs immediately (at least start working on them) and are open to enhancement requests. I'm not aware of any company willing to provide awesome service for gcc on these platforms. Edit: Not to say we don't use gcc. The entire codebase does of course build using gcc on all of the platforms.. it is mainly the support issue and tweaks needed to build the binaries the way we want on each architecture.
  - Alaric 15y ago
    It might be more beneficial to try to get them to improve llvm support for their respective os+archs. It'd be less diversity of compilers but is probably a better investment for them than shoe-horning a poor/incomplete C++11 implementation into their aging compilers.
    - apaprocki 15y ago
      Yeah I'm pushing this route as well, but unfortunately the "hard to reproduce" part is all of the chip specific optimization. You could imagine that if their optimization phase(s) look nothing like llvm it would be really hard to get them to buy into that. I've had more success getting vendors to contribute gdb support (IBM has). I'll keep trying, though.

shin_lao 15y ago

It's there in clang and Visual Studio 2010.

apaprocki 15y ago
Only leaving CC (Oracle), xlC (IBM), aCC (HP) to name a few. I got 99 platforms and x86 is only one. :)
- qdog 15y ago
  Yes, and ARM is everywhere.
- nitrogen 15y ago
  On your large projects that must support Oracle, IBM, and HP's compilers, what prevents you from compiling your C++11 code with gcc and linking it in? Is it to difficult to maintain a consistent external ABI? Does gcc not support the other ABIs and/or mangling conventions?
  - lysium 15y ago
    Mangling is not standardized and every compiler does it differently. In general, you can't link files compiled by different C++ compilers.
    - apaprocki 15y ago
      And to make things even more fun, each individual compiler usually comes with baggage it has collected over the years. In xlC alone the -qnamemangling option can be set to: ansi (don't let it fool you), v11, v10, v9, v8, v7, v6, v5, v4, v3, or compat so even code build with the same compiler isn't always compatible.
  - apaprocki 15y ago
    The generated code is not compatible and there are other issues. We have some stubs vs dwarf debug information issues with gcc. The code generated by gcc is not as optimized as the vendor supplied compilers. This is if you are telling the compiler that you only want to support sparcv8+ or pwr5+ so it can take advantage of the newer CPUs. And even if gcc was the same or better, there is the issue of support. We only use the vendor compilers because we meet with them regularly and they will fix any bugs immediately (at least start working on them) and are open to enhancement requests. I'm not aware of any company willing to provide awesome service for gcc on these platforms. Edit: Not to say we don't use gcc. The entire codebase does of course build using gcc on all of the platforms.. it is mainly the support issue and tweaks needed to build the binaries the way we want on each architecture.
- Alaric 15y ago
  It might be more beneficial to try to get them to improve llvm support for their respective os+archs. It'd be less diversity of compilers but is probably a better investment for them than shoe-horning a poor/incomplete C++11 implementation into their aging compilers.
  - apaprocki 15y ago
    Yeah I'm pushing this route as well, but unfortunately the "hard to reproduce" part is all of the chip specific optimization. You could imagine that if their optimization phase(s) look nothing like llvm it would be really hard to get them to buy into that. I've had more success getting vendors to contribute gdb support (IBM has). I'll keep trying, though.