3 ms·

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

by 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.

by llukas 8y ago

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.