3 ms·

Experience has taught me that C++ compilers generally don't agree on the code they will accept: incomplete implementation of the standard (Visual C++ 2010 parti

by Ace17 11y ago

Experience has taught me that C++ compilers generally don't agree on the code they will accept: incomplete implementation of the standard (Visual C++ 2010 partial C++11 support), different non-standard header files (string.h vs memory.h), different warnings ( "possible loss of data" ), different error message conditions ( "not all control paths return a value" ). I find it a lot easier not having to support several compilers, especially if Visual Studio's is one of them. If the Visual Studio compiler was able to run on many platforms and target those platforms, it could definitely be a choice, as it compiles fast and generates fast code. However, for the moment, g++ allows me to ensure that my project properly builds for all desktop platforms, without having to setup compilation-dedicated virtual machines or worse, a jenkins build server ... How are you going to avoid breaking things if you can't cross-compile before committing ?

roel_v 11y ago
Sure, there are some differences in what compilers accept in terms of bleeding edge features. I've never found it an issue to keep within a subset that works everywhere; we're not talking about cases where you need to support VS6, obviously. And there are always compatibility shims in boost for many things. "How are you going to avoid breaking things if you can't cross-compile before committing ?" Depends on the workflow. If you cannot afford to break builds, you need to push changes through a staging layer, which will then (in large scale setups like that) also run tests etc. If it's just a few people, your build server will catch it. If it's just me, who cares that it breaks on another platform - I'll have to fix it myself anyway. As long as you do somewhat regular integration, obviously. There is no silver bullet. But when it comes to giving up the great efficiency gains that come from a great IDE like Visual Studio, or having to fumble with the toolchain a bit to integrate better - it's an easy choice for me. Plus having a project that compiles with multiple compilers keeps you honest about standards conformance and portability.

by Ace17 11y ago

roel_v 11y ago

Sure, there are some differences in what compilers accept in terms of bleeding edge features. I've never found it an issue to keep within a subset that works everywhere; we're not talking about cases where you need to support VS6, obviously. And there are always compatibility shims in boost for many things. "How are you going to avoid breaking things if you can't cross-compile before committing ?" Depends on the workflow. If you cannot afford to break builds, you need to push changes through a staging layer, which will then (in large scale setups like that) also run tests etc. If it's just a few people, your build server will catch it. If it's just me, who cares that it breaks on another platform - I'll have to fix it myself anyway. As long as you do somewhat regular integration, obviously. There is no silver bullet. But when it comes to giving up the great efficiency gains that come from a great IDE like Visual Studio, or having to fumble with the toolchain a bit to integrate better - it's an easy choice for me. Plus having a project that compiles with multiple compilers keeps you honest about standards conformance and portability.