3 ms·

> All we need is a magic wand that works instantly and flawlessly. > That makes clang-tidy, if nothing else, a proof of concept. More like a proof of failure.

> All we need is a magic wand that works instantly and flawlessly. > That makes clang-tidy, if nothing else, a proof of concept. More like a proof of failure. Apply clang-tidy's transformations to source code and now you've now got one gigantic merge conflict to resolve every time you merge from upstream. That's partially fixable if you script your integration, or your integrators have good checklist discipline (they don't) and apply clang-tidy to new upstream commits before trying to merge them, and you've properly documented that. Downstream is more problematic. And in my experience, large merge conflicts like this are just begging for hard to spot bugs introduced by mismerging commits - much more common than I've noticed bugs from passing 0 to pointers or NULL to non-pointers. To add insult to injury, it'll fail to finish the job - for example, trivial edge cases like 0 being used in a macro which is interchangeably used to initialize ints and nullptrs depending on context - so now you need manual intervention to actually fix up the code enough to actually "break the egg". Not to mention NULL in C headers, as mentioned in the blog comments, being not a great thing to get rid of. > Experience shows that relying on compiler warnings to inform programmers about "bad" practices is not reliable. Get a bigger CI build matrix. This is a criticism of the implementation, and perhaps those who don't use warnings-as-errors - they have much bigger problems than a confusing 0/NULL/nullptr trifecta though. Standardize some warnings? Sure! We've been adding things like [[nodiscard]] that, while still not requiring warnings, strongly encourage them to the point of being just a hair's breadth away from standardization. Several compilers don't even like enabling new warnings by default - hence the -Wall -Wextra -Weffc++ -pedantic -etc -etc -etc dance, which still doesn't get everything you might want. If you want to change the culture around that so we opt out of warnings instead of opting in, sure, I'm on board with that. We already have the tooling to crank those up for your own code while using more permissive settings for third party code you'd rather not modify/break. If you can't convince compiler vendors to warn more by default, you're going to have even less luck getting them to break code by default (unless you can trick them into thinking it's an optimization). TL;DR: We've got more reasonable, less drastic tools. Maybe push those to be used more efficiently, instead of inviting a new Python 3 fiasco. I'm sure I'm not the only person who would jump to Rust (or Go, or Nim, or ...) instead of to C++vIncompatible - because if you're going to make a breaking change, why not break enough things to make it worthwhile?

llukas 8y ago
> Python 3 fiasco Python 3 - fiasco or not - happened and went away. C++ fiasco is still ongoing with no end in sight - both on tooling side and language complexity side.
- MaulingMonkey 8y ago
  > Python 3 - fiasco or not - happened and went away. Bullshit. I'm still encountering actively maintained Python 2 codebases. Just to take one concrete example - Maya scripts, where AFAIK Python 3 still isn't an option. https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-3-x/idi-p/7963375 https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-... links http://www.vfxplatform.com/ http://www.vfxplatform.com/ which implies the Python 3 transition has been pushed back to 2020. Maybe it's gone for you. Great, I'm happy for you. I'm still dealing with the aftermath of not having a clean incremental upgrade path, so you can see why I'm not in favor of adding more? At work, we recently postponed a transition to C++17 due to library compatibility issues. Which is a shame - I'd really like to be using [[nodiscard]] for some APIs on MSVC (we're using vendor attributes on clang at least, but not everyone compiles with clang first.) I'm sure you understand, then, why I'm hesitant to make upgrading even harder.
  - llukas 8y ago
    Python3 fixed issues with standard. In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. This has nothing to do with vendor refusing to upgrade.
    - MaulingMonkey 8y ago
      > In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. We agree there's a lot rotten with C++. I have a large list of complaints about C++ that's been growing for well over a decade now, but that's just what makes suggestions like this doubly frustrating. There's so much wrong with C++ that could be fixed, and non-issues with serious consequences to their "fixes" like "I can still use NULL" come up, distract and waste developer time (meaning less time can be spent on actual issues with real consequences), that suggest wasting even more time fixing what isn't broken. It's like some compulsion to make old code look new and shiny at all costs, even if s/NULL/nullptr/ is about as effective as putting lipstick on a pig in that regard. > This has nothing to do with vendor refusing to upgrade. I'm confused as to how an upgrade roadmap is "refusing to upgrade". You can see some of the minimum patch version bumps they've required in the tables I linked. Despite the fact that it's going to break things and leave downstream on older versions until they get a chance to make the upgrade. I've done the downstream fixes for Maya plugins before (D3D9 -> D3D11 for plugins that hook into the renderer), I'll probably end up doing the fixes for Maya python scripts broken by the 2 -> 3 upgrade whenever that lands too. The only way this is unrelated is if you live in a closed ecosystem where you have perfect control over your dependencies, no upstream or downstream to break compatability with, no branching to worry about, and a small or borderline inactive codebase where sweeping changes are trivial.

llukas 8y ago

> Python 3 fiasco Python 3 - fiasco or not - happened and went away. C++ fiasco is still ongoing with no end in sight - both on tooling side and language complexity side.

MaulingMonkey 8y ago
> Python 3 - fiasco or not - happened and went away. Bullshit. I'm still encountering actively maintained Python 2 codebases. Just to take one concrete example - Maya scripts, where AFAIK Python 3 still isn't an option. https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-3-x/idi-p/7963375 https://forums.autodesk.com/t5/maya-ideas/upgrade-to-python-... links http://www.vfxplatform.com/ http://www.vfxplatform.com/ which implies the Python 3 transition has been pushed back to 2020. Maybe it's gone for you. Great, I'm happy for you. I'm still dealing with the aftermath of not having a clean incremental upgrade path, so you can see why I'm not in favor of adding more? At work, we recently postponed a transition to C++17 due to library compatibility issues. Which is a shame - I'd really like to be using [[nodiscard]] for some APIs on MSVC (we're using vendor attributes on clang at least, but not everyone compiles with clang first.) I'm sure you understand, then, why I'm hesitant to make upgrading even harder.
- llukas 8y ago
  Python3 fixed issues with standard. In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. This has nothing to do with vendor refusing to upgrade.
  - MaulingMonkey 8y ago
    > In C++17 and any upcoming C++ standard you can still use all three of: NULL, 0 and nullptr just to name one issue. We agree there's a lot rotten with C++. I have a large list of complaints about C++ that's been growing for well over a decade now, but that's just what makes suggestions like this doubly frustrating. There's so much wrong with C++ that could be fixed, and non-issues with serious consequences to their "fixes" like "I can still use NULL" come up, distract and waste developer time (meaning less time can be spent on actual issues with real consequences), that suggest wasting even more time fixing what isn't broken. It's like some compulsion to make old code look new and shiny at all costs, even if s/NULL/nullptr/ is about as effective as putting lipstick on a pig in that regard. > This has nothing to do with vendor refusing to upgrade. I'm confused as to how an upgrade roadmap is "refusing to upgrade". You can see some of the minimum patch version bumps they've required in the tables I linked. Despite the fact that it's going to break things and leave downstream on older versions until they get a chance to make the upgrade. I've done the downstream fixes for Maya plugins before (D3D9 -> D3D11 for plugins that hook into the renderer), I'll probably end up doing the fixes for Maya python scripts broken by the 2 -> 3 upgrade whenever that lands too. The only way this is unrelated is if you live in a closed ecosystem where you have perfect control over your dependencies, no upstream or downstream to break compatability with, no branching to worry about, and a small or borderline inactive codebase where sweeping changes are trivial.