4 ms·

On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. In the examples I

by w-m 7y ago

On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. In the examples I've seen it seems to mostly come down to compiler, toolchain and 3rd party binary availability for the new versions, like with any major language version. If for example you are using stock gcc from Ubuntu 16.04 for your builds, you can't use C++17.

Fronzie 7y ago
For big (legacy) code-bases, just upgrading the compiler is a project by itself. All 3rd party C++ libs need to be upgraded, all internal projects need to upgrade in an orderly fashion. On top of that, just the change of the compiler will expose some pre-existing bugs.The bugs might have been there, but are not a problem for the business if they currently don't show. I've seen projects with a core team of half a dozen people, supported by the other SW engineers working for 6 months just to upgrade to a newer version of windows and the compiler. This was mostly due to unwise SW-design decisions accumulated over 15+ years.
- w-m 7y ago
  I totally agree, updating compilers is painful, and can be hard even for smaller projects. But for projects that went through that and actually got the newer compiler working with the C++11 code, I haven't yet seen anything that breaks compilation when then switching the compiler flag to C++14 mode.
- jandrewrogers 7y ago
  You raise a good point about newer compilers doing much deeper analysis of the code than older compilers. I have experienced the horror of compiling an old, nominally clean C++11 code base with the latest version of clang++ and seeing a small avalanche of errors and warnings that weren't picked up by the compiler when that code was written. It creates a lot of work, and frequently the nature of the bugs are not material (i.e. in context they may not produce a runtime fault), but I do find it to be good hygiene. I used to do builds with two different compilers for the same purpose, though that found compiler bugs as often as it found issues in the code.
- d1zzy 7y ago
  Plus, a lot of new library and language features are simply standardized versions of features that mature codebases had their own solutions for years, so "upgrading" to a newer C++ may also imply a long process of deprecating these alternatives in favor of standard ones, and the subtle differences between the two can expose new bugs and issues.
- cpeterso 7y ago
  Here is a list of some real-world examples of bugs that Mozilla had to fix when upgrading from Firefox from C++11 to C++14 to C++17 (still in progress). Many of these are compiler issues from upgrading to clang or gcc versions recent enough to support the new C++ versions, not C++ language changes. https://bugzilla.mozilla.org/showdependencytree.cgi?id=1560664&hide_resolved=0 https://bugzilla.mozilla.org/showdependencytree.cgi?id=15606...
  - dgellow 7y ago
    Your link requires to be logged in to see the actual bug ticket.
    - cpeterso 7y ago
      Oops. Sorry! Here is a different view of the bugs. I verified this list didn't require Bugzilla account. https://bugzilla.mozilla.org/buglist.cgi?bug_id=1396098%2C1390524%2C1377959%2C1526245%2C1395722%2C1396892%2C1238661%2C1390640%2C1238635%2C1577869%2C1194806%2C1401226%2C1577867%2C1411692%2C1378600%2C1584296%2C1379835%2C1579189%2C1412825%2C1172109%2C1278868%2C1560667%2C1335710%2C1577910%2C1322792%2C1369992%2C1507636%2C1578107%2C1416183%2C1577326%2C1580028%2C1577934%2C1262052%2C1246772%2C1377962%2C1396862%2C1413555%2C1573820%2C1378830%2C1396867%2C1278871%2C1278861%2C1577871%2C1029346%2C1396863%2C1412513%2C1278863%2C1396864%2C1243331%2C1396850%2C1536848%2C1029245%2C1412988%2C1277236%2C1581941%2C1569728%2C1378605%2C1577583%2C1029325%2C1412405%2C1411694%2C1577831%2C1576751%2C1593673%2C1410959%2C1396865%2C1577319%2C1399315%2C1163171%2C1578025%2C1411613%2C1288442%2C1412547%2C1396869%2C1578535%2C1412546%2C1577932%2C1577885%2C1578876%2C1412785%2C1377970%2C1396882%2C1412888%2C1577936%2C1277853%2C1277649%2C1277619%2C1325632%2C1412791%2C1577916%2C1282096%2C1577272%2C1414636%2C1195477%2C1578024%2C1277650%2C1414506%2C1377971%2C1396889%2C1277646%2C1577275%2C1560666%2C1577650%2C1278314%2C1433418%2C1573733%2C1412734%2C1370133%2C1320656%2C1277647%2C1379032%2C1593703%2C1577915%2C1277624&list_id=14976398 https://bugzilla.mozilla.org/buglist.cgi?bug_id=1396098%2C13...
gumby 7y ago
> On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. auto_ptr has thankfully be removed, but if you have legacy code that uses it it won't compile under C++17. Of course if you have code that uses auto_ptr you should fix it, but realistically nobody has the time for that.
- ludamad 7y ago
  I mean, if tricky usage of auto_ptr is stopping you, you could probably use a drop-in replacement. But the 'and this adds to the sprint tasks how?' question still isn't answered in a good way
  - TillE 7y ago
    You could probably just find/replace unique_ptr. I'm pretty sure that's what I did a million years ago when auto_ptr was deprecated. C++17 does break some code by removing a few things, but they're pretty trivial and nothing sneaky.
    - tjalfi 7y ago
      clang-tidy has a command to replace auto_ptr with unique_ptr[0]. I haven't used it in anger, though. [0] https://clang.llvm.org/extra/clang-tidy/checks/modernize-replace-auto-ptr.html https://clang.llvm.org/extra/clang-tidy/checks/modernize-rep...
- MauranKilom 7y ago
  Depends on how much it was used. But I was part of the effort to convert to C++17 for our (substantial) C++ code base of ~30 years and it was not painful at all.
- twoodfin 7y ago
  I also ran up against the deprecation of std::mem_fun and std::mem_fun_ref in a recent migration. Easy enough to replace with lambda expressions, but one more hurdle to running C++17 code.

by w-m 7y ago

Fronzie 7y ago

For big (legacy) code-bases, just upgrading the compiler is a project by itself. All 3rd party C++ libs need to be upgraded, all internal projects need to upgrade in an orderly fashion. On top of that, just the change of the compiler will expose some pre-existing bugs.The bugs might have been there, but are not a problem for the business if they currently don't show. I've seen projects with a core team of half a dozen people, supported by the other SW engineers working for 6 months just to upgrade to a newer version of windows and the compiler. This was mostly due to unwise SW-design decisions accumulated over 15+ years.

w-m 7y ago
I totally agree, updating compilers is painful, and can be hard even for smaller projects. But for projects that went through that and actually got the newer compiler working with the C++11 code, I haven't yet seen anything that breaks compilation when then switching the compiler flag to C++14 mode.
jandrewrogers 7y ago
You raise a good point about newer compilers doing much deeper analysis of the code than older compilers. I have experienced the horror of compiling an old, nominally clean C++11 code base with the latest version of clang++ and seeing a small avalanche of errors and warnings that weren't picked up by the compiler when that code was written. It creates a lot of work, and frequently the nature of the bugs are not material (i.e. in context they may not produce a runtime fault), but I do find it to be good hygiene. I used to do builds with two different compilers for the same purpose, though that found compiler bugs as often as it found issues in the code.
d1zzy 7y ago
Plus, a lot of new library and language features are simply standardized versions of features that mature codebases had their own solutions for years, so "upgrading" to a newer C++ may also imply a long process of deprecating these alternatives in favor of standard ones, and the subtle differences between the two can expose new bugs and issues.
cpeterso 7y ago
Here is a list of some real-world examples of bugs that Mozilla had to fix when upgrading from Firefox from C++11 to C++14 to C++17 (still in progress). Many of these are compiler issues from upgrading to clang or gcc versions recent enough to support the new C++ versions, not C++ language changes. https://bugzilla.mozilla.org/showdependencytree.cgi?id=1560664&hide_resolved=0 https://bugzilla.mozilla.org/showdependencytree.cgi?id=15606...
- dgellow 7y ago
  Your link requires to be logged in to see the actual bug ticket.
  - cpeterso 7y ago
    Oops. Sorry! Here is a different view of the bugs. I verified this list didn't require Bugzilla account. https://bugzilla.mozilla.org/buglist.cgi?bug_id=1396098%2C1390524%2C1377959%2C1526245%2C1395722%2C1396892%2C1238661%2C1390640%2C1238635%2C1577869%2C1194806%2C1401226%2C1577867%2C1411692%2C1378600%2C1584296%2C1379835%2C1579189%2C1412825%2C1172109%2C1278868%2C1560667%2C1335710%2C1577910%2C1322792%2C1369992%2C1507636%2C1578107%2C1416183%2C1577326%2C1580028%2C1577934%2C1262052%2C1246772%2C1377962%2C1396862%2C1413555%2C1573820%2C1378830%2C1396867%2C1278871%2C1278861%2C1577871%2C1029346%2C1396863%2C1412513%2C1278863%2C1396864%2C1243331%2C1396850%2C1536848%2C1029245%2C1412988%2C1277236%2C1581941%2C1569728%2C1378605%2C1577583%2C1029325%2C1412405%2C1411694%2C1577831%2C1576751%2C1593673%2C1410959%2C1396865%2C1577319%2C1399315%2C1163171%2C1578025%2C1411613%2C1288442%2C1412547%2C1396869%2C1578535%2C1412546%2C1577932%2C1577885%2C1578876%2C1412785%2C1377970%2C1396882%2C1412888%2C1577936%2C1277853%2C1277649%2C1277619%2C1325632%2C1412791%2C1577916%2C1282096%2C1577272%2C1414636%2C1195477%2C1578024%2C1277650%2C1414506%2C1377971%2C1396889%2C1277646%2C1577275%2C1560666%2C1577650%2C1278314%2C1433418%2C1573733%2C1412734%2C1370133%2C1320656%2C1277647%2C1379032%2C1593703%2C1577915%2C1277624&list_id=14976398 https://bugzilla.mozilla.org/buglist.cgi?bug_id=1396098%2C13...

gumby 7y ago

> On the other hand, there aren't really any changes in 14 and 17 that break compatibility with code written in 11, at least that I'm aware of. auto_ptr has thankfully be removed, but if you have legacy code that uses it it won't compile under C++17. Of course if you have code that uses auto_ptr you should fix it, but realistically nobody has the time for that.

ludamad 7y ago
I mean, if tricky usage of auto_ptr is stopping you, you could probably use a drop-in replacement. But the 'and this adds to the sprint tasks how?' question still isn't answered in a good way
- TillE 7y ago
  You could probably just find/replace unique_ptr. I'm pretty sure that's what I did a million years ago when auto_ptr was deprecated. C++17 does break some code by removing a few things, but they're pretty trivial and nothing sneaky.
  - tjalfi 7y ago
    clang-tidy has a command to replace auto_ptr with unique_ptr[0]. I haven't used it in anger, though. [0] https://clang.llvm.org/extra/clang-tidy/checks/modernize-replace-auto-ptr.html https://clang.llvm.org/extra/clang-tidy/checks/modernize-rep...
MauranKilom 7y ago
Depends on how much it was used. But I was part of the effort to convert to C++17 for our (substantial) C++ code base of ~30 years and it was not painful at all.
twoodfin 7y ago
I also ran up against the deprecation of std::mem_fun and std::mem_fun_ref in a recent migration. Easy enough to replace with lambda expressions, but one more hurdle to running C++17 code.