C++0x: how to ask for a small addition? (syntax of pure virtual functions)

views:

337

answers:

+4 Q:

C++0x: how to ask for a small addition? (syntax of pure virtual functions)

Hi all.

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?

Thanks

+4 A:

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.

Richard 2009-05-12 12:07:41

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 2009-05-12 12:11:45

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 2009-05-12 13:32:49

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 2009-05-12 14:37:28

+3 A:

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

graham.reeds 2009-05-12 12:11:11

Ok, I'll try again, later... Thanks.

Gian Paolo Ghilardi 2009-05-12 12:13: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 2009-05-12 12:38:54

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 2009-05-12 13:30:27

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 2009-05-12 15:36:45

+25 A:

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. ;)

jalf 2009-05-12 12:12:24

I'm not an expert myself but I think *= pure*, used in that context, shouldn't break anything.Anyway, about the "pure as a new keyword" problem, I think you're right: I didn't consider that issue at all...Thanks.

Gian Paolo Ghilardi 2009-05-12 12:18:06

Thanks for this answer. It's interesting to realize that both default and delete already were c++ keywords, but in different contexts.

Benoît 2009-05-12 12:23:42

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 2009-05-12 12:39:47

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 2009-05-12 12:48:23

I wonder what about "= void" ?

Johannes Schaub - litb 2009-05-12 17:27:13

'= void' is a bit odd in that void is a type. I can't think of any other case where type keywords do double duty.

caspin 2009-05-12 19:06:57

I personally don't find it weird to call "undefined" the value of a null pointer. But that's just me. As to what could be gained, i don't know, i am just building up on what you said, which is that it is the biggest change in a language to add a keyword. I guess it means you have to make the most of it !

Benoît 2009-05-12 21:09:40

@Benoit: It's incorrect though. It is *not* undefined. It has a very specific and well-defined value. Most people are confused enough already about what is and isn't undefined. Void could work, as litb suggested, but if anything, I think it'd be more obvious to use the new null_ptr. That's essentially what a pure virtual function is anyway. And 0 is the "old" syntax for a null pointer as well.

jalf 2009-05-12 21:14:01

programming language D uses "void" in cases like "int a = void;" to say "don't initialize it" if i remember correctly.

Johannes Schaub - litb 2009-05-13 22:51:26

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 2009-05-13 23:00:12

By the way, it's nullptr, not null_ptr anymore.

Klaim 2009-05-14 00:03:22

+5 A:

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>

j_random_hacker 2009-05-12 13:22:10

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 2009-05-12 14:27:51

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 2009-05-12 14:30:30

Yes, it's a problem. I asked this question offering a simple proposal, not with perfect solution. Sorry... ^^'

Gian Paolo Ghilardi 2009-05-12 14:42:30

+1 A:

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.

Motti 2009-05-13 20:37:09

ansaurus

tags:

views:

answers:

C++0x: how to ask for a small addition? (syntax of pure virtual functions)

related questions