Take the 2-minute tour ×

In the current C++0x draft I've noticed they introduced some new explicit keywords to highlight expected behaviors (great move!).

Examples: defaulted/deleted functions (= default and = delete), the new nullptr constant, the explicit keyword usable also for conversion operators, ...

So I expected to see also a = pure syntax for pure virtual functions.

Instead the ugly (IMHO, of course) = 0 thing still exists.

Ok, I can use a #define pure 0 (and sometimes I do that), but I think coherency/consistency should be definitely a goal for a standard. Moreover I know it's just a sort of ultra-pedantic request, but = 0 was indeed one of my least favorite part of C++ (euphemism)...

My questions:

  • I know, the new standard is feature-complete, but is it still possible to ask for this small pedantic addition, even just as a "required macro" thing?
  • if the answer is positive, how? (any committee member around?)
  • am I just a bit too pedantic (or wrong) for asking this addition? what do you think about the current syntax of pure virtual functions?
share|improve this question
+1 from me btw. It's a perfectly good question, and I think the standards committee would love it if more people took an interest in their work. :) –  jalf May 12 '09 at 13:30
Thanks! As said in other comments I'm not an expert and I've just started reading the last draft (1347 pages)... –  Gian Paolo Ghilardi May 12 '09 at 14:20
add comment

5 Answers

up vote 28 down vote accepted

That's not a small pedantic change. Introducing a new keyword is one of the biggest changes you can ask for. It is something they try to avoid almost at any cost. Think of all the code that uses the word "pure", which would break.

In general, their guideline is to only add things to the language that could not be done before. A pure keyword wouldn't enable anything new (unlike the nullptr keyword, which enables better type checking, for example), so expect it to have a very low priority. Keep in mind that anything they do is basically maintenance work. The #1 goal is to avoid breaking the language (or existing code that uses it). Any features that are added on are only added if it can be done without breaking backward compatibility.

However, the committee is more or less an open forum. Browse around their website, and you should be able to find a few email addresses. OR use the comp.std.c++ newsgroup.

I believe their meetings are open as well, so you could just gatecrash the next one. ;)

share|improve this answer
Thanks for this answer. It's interesting to realize that both default and delete already were c++ keywords, but in different contexts. –  Benoît May 12 '09 at 12:23
One question though. They introduced "null_ptr" as a new keyword. Had they named it "undefined", it would have been logical to use it to define pure virtual functions, as suggested by Gian... Or am i dreaming ? :) –  Benoît May 12 '09 at 12:39
True, I suppose. But then it would have lost its meaning in the null pointer context. A null pointer is not undefined. It is null. You can compare it to other pointers, and get a consistent result. You can't do that with undefined values. And it would have confused existing C++ programmers. They know what a null pointer is, so they can guess what null_ptr means. But "undefined"? You have a point though, it's possible that they could have found a word that'd cover both cases. But again, how much would be gained by doing it? –  jalf May 12 '09 at 12:48
I wonder what about "= void" ? –  Johannes Schaub - litb May 12 '09 at 17:27
void generally has the meaning of expressing the absence of something. Like a cast to void expresses the absence of using the value computed. void in parameter lists expresses the absence of parameters and of course as a return type to express the absence of a return value. and =void would express the absence of an implementation, or more precisely the need of an implementation in a derived class. –  Johannes Schaub - litb May 13 '09 at 23:00
show 8 more comments

The thing you hate most about C++ is "= 0;"???

Have you ever used this language? There's plenty of other things you could be better spending your hate on.

<Flame retardant>I have used C++ for more than 10 years. For me it's still the language of choice whenever I need to do some computational heavy lifting.</Flame retardant>

share|improve this answer
It's not the worst thing of this language, IMHO (6+ years on this language, BTW). But I hate terribly this thing since my day one with C++ and when I saw the drafts (this and the previous one) I expected to see "something" on this front. Said in other words: I think this addition is so small that it could made into the next draft. I didn't expect the "as-a-new-keyword" issue as my "proposal" was restricted only to a "required macro". :) –  Gian Paolo Ghilardi May 12 '09 at 14:27
But a macro would cause even more problems. If it was a keyword, a compiler could limit the scope so that it doesn't affect variables or functions named "pure". But a macro would just substitute them all for 0. :) –  jalf May 12 '09 at 14:30
Yes, it's a problem. I asked this question offering a simple proposal, not with perfect solution. Sorry... ^^' –  Gian Paolo Ghilardi May 12 '09 at 14:42
add comment

First, start reading comp.std.c++ newsgroup. This is the place for public discussions.

Second, I would say that only errata will be applied to the current C++0x draft, the committee really is in the final stages.

If you are extremely keen, make your proposal in the newsgroup, with a really good justification. And expect it to be shot down. Substantially more useful proposals (e.g. modules) have not made it.

Addendum: If you want something like this to progress, you will need to either join (ANSI have of) the committee, or find someone on the committee to push your proposal.

share|improve this answer
Thanks for your question. I know my "proposal" is small, pedantic, secondary, ... but I'm not asking for the moon. Maybe I'm wrong but coherency and consistency are more important than the "addition" I'm asking. –  Gian Paolo Ghilardi May 12 '09 at 12:11
You are asking for the moon. As Jalf pointed out, you're asking for a new keyword that does not add any new expressiveness. BTW, Richard's answer is dead on. I've been shot down before in standards discussions. It isn't fatal. –  David Thornley May 12 '09 at 13:32
I absolutely agree with you (all) on: "no change on expressiveness" => "why to change, possibly breaking existing stuff?". You can consider my "proposal" as pure (LOL) aesthetical. I'd just like to avoid this: ... = delete; ... = default; ... = 0; If my "proposal" reads as "you're asking for the moon", I humbly retire that (really sorry - no joking). Thanks! :) –  Gian Paolo Ghilardi May 12 '09 at 14:37
add comment

Too late. The call for requests ended a couple of years ago.

(There was a page where the submissions were held but I can't find that list anymore.)

share|improve this answer
Ok, I'll try again, later... Thanks. –  Gian Paolo Ghilardi May 12 '09 at 12:13
Don't feel too bad - others suggested that originally. My suggestions were: deprecate int, short, etc. and replace with int8, int16, etc. And also deprecate char and new type of glyph which would be a template class representing unicode characters. –  graham.reeds May 12 '09 at 12:38
I believe that the C99 types (like int16_t) were accepted into the standard, but as typedefs you get by including a header file. The committee is extremely reluctant to introduce new keywords, but optional typedefs are far less likely to inconvenience anybody. –  David Thornley May 12 '09 at 13:30
Yes but I was annoyed by the extremely lackluster 'long long' for 64 bit types. What happens when we get to 128bit? 'long long long'? By defining the size of data types in the type itself you don't get this silly type a '>= type b' we have now and is obvious what you are using and makes porting code easier. –  graham.reeds May 12 '09 at 15:36
add comment

In addition to jalf's comment about the drawbacks of adding a keyword (with which I agree 100%) you should also note than in computer science the phrase pure function already has a meaning. It means that given the same parameters a function always returns the same value and has no side effects. So choosing = pure to indicate a virtual function which must be overridden would be a bad syntax choice.

share|improve this answer
add comment

Your Answer


