Do you _actually_ use different compiles on different platforms at all ????
Yep.
'inline' is only a hint
Inline specifically means "export this as a weak symbol".
I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.
Yes, but why are you trying to do that? You're fighting the optimizer and you're almost certain to lose.
Nonetheless you're ignoring the other part of the reply that the C++ committe has in fact standardised a way of specifying attributes. Why don't you submit a paper specifying some always inline attribute?
You're constantly complaining about "breaking things." Gee, if only there was a way to migrate, mitigate, and deploy change ...
You wishing something to be the case dosen't make it happen. Unlike your silly car analogy, there is no government body who will arrest and detain anyone using C++98 after some flag day. As a result it will cause fragmentation just like Python 3.
Gee, why does Microsoft provide a _specific_ number for _each_ warning ???
Uh? Again, there is no language where error messages are standardised. The fact that MS provides numbers for each one is a total red herring. Like I said, complaining that the C++ committee have their heads up their arses because they're not standardising something that no other language spec ever standardised is basically idiotic.
But now you've wandered into bizarro world with warnings. So what would the procedure be? The warnings which a compiler is capable of emitting depend quite strongly on the code analaysis part which is in part dependent on the optimizer. There is no way to get GCC, LLVM, VS and ICC to have exactly the same set of warnings. And then what would the procedure be for new warning?
Seriously, the standards committee cannot make something happen by magic. If they try to do something that no one is going to implement then it's a pointless and destructive waste of time. They learned their lesson very well with exported templates. All sorts of people begged and whined for it, so they did it. They didn't listen to the howls of anguish from the compiler writers. All that happened was a dead stub of a standard which almost no compilers ever supported.
This is a solution in search of a problem.
So you're saying that the C++ commitee shouldn't be reading and considering every proposal that is submitted according to the correct procedures? So how should they filter them? Ask you and see if you give the thumbs up?
1. Completely failing to understand _practical_ matters.
Says the person who believes that by magic the C++ committee can make everyone switch to a new, incompatible language and avoid fragmentation! That's about the biggest practical matter and you claim outright that it doesn't exist. Then you rather hilariously accuse me of not understanding the practicalities.
OK, smart-ass, how would you force everyone to switch to a future non-backwards compatible version?
2. Continue to make excuses for why their tools are crap.
Tools are crap for reasons you haven't mentioned: namely it's sodding hard to parse C++. Because of (1) the committee can't fix that. But again, the OP complained that the "committee have their heads up their asses", which is a foolish and ignorant statement. There hasn't ever been a language standard which specifies the kind of tooling he was asking for.
And tools have nothing to do with the language standard.
3. And then post blatantly false information that gets modded up to Insightful without a clue.
Except nothing I said was false.