That must have broken a lot of peoples code bases right? Everyone who had a variable named "nullptr" (which I think would have been fairly common) has to find "nullptr" and replace with "something_else" before being able to compile with c++11.

Does the standards committee assume that people will do that much "adjusting"?

closed as primarily opinion-based by Kilian Foth, thorsten müller, user53019, M. Dudley, Jan Hudec Jul 22 '14 at 12:02

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    "Get away?" They're the standards committee, they make the rules. What are people going to do, topple them and rule themselves? Most committee members see the task as a necessary chore and would love to be replaced by others willing to put in the work. – Kilian Foth Jul 22 '14 at 10:53
  • 4
    I think it's standard and accepted practice that updating your code base to a newer standard is likely to involve at least some level of re-writing. It's not just variable names - what if part of your code turned out to be reliant on a bug or behaivour that has now been fixed/altered/removed? – Kai Jul 22 '14 at 10:57
  • 3
    @Wildling when nullptr isn't NULL then something is wrong with your code on a more fundamental problem – ratchet freak Jul 22 '14 at 11:05
  • 2
    @wildling It's too generic, says nothing about the context (null pointer of what to what?), violates the common coding standards (I would expect null_ptr or nullPtr), and I agree with the last comment of @ratchetfreak (what happens if the value of the variable is not NULL?) – sakisk Jul 22 '14 at 11:13
  • 8
    The committe website is at open-std.org/jtc1/sc22/wg21, and they have meeting minutes in their "mailings" section (along with all the proposals). – Bart van Ingen Schenau Jul 22 '14 at 11:38

The C++ standards committee is full of smart people that are fully aware of the amount of existing code and the consequences of introducing new keywords.

One of the aims of the committee is to keep as much existing code as possible working unchanged and that certainly plays a large role when deciding to add new keywords and how to name those keywords.

To my knowledge, when a new keyword is proposed, they perform an investigation over a number of large codebases to see how many conflicts that new keyword would create and if any of those conflicts would create a silent change in the behavior of the programs.

According to the proposal for adding nullptr, this spelling of the keyword resulted in the least amount of conflict with existing code:

  • Programmers have often requested that the null pointer constant have a name, and nullptr appears to be the least likely of the alternative text spellings to conflict with identifiers in existing user programs. For example, a Google search for nullptr cpp returns a total of merely 150 hits, only one of which appears to use nullptr in a C++ program.

    • The alternative name NULL is not available. NULL is already the name of an implementation-defined macro in the C and C++ standards. If we defined NULL to be a keyword, it would still be replaced by macros lurking in older code. Also, there might be code “out there” that (unwisely) depended on NULL being 0. Finally, identifiers in all caps are conventionally assumed to be macros, testable by #ifdef, etc.
    • The alternative name null is impractical. It is nearly as bad as NULL in that null is also a commonly used in existing programs as an identifier name and (worse) as a macro name. For example, a Google search for null cpp returns about 180,000 hits, of which an estimated 3% or over 5,000 use null in C++ code as an identifier or as a macro. Another favorite, nil, is worse still.
    • Any other name we have thought of is longer or clashes more often.

Given this analysis, I don't expect that that much adjustment needs to be done.
But otherwise, yes you are expected to update your codebase for the backwards-incompatible changes when moving to a new standard.

  • I just wonder, can you give some sources for their sweeps of a number of large codebases or is this smart guessing of best practise? – Trilarion Jul 22 '14 at 12:46
  • @Trilarion: I don't have any numbers. It is based on inference from snippets of online conversations. – Bart van Ingen Schenau Jul 22 '14 at 13:07

Introducing new language features and extensions, most of the time, require new language keywords or syntax changes. In addition, its essential to name these keywords for their intended purposes so as to help programmers memorize the new features. Fortunately, for that purpose, new language version/standards contain a list of code-breaking changes that you must consult before building the code with the new toolset.

Not the answer you're looking for? Browse other questions tagged or ask your own question.