Hi,

the C++ committee is very restrictive in introducing new keywords in the
C++ standard. An example is the proposal for overriding virtual
functions. (Sad story is I don't know yet if it will be really in the
final draft).

It shall have the syntax:

virtual void foo() >= 0;
virtual void foo() >  0;

Where the natural "human" readable version would be IMHO:

virtual void foo() override abstract;
virtual void foo() override;

Would the introduction of new keywords really break that much "old" code
? I don't think so, if the keywords would be interpreted only in the
context of a function declaration so that old code:

class override {};

class sample : public base
{
   virtual void foo() override;
};

would still compile. Only code using

#define override _bad_style_either_

would break.
There are already C++ compilers introducing proprietary new context
sensitive keywords. I had no problem in compiling all my C++ code and
many open source libraries with such compilers.

Is it really worth to sacrifice readability, which also has an impact on
maintainability, for compatibility to some rare cases where macros are
used ? I would prefer readability and rather change my code.


-------------

Additionally it's commonly preferred to implement new functionality in
code, rather than introducing new keywords.
I just would it prefer the other way round, because commonly the
compiler can be more effective and handling is commonly easier by using
a new keyword than a big template library.

E.g.: member function pointers.

It's impressive how much can be done in plain "old" C++98, but
nevertheless I think the compiler could handle member function pointers
more effective than a library. Additionally I wouldn't have to know
which library I have to include and additionally wouldn't have to
increase compilation time due to the inclusion of the library.


Andre


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 27, 11:13 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:
> There are already C++ compilers introducing proprietary new context
> sensitive keywords. I had no problem in compiling all my C++ code and
> many open source libraries with such compilers.

The problem isn't whether *a* compiler can support context-sensitive
keywords, it's whether *every* compiler can support context-sensitive
keywords. There are compiler implementers on the committee that
strongly object to context-sensitive keywords, because their parsers
would require a significant re-write to support such a feature.
Without studying their compiler, I can't evaluate how significant that
rewrite would be... but, in general, it's best to listen to those few
people who have implemented C++ compilers when evaluating new
features.

> Is it really worth to sacrifice readability, which also has an impact on
> maintainability, for compatibility to some rare cases where macros are
> used ? I would prefer readability and rather change my code.

Yet there are many C++ users who do not want to change their code.
There is a lot of give-and-take when evolving a language, because you
need to balance the needs of large-scale users who can't easily just
"change their code" (because most of the code isn't theirs) against
the needs of new features. The greater sacrifice in maintainability is
breaking existing code that works perfectly well today, for some small
perceived gain in readability.

Some ideas require new keywords and new syntax, that's certain. But
not all new features need their own syntax, and one can often work
within the confines of the language to find a syntax that is both
readable and maintains backward compatibility. Unfortunately, context-
sensitive keywords are not a mechanism to help with this.

  - Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> On May 27, 11:13 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:
>> There are already C++ compilers introducing proprietary new context
>> sensitive keywords. I had no problem in compiling all my C++ code and
>> many open source libraries with such compilers.
>

Thanx for the answer.

> The problem isn't whether *a* compiler can support context-sensitive
> keywords, it's whether *every* compiler can support context-sensitive
> keywords. There are compiler implementers on the committee that
> strongly object to context-sensitive keywords, because their parsers
> would require a significant re-write to support such a feature.

Well, in the case of override > or >= must be context sensitive either.
Otherwise it would be interpreted as an operator. So I don't see a
problem to change > to a keyword override, which doesn't conflict with a
class named override, only with a macro called override.

> Without studying their compiler, I can't evaluate how significant that
> rewrite would be... but, in general, it's best to listen to those few
> people who have implemented C++ compilers when evaluating new
> features.

Well, I think we all agree to the fact that writing a parser for C++ is
not that simple, it's rather complex compared to other languages.

So an argumentation from compiler implementers that it would be need a
significant rewrite is Perhaps only an excuse -> no additional work.
And the they wouldn't have to implement the keywords context sensitive,
  they would "only" have to accept to break more code.

And in the context of "export of templates", which surely is more
complex to implement than context sensitive keywords, I can't understand
such an argumentation (from the compiler implementers).

>> Is it really worth to sacrifice readability, which also has an impact on
>> maintainability, for compatibility to some rare cases where macros are
>> used ? I would prefer readability and rather change my code.
>
> Yet there are many C++ users who do not want to change their code.

Well as I already wrote, context sensitive keywords don't break that
much code, if at all. I've searched the web for #define override with
code search websites and hadn't a single hit.

> There is a lot of give-and-take when evolving a language, because you
> need to balance the needs of large-scale users who can't easily just
> "change their code" (because most of the code isn't theirs) against
> the needs of new features. The greater sacrifice in maintainability is
> breaking existing code that works perfectly well today, for some small
> perceived gain in readability.

A large code base which is easier to maintain and read isn't it worth to
break perhaps a single source line out of millions ? So millions of C++
programmers have to pay (readability and maintainability) for a small
code base, which can't be changed, which I can's believe. By the way
they wouldn't have to migrate (that fast) to a new compiler either.

> Some ideas require new keywords and new syntax, that's certain. But
> not all new features need their own syntax, and one can often work
> within the confines of the language to find a syntax that is both
> readable and maintains backward compatibility. Unfortunately, context-
> sensitive keywords are not a mechanism to help with this.

Well, I think some real world implementations proof the opposite.
Currently I have the feeling that maintainability and readability and
their side effects are underestimated by the C++ committee (I don't mean
that they don't care, but rather care too much for arguments against them.

Simple example: If I want to search my code base for overridden
functions in the case of the keyword override I simply could search for
"override". In the case of >, well I need context sensitive search or
regular expressions, which makes it quite hard for IDE implementers and
users to implement/do such a search.

Another example would be C++ modules (which IMHO should have been
already in the last TR instead of template export). If I have a look at
the other languages, which are evolving much much faster and are able to
keep up with the hardware changes (multi cores etc.) and how much easier
and faster it is to implement IDE features (refactoring, context
sensitive help etc.) I sometimes have the feeling that C++ somewhat
falls behind of them all.

Don't get me wrong, I have great respect of the very good and !hard!
work of the C++ committee, but in some points I just think different
(perhaps I don't know all the facts), but I'm programming in many
different languages and I can see how much they evolve (easily).

>   - Doug

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Douglas Gregor wrote:
>> On May 27, 11:13 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:
>>> There are already C++ compilers introducing proprietary new context
>>> sensitive keywords. I had no problem in compiling all my C++ code and
>>> many open source libraries with such compilers.
>>
>
> Thanx for the answer.
>
>> The problem isn't whether *a* compiler can support context-sensitive
>> keywords, it's whether *every* compiler can support context-sensitive
>> keywords. There are compiler implementers on the committee that
>> strongly object to context-sensitive keywords, because their parsers
>> would require a significant re-write to support such a feature.
>
> Well, in the case of override > or >= must be context sensitive either.

Not in quite the same way.

> Otherwise it would be interpreted as an operator.

A strange viewpoint; operators appear only inside expressions.
In this sense *everything* in a grammar is context-sensitive.
But it doesn't seem a useful way of looking at things.

> So I don't see a
> problem to change > to a keyword override, which doesn't conflict with a
> class named override, only with a macro called override.

It was clear from your first post that you think so, but the
prevailing opinion from the committee doesn't agree.  Adding
context-sensitive keywords is perceived as being good for
neither users nor implementors, as it adds disproportional
complexity (compared to its benefit) to an already complex
language.

>> Without studying their compiler, I can't evaluate how significant that
>> rewrite would be... but, in general, it's best to listen to those few
>> people who have implemented C++ compilers when evaluating new
>> features.
>
> Well, I think we all agree to the fact that writing a parser for C++ is
> not that simple, it's rather complex compared to other languages.

An understatement, I would say.  Parsing C++ requires
implementation of a good fraction of the compiler
front-end.

> So an argumentation from compiler implementers that it would be need a
> significant rewrite is Perhaps only an excuse -> no additional work.

I wouldn't write off the issue so lightly; if it's a
large enough amount of work, it might not make financial
sense for them to do it.  There's a clear interest in
the committee in a standard which will be adopted.

> And the they wouldn't have to implement the keywords context sensitive,
>  they would "only" have to accept to break more code.

Then they'd be implementing a different language, not
C++-with-context-sensitive-keywords.  We do not want
to split C++ into multiple incompatible communities.

> And in the context of "export of templates", which surely is more
> complex to implement than context sensitive keywords, I can't understand
> such an argumentation (from the compiler implementers).

Implementors did raise many objections to "export", and
perhaps rightly so, but it was included in C++98 anyway,
and in some senses has been a failure -- in practice it
is the least observed feature in C++98.  History teaches
us to listen to the objections of implementors.

>>> Is it really worth to sacrifice readability, which also has an impact on
>>> maintainability, for compatibility to some rare cases where macros are
>>> used ? I would prefer readability and rather change my code.
>>
>> Yet there are many C++ users who do not want to change their code.
>
> Well as I already wrote, context sensitive keywords don't break that
> much code, if at all. I've searched the web for #define override with
> code search websites and hadn't a single hit.

Let's be clear: the problems of context-sensitive keywords
are mostly readability and implementation costs.  The problem
of new non-context-sensitive keywords is large scale breakage
of code and interfaces.

>> There is a lot of give-and-take when evolving a language, because you
>> need to balance the needs of large-scale users who can't easily just
>> "change their code" (because most of the code isn't theirs) against
>> the needs of new features. The greater sacrifice in maintainability is
>> breaking existing code that works perfectly well today, for some small
>> perceived gain in readability.
>
> A large code base which is easier to maintain and read isn't it worth to
> break perhaps a single source line out of millions ?

Introducing new keywords usually breaks a lot more than
that; you can read a recent committee paper on how widely
used certain proposed keywords were in some code samples.

> So millions of C++
> programmers have to pay (readability and maintainability) for a small
> code base, which can't be changed, which I can's believe. By the way
> they wouldn't have to migrate (that fast) to a new compiler either.

You might be surprised at the cost estimates some companies
have for moving to a different/binary incompatible compiler.
I have been.

>> Some ideas require new keywords and new syntax, that's certain. But
>> not all new features need their own syntax, and one can often work
>> within the confines of the language to find a syntax that is both
>> readable and maintains backward compatibility. Unfortunately, context-
>> sensitive keywords are not a mechanism to help with this.
>
> Well, I think some real world implementations proof the opposite.

I think they don't _prove_ it.

> Currently I have the feeling that maintainability and readability and
> their side effects are underestimated by the C++ committee (I don't mean
> that they don't care, but rather care too much for arguments against them.

That doesn't match my experience at all; I hardly know of
a group of people who are *more* concerned about maintainability
and readability of code (and yes, those on the committee are
collectively responsible for upwards of 100M LOC, they don't
want that code to be unreadable).

> Simple example: If I want to search my code base for overridden
> functions in the case of the keyword override I simply could search for
> "override". In the case of >, well I need context sensitive search or
> regular expressions, which makes it quite hard for IDE implementers and
> users to implement/do such a search.

Various tools can do this today.

(On the specific note of using symbols instead of an
"override" keyword, I personally dislike the proposal
to use symbols.  But that's neither here nor there.)

> Another example would be C++ modules (which IMHO should have been
> already in the last TR instead of template export).

The C++ TRs haven't added any support for "export", so
I don't know what you're talking about here.

> If I have a look at
> the other languages, which are evolving much much faster and are able to
> keep up with the hardware changes (multi cores etc.) and how much easier
> and faster it is to implement IDE features (refactoring, context
> sensitive help etc.) I sometimes have the feeling that C++ somewhat
> falls behind of them all.

C++ is used for a lot of high-performance code on machines
that newer languages don't handle very well yet; don't be
fooled just because not all C++ is covered by the standard.

Refactoring for C++ *is* a tough thing, because of the
complexity of parsing/name lookup in C++, and that's a result
of history, and can't be addressed without huge breaks in
backwards compatibility.  Score one for non-C++ languages.

> Don't get me wrong, I have great respect of the very good and !hard!
> work of the C++ committee, but in some points I just think different
> (perhaps I don't know all the facts), but I'm programming in many
> different languages and I can see how much they evolve (easily).

C++ provides stability while evolving, much more so than
most other languages.  That's a side-effect of the ISO
process, which *does* slow down change.  Standardization,
as with most things, has costs as well as benefits.
Fortunately vendors implement a huge range of extensions
to support facilities before they are standardized, and
to support facilities that are likely never to become
part of standard C++.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 30, 3:19 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
> Douglas Gregor wrote:
> > The problem isn't whether *a* compiler can support context-sensitive
> > keywords, it's whether *every* compiler can support context-sensitive
> > keywords. There are compiler implementers on the committee that
> > strongly object to context-sensitive keywords, because their parsers
> > would require a significant re-write to support such a feature.
>
> Well, in the case of override > or >= must be context sensitive either.

The tokens ">" and ">=" are always tokens; they can never be anything
else. The issue with a context-sensitive keyword like "override" is
that it is sometimes and token and sometimes an identifier. In a
compiler that has a rigid separation between the lexer/tokenizer and
parser, context-sensitive keywords can be a problem. I suspect this is
the issue.

> So an argumentation from compiler implementers that it would be need a
> significant rewrite is Perhaps only an excuse -> no additional work.

Compiler implementers have accepted work that is far more complicated
and time-consuming than what you're proposing. They aren't being laze
or making excuses; they're being pragmatic.

> And in the context of "export of templates", which surely is more
> complex to implement than context sensitive keywords, I can't understand
> such an argumentation (from the compiler implementers).

"export" is a sad story. Implementers knew that "export" was extremely
complicated to implement and would not bring the benefits that the
proponents of "export" claimed, and the implementers voted strongly
against "export". However, the promise of "separate compilation of
templates" won over the non-implementers on the committee, and we are
now stuck with a feature that is extremely complicated to implement
and is almost entirely useless. At least it serves as a sobering
reminder that when an implementer says there is a problem implementing
a particular feature, we would all do well to listen.

> Simple example: If I want to search my code base for overridden
> functions in the case of the keyword override I simply could search for
> "override".

Only if the code is C++0x with an "override" extension. You're not
proposing that the *only* way to override a virtual function is with
the "override" keyword, are you? That would break every existing C++
program that uses object-oriented techniques! However, if you don't
require the "override" keyword, then your argument about searching the
code base for overriddes doesn't hold up, because you won't find all
of the overrides that way.

There's a trap that's very easy to fall into when trying to fix
problems in the current language. There's a tendency to want to add
features that do things the way that we wish they were always done...
enums that don't convert to integers, classes that don't have implicit
copy constructors, etc. The problem with adding these new entities
that are somewhat like the old entities (but slightly different) is
that they will never, ever completely "fix" the problem: somebody will
still use the old entities, and now everyone has to recognize both
forms, their similarities, and their subtle differences. Yes, new code
using the new forms might be a little more obvious, but none of those
benefits scale to real programs.

> Another example would be C++ modules (which IMHO should have been
> already in the last TR instead of template export).

C++ certainly needs modules. Daveed Vandevoorde has a very promising
proposal for module support in C++; it's not slated for C++0x (because
it wasn't far enough along), but should be in a separate TR. We'll
see.

> If I have a look at
> the other languages, which are evolving much much faster and are able to
> keep up with the hardware changes (multi cores etc.) and how much easier
> and faster it is to implement IDE features (refactoring, context
> sensitive help etc.) I sometimes have the feeling that C++ somewhat
> falls behind of them all.
>
> Don't get me wrong, I have great respect of the very good and !hard!
> work of the C++ committee, but in some points I just think different
> (perhaps I don't know all the facts), but I'm programming in many
> different languages and I can see how much they evolve (easily).

I completely agree. C++ really has two problems in this area... the
first problem is that it's extremely complicated to parse C++,
especially C++ templates, so few developers are willing to take on
that challenge to  build C++ development tools. The second problem
(from this perspective) is that there are many implementations of C++.
With most other languages in use today, there is only a single
implementation that matters: Microsoft's C# compiler, the standard
Python interpreter, the standard Perl interpreter, Java's Sun
compiler, etc. That one implementation, typically driven by a small
team or a company, can move *fast* to get new features out to users. C+
+ isn't like that: there are many implementations, all based on an
agreed-upon standard. It's both a blessing and a curse... if you get
fed up with your C++ vendor, just go to another one. But, it means
that for a feature to be usable in C++ it needs to be implemented in
the vast majority of those implementations.

  - Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 30, 5:12 am, Douglas Gregor <doug.gre...@gmail.com> wrote:
> On May 27, 11:13 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:

> > There are already C++ compilers introducing proprietary new context
> > sensitive keywords. I had no problem in compiling all my C++ code and
> > many open source libraries with such compilers.

> The problem isn't whether *a* compiler can support context-sensitive
> keywords, it's whether *every* compiler can support context-sensitive
> keywords.

The problem isn't whether a compiler can support
context-sensitive keywords.  It's whether a human reader can
support them.  C++ is hard enough to read as it is, without
adding context-sensitive keywords.

    [...]
> Some ideas require new keywords and new syntax, that's certain. But
> not all new features need their own syntax, and one can often work
> within the confines of the language to find a syntax that is both
> readable and maintains backward compatibility. Unfortunately, context-
> sensitive keywords are not a mechanism to help with this.

Not a good mechanism, anyway.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 28, 5:13 am, akfmn...@t-online.de (Andre Kaufmann) wrote:

> the C++ committee is very restrictive in introducing new keywords in the
> C++ standard.

Because the might break existing code.

> An example is the proposal for overriding virtual
> functions. (Sad story is I don't know yet if it will be really in the
> final draft).

> It shall have the syntax:

> virtual void foo() >= 0;
> virtual void foo() >  0;

> Where the natural "human" readable version would be IMHO:

> virtual void foo() override abstract;
> virtual void foo() override;

> Would the introduction of new keywords really break that much
> "old" code ? I don't think so, if the keywords would be
> interpreted only in the context of a function declaration so
> that old code:

Context dependent keywords is a slippery slope, that I don't
think anyone really wants to go down.  They make understanding
the language considerably more difficult.

On the other hand, I'm not really sure that adding "override" as
a keyword would break that many programs (I'm less sure about
abstract).  More importantly, if the keyword is only legal in
this context, any that it breaks would break at compile time.
In this case, I'd go with the keyword, despite breakage.

    [...]
> Additionally it's commonly preferred to implement new functionality in
> code, rather than introducing new keywords.

You mean in the library, rather than in the language.  There are
a number of advantages to introducing new features in the
library, when it works.

> I just would it prefer the other way round, because commonly the
> compiler can be more effective and handling is commonly easier by using
> a new keyword than a big template library.

> E.g.: member function pointers.

I don't follow you here.  Pointers to member functions aren't a
new concept, and they're part of the language.

> It's impressive how much can be done in plain "old" C++98, but
> nevertheless I think the compiler could handle member function pointers
> more effective than a library.

Only the language can handle them.  That's why they're part of
the language.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> On May 28, 5:13 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
> [...]
>> E.g.: member function pointers.
>=20
> I don't follow you here.  Pointers to member functions aren't a
> new concept, and they're part of the language.

Yes. But besides an ugly syntax, I can't specify an member function=20
pointer not bound to a specific object. A generic callback function.

>> It's impressive how much can be done in plain "old" C++98, but
>> nevertheless I think the compiler could handle member function pointer=
s
>> more effective than a library.
>=20
> Only the language can handle them.  That's why they're part of
> the language.

I rather referred to boost::function, which isn't supported by the=20
language.

Example:

boost::function<float (int x, int y)> f;

IMHO it would be more efficient (for the resulting code and compilation=20
time) to implement this in the language directly.

Andre

> --
> James Kanze (GABI Software)             email:james.kanze@gmail.com
> Conseils en informatique orient=E9e objet/
>                    Beratung in objektorientierter Datenverarbeitung
> 9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Douglas Gregor wrote:
>> The problem isn't whether *a* compiler can support context-sensitive
>> keywords, it's whether *every* compiler can support context-sensitive
>> keywords. There are compiler implementers on the committee that
>> strongly object to context-sensitive keywords, because their parsers
>> would require a significant re-write to support such a feature.
>
> Well, in the case of override > or >= must be context sensitive either.
> Otherwise it would be interpreted as an operator. So I don't see a
> problem to change > to a keyword override, which doesn't conflict with a
> class named override, only with a macro called override.

C++ evolved on a path deliberately chosen to separate tokenization from
parsing.  This is a very big win in specifying the language as the
productions involving keywords are specified as simply yet exactly as
those involving punctuation.  For an ugly example of the opposite
extreme, search out how the "for" statement is recognized in Fortran.
Unfortunately (because I like keywords) this makes adding a new keyword
expensive because it breaks existing programs.

As I understand the proposal, ">" and ">=" remain the same tokens they
now are, but can be parsed in a new context.  (They are not operators
unless and until the parser has matched them to a production labelling
them so.)

>> Without studying their compiler, I can't evaluate how significant that
>> rewrite would be... but, in general, it's best to listen to those few
>> people who have implemented C++ compilers when evaluating new
>> features.
>
> Well, I think we all agree to the fact that writing a parser for C++ is
> not that simple, it's rather complex compared to other languages.
>
> So an argumentation from compiler implementers that it would be need a
> significant rewrite is Perhaps only an excuse -> no additional work.
> And the they wouldn't have to implement the keywords context sensitive,
>  they would "only" have to accept to break more code.

I'll defer to anyone with budgetary experience on the likelihood of a
rewrite or other major compiler work.  But on the last point, a partial
implementation of the next standard is utterly useless.  Imagine telling
the customer that you have 90% of the standard and it breaks more of the
user's code than your competitor's compiler.

> A large code base which is easier to maintain and read isn't it worth to
> break perhaps a single source line out of millions ? So millions of C++
> programmers have to pay (readability and maintainability) for a small
> code base, which can't be changed, which I can's believe. By the way
> they wouldn't have to migrate (that fast) to a new compiler either.

It seems like the language committee has a very small budget for
incompatible changes, and if they go over the limit then the language
will fragment as significant numbers of users will choose to stay with
the version that works for them.

When you say "gradual migration" management likely hears "prolonged
period of no productivity followed by customer complaints of the same".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Dennett wrote:
> Andre Kaufmann wrote:
> [...]
> Not in quite the same way.

>> Otherwise it would be interpreted as an operator.
> A strange viewpoint; operators appear only inside expressions.
> In this sense *everything* in a grammar is context-sensitive.
> But it doesn't seem a useful way of looking at things.

Well, I'm not an expert regarding compiler technology nor an native
English speaker so I express it perhaps not that specific as you are
used to. It's not my intention to mix up the different compiler stages,
sorry if I do in my naive way. You are the expert.

I see only that a single character commonly an operator is IMHO misused
as an keyword. In the case of override it's ">". Only in view of the
programmer, the scanner, tokenizer of the compiler doesn't care about, I
know.

>> So I don't see a
>> problem to change > to a keyword override, which doesn't conflict with a
>> class named override, only with a macro called override.
>
> It was clear from your first post that you think so, but the

Thanx. Same applies to you ;-)

> prevailing opinion from the committee doesn't agree.  Adding
> context-sensitive keywords is perceived as being good for
> neither users nor implementors, as it adds disproportional
> complexity (compared to its benefit) to an already complex
> language.

It would IMHO be more readable for C++ starters, which are used to
"override" and "abstract".

> [...]
> An understatement, I would say.  Parsing C++ requires
> implementation of a good fraction of the compiler
> front-end.

Yes. C++ can't be expressed (AFAIK) in a simple EBNF grammar. But the
work is already done (should be done).

Sorry for not being an expert in this regard, but I can't think why it
would be that complex if the interpreter, which already knows that it's
interpreting a function, can't distinguish if the token "override" is a
keyword or a class.

>[...]
>> And the they wouldn't have to implement the keywords context sensitive,
>>  they would "only" have to accept to break more code.
>
> Then they'd be implementing a different language, not
> C++-with-context-sensitive-keywords.  We do not want
> to split C++ into multiple incompatible communities.

Well I think it's done already. There aren't many 100% standard
compliant C++ compilers - if there are.

 >[...]
> Let's be clear: the problems of context-sensitive keywords
> are mostly readability and implementation costs.  The problem
> of new non-context-sensitive keywords is large scale breakage
> of code and interfaces.

Well I'm dealing with 6 C++ compilers. One of them has many new context
sensitive keywords (not C++). And this hasn't broken any line of code
yet. Perhaps my code base isn't large enough.

> [...]
> Introducing new keywords usually breaks a lot more than
> that; you can read a recent committee paper on how widely
> used certain proposed keywords were in some code samples.

Not if they are context sensitive.

> [...]
>
> You might be surprised at the cost estimates some companies
> have for moving to a different/binary incompatible compiler.
> I have been.

I (think I) know. I'm dealing with several C++ compilers and languages
at once using the same code base. It's hard to get them compile the same
standard compliant C++ code.

 >[...]
>> Well, I think some real world implementations proof the opposite.
>
> I think they don't _prove_ it.

It's your opinion. The compiler I referring to has saved me much time in
searching for the function which has not been overridden, because the
base class implementation has changed. It's using a context sensitive
override keyword and doesn't break a single line of C++ code using
"override", except preprocessed code using #define override.

> [...]
>
> That doesn't match my experience at all; I hardly know of
> a group of people who are *more* concerned about maintainability
> and readability of code (and yes, those on the committee are
> collectively responsible for upwards of 100M LOC, they don't
> want that code to be unreadable).

Then perhaps module concept should have a higher priority
(maintainability), some ugly syntax "member function pointers" should
have been deprecated .....


> [...]
> Various tools can do this today.

Well, it's now up to the programmer to do that. And the ones
implementing such tools, which means that there aren't many of them.

>
> (On the specific note of using symbols instead of an
> "override" keyword, I personally dislike the proposal
> to use symbols.  But that's neither here nor there.)
>
>> Another example would be C++ modules (which IMHO should have been
>> already in the last TR instead of template export).
>
> The C++ TRs haven't added any support for "export", so
> I don't know what you're talking about here.

Has template export already been in C++98 ? Sorry for my mistake.

 > [...]
> C++ provides stability while evolving, much more so than
> most other languages.  That's a side-effect of the ISO
> process, which *does* slow down change.  Standardization,
> as with most things, has costs as well as benefits.
> Fortunately vendors implement a huge range of extensions
> to support facilities before they are standardized, and
> to support facilities that are likely never to become
> part of standard C++.

Well perhaps there should be some kind of fast track C++, which is about
to be changed and resynchronized with the ISO C++. I know that stability
is the basis of the success of C++.

> -- James

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 31, 2:29 pm, James Kanze <james.ka...@gmail.com> wrote:
> On May 28, 5:13 am, akfmn...@t-online.de (Andre Kaufmann) wrote:
>
> > the C++ committee is very restrictive in introducing new keywords in the
> > C++ standard.
>
> Because the might break existing code.
>
>
> Context dependent keywords is a slippery slope, that I don't
> think anyone really wants to go down.  They make understanding
> the language considerably more difficult.

I don't have a problem with the proposal.  His arguments are
persuasive.  I'm not crazy about how the language permits
context sensitive type name semantics.  Some keywords are
also type names and those you can't "overload."  Which way
is the standard heading?  Will it someday be possible to get
rid of the big in bigint or should it go back to its C roots in
this respect?

I remember Stroustrup saying he didn't want UDTs to be
second class citizens.  It seems in some ways the standard
went too far in that UDTs can be overloaded but the standard/
built-in types can't be.   A new Boost library called Intrusive
originally had a type called ilist.  In the review a number of
people said they preferred to change it to just list and use
namespaces to differentiate things.  I said what if this library
becomes part of the standard?  The reply was that std is
getting cluttered and should be segregated with namespaces.
If there are just two "list"s in std it isn't too bad, but the
slippery slope part comes in in that once you have more than
one there's no clear boundary.  There could be proposals to add
more "list"s in the future and IMO that gets too confusing. You
have to be familiar with all of them to be sure you are reading
the code correctly.  I don't think the OP's proposal would make
things similarly confusing.

Brian Wood
Ebenezer Enterprises

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> On May 30, 3:19 am, Andre Kaufmann <akfmn...@t-online.de> wrote:
>> Douglas Gregor wrote:
> [...]
> The tokens ">" and ">=" are always tokens; they can never be anything
> else.

I meant how the tokens are interpreted, sorry for not being precise
enough. I meant the parser stage.

> The issue with a context-sensitive keyword like "override" is
> that it is sometimes and token and sometimes an identifier. In a
> compiler that has a rigid separation between the lexer/tokenizer and
> parser, context-sensitive keywords can be a problem. I suspect this is
> the issue.

I suspect that the lexer/tokenizer will/could stop, when it sees the
terminating ";" char of a function or the "{"  char of a function block.
Or it may continue, in the case of a rigid separation as you assumed to
be the problem. But IMHO it doesn't matter that match. It's up to the
parser to decide if the keyword override in the context of a function is
a keyword and not a class / variable named override.

>> So an argumentation from compiler implementers that it would be need a
>> significant rewrite is Perhaps only an excuse -> no additional work.
>
> Compiler implementers have accepted work that is far more complicated
> and time-consuming than what you're proposing.

Exactly ! ;-)

> They aren't being laze
> or making excuses; they're being pragmatic.

Perhaps I would argue the same way as a compiler implementer. Though I
can't understand it really if I think about what they had already to
implement.

>> And in the context of "export of templates", which surely is more
>> complex to implement than context sensitive keywords, I can't understand
>> such an argumentation (from the compiler implementers).
>
> "export" is a sad story. Implementers knew that "export" was extremely
> complicated to implement and would not bring the benefits that the
> proponents of "export" claimed, and the implementers voted strongly
> against "export". However, the promise of "separate compilation of
> templates" won over the non-implementers on the committee, and we are
> now stuck with a feature that is extremely complicated to implement
> and is almost entirely useless. At least it serves as a sobering
> reminder that when an implementer says there is a problem implementing
> a particular feature, we would all do well to listen.

Agreed. Module concept would have solved many issues, that template
export should have addressed, too.
In the case of context sensitive keywords they are real world
implementations already.

>> Simple example: If I want to search my code base for overridden
>> functions in the case of the keyword override I simply could search for
>> "override".
>
> Only if the code is C++0x with an "override" extension. You're not
> proposing that the *only* way to override a virtual function is with
> the "override" keyword, are you?

No. Currently it's up to the compiler to decide if a function matches a
base class virtual function. I only want to express that I want to
override a function and that the compiler shall throw an error if there
isn't a matching function to override. I simply have no chance in a
large code base to check if the code is still o.k. if a change a virtual
function in a base class. And most arguments I read about that I'm
missing override, which isn't perhaps not in the next standard (???)
that it's only a minor problem. Yes it is minor, but in the case of base
class changes it's a huge one and it's IMHO peanuts for compiler
implementers to implement it.

> That would break every existing C++
> program that uses object-oriented techniques! However, if you don't
> require the "override" keyword, then your argument about searching the
> code base for overriddes doesn't hold up, because you won't find all
> of the overrides that way.

It should be only an example, why it's different to have a keyword
rather than a single ">" character. That the whole code base won't
change over night is clear, we would/will have to live with that fact :-/.

> There's a trap that's very easy to fall into when trying to fix
> problems in the current language. There's a tendency to want to add
> features that do things the way that we wish they were always done...
> enums that don't convert to integers,

Enums, good that you write it - they need a size specifier ;-9

> classes that don't have implicit
> copy constructors,

Hm, AFAIK part of the standard isn't it ?

> etc. The problem with adding these new entities
> that are somewhat like the old entities (but slightly different) is
> that they will never, ever completely "fix" the problem: somebody will
> still use the old entities, and now everyone has to recognize both
> forms, their similarities, and their subtle differences. Yes, new code
> using the new forms might be a little more obvious, but none of those
> benefits scale to real programs.

I agree. Sometimes you can add changes only if you make a hard break in
compatibility or you have to "live" with the old implementation.
I don't take the problems the C++ committee has to care about too
lightly (I hope so at least). But a language evolving only at the level
of the least common denominator, might be evolving to slowly. It should
be IMHO some kind of middle course and sometimes, it's hard I know, you
have to cut down some old "blocking" obstacles or the language will get
more and more and more complex till it ......

>> Another example would be C++ modules (which IMHO should have been
>> already in the last TR instead of template export).
>
> C++ certainly needs modules. Daveed Vandevoorde has a very promising
> proposal for module support in C++; it's not slated for C++0x (because
> it wasn't far enough along), but should be in a separate TR. We'll
> see.

I don't think C++ will survive without them.

> [...]
> I completely agree. C++ really has two problems in this area... the
> first problem is that it's extremely complicated to parse C++,
> especially C++ templates, so few developers are willing to take on
> that challenge to  build C++ development tools. The second problem
> (from this perspective) is that there are many implementations of C++.
> With most other languages in use today, there is only a single
> implementation that matters: Microsoft's C# compiler, the standard
> Python interpreter, the standard Perl interpreter, Java's Sun
> compiler, etc.

Yes it's totally different to develop in C#/Java/Delphi etc. than in
C++. They are blindly fast (compilation) and the IDE support is far
superior compared to all C++ tools. I don't want to say that C++
implementors of a C++ ide / C++ tools are too dumb to implement such
features, far from beyond that, but as you too wrote C++ is just too
complex.
C++ has also some good features, which aren't in the other languages,
RAII - templates >had< been a big plus before.

> That one implementation, typically driven by a small
> team or a company, can move *fast* to get new features out to users. C+
> + isn't like that: there are many implementations, all based on an
> agreed-upon standard. It's both a blessing and a curse... if you get
> fed up with your C++ vendor, just go to another one. But, it means
> that for a feature to be usable in C++ it needs to be implemented in
> the vast majority of those implementations.

Yep. I don't know if C++ has a bright future, if it continues this way
(rather slow evolution - hardware evolves now very fast to multi cores
for example, C++ gets more and more complex for the developer). But we
will see.

>   - Doug

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 31 mai, 22:29, James Kanze <james.ka...@gmail.com> wrote:
> The problem isn't whether a compiler can support
> context-sensitive keywords.  It's whether a human reader can
> support them.

Well, I used to use Object Pascal, which has
context-sensitive keywords of the kind discussed
here.

They gave exactly zero problem in a one million
lines code-base, and they improve a lot readability.

--- Raoul


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
::
:: No. Currently it's up to the compiler to decide if a function
:: matches a base class virtual function. I only want to express that
:: I want to override a function and that the compiler shall throw an
:: error if there isn't a matching function to override. I simply
:: have no chance in a
:: large code base to check if the code is still o.k. if a change a
:: virtual function in a base class.

The argument against this is of course that you just shouldn't change
the signature of a virtual function in the base class.

If you do, you will have to check all subclasses anyway, to make sure
that they follow the semantics of the *new* function. I can't even
imagine changing the number and/or types of the parameters, whithout
severly affecting the derived classes. The problem an 'override'
keyword would solve, is a really minor problem!


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> James Dennett wrote:
>
>>[...]
>> Let's be clear: the problems of context-sensitive keywords
>> are mostly readability and implementation costs.  The problem
>> of new non-context-sensitive keywords is large scale breakage
>> of code and interfaces.
>
> Well I'm dealing with 6 C++ compilers. One of them has many new context
> sensitive keywords (not C++). And this hasn't broken any line of code
> yet. Perhaps my code base isn't large enough.

As I wrote: the problems of context-sensitive keywords
are mostly *not* in how much code they break.

(I seem to recall that the changes in VC++.NET mean
that it fails to issue some required diagnostics even
when in its most 14882-compliant modes, but I do not
have the details to hand.  One more cost of complexity
and of language variants.)

It's not just compilers that have to be updated when
C++'s grammar changes; documentation tools, static
analysis tools, in-house/project-specific tools for
various purposes, style checkers and more all need
to be updated.  Documentation needs to be updated.
And in the case of the C++ community there is a lot
of all these.  Making those updates more expensive
is a very real cost.

This isn't neglecting the cost of a less appealing
appearance for code that can be caused by trying too
hard to avoid new keywords, but as always it's a
trade-off, and in the absence of hard data it's going
to come down to subjective judgment calls.  Luckily
these are influenced directly by many dozens, and
indirectly by hundreds or thousands, and so they tend
to do a decent job of balancing the needs of a very
diverse (and very large) community.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Dennett wrote:
> Andre Kaufmann wrote:
> [...]
> As I wrote: the problems of context-sensitive keywords
> are mostly *not* in how much code they break.
>
> (I seem to recall that the changes in VC++.NET mean
> that it fails to issue some required diagnostics even
> when in its most 14882-compliant modes, but I do not
> have the details to hand.  One more cost of complexity
> and of language variants.)

It's not only VC++.NET, there are other compilers having context
sensitive proprietary keywords (not override ?). Besides I don't want to
name and favor a specific compiler, because I want only to discuss
context sensitive keywords.

> It's not just compilers that have to be updated when
> C++'s grammar changes; documentation tools, static
> analysis tools, in-house/project-specific tools for
> various purposes, style checkers and more all need
> to be updated.  Documentation needs to be updated.

Yes good point. But how does a documentation tool work. Is it really a
fully 100% C++ compliant parser ? I don't think so. Commonly they are
rather low level tools, which IMHO don't break (that much) - depends on
the context of the context sensitive keyword.

Static code checkers commonly (are able to) analyze only a small part of
the C++ code and therefore are restricted and context sensitive either
(in some way).

In the context of template export I think it's rather a small change.
Same applies to the upcoming module concept. This will be a huge change
for all such tools - much more than context sensitive keywords.
It surely adds more value, but in this context the rather small change
of adding context sensitive keywords could be neglected.

By the way, many C++ keywords are used in different contexts with
different meanings, so don't we have already some kind of context
sensitive keywords ?

 > And in the case of the C++ community there is a lot
 > of all these.  Making those updates more expensive
 > is a very real cost.

Well as I think with using (as I would call it generally) "operators" as
keywords these tools have been already made much more expensive.
If for example such a tool should search for all abstract functions to
display them, is it easier to search (regular expressions, parser ...)
for ">" or for an keyword "abstract" ?. So I could argue in the same way
that continuing in using single operator keys as keywords also introduce
more costs - but I don't argue this way ;-).


> This isn't neglecting the cost of a less appealing
> appearance for code that can be caused by trying too
> hard to avoid new keywords, but as always it's a
> trade-off, and in the absence of hard data it's going
> to come down to subjective judgment calls.  Luckily
> these are influenced directly by many dozens, and
> indirectly by hundreds or thousands, and so they tend
> to do a decent job of balancing the needs of a very
> diverse (and very large) community.

I don't neglect that it would mean additional costs, but continuing to
overload already existing keywords (or operators) will make C++ even
more complex and less appealing for new/experienced developers. Though
these effects will be seen in some years only.

The module concept is a chance for C++ to catch up with other languages
regarding compilation speed and makes it easier to program with. It
would be also a good chance to cut down some old obstacles.

> -- James

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Bo Persson wrote:
> Andre Kaufmann wrote:

Somehow my last post hasn't been approved. Perhaps it has been to long -
I'll keep it short now. If I have now double posted - please excuse this
fact.

> [...]
> The argument against this is of course that you just shouldn't change
> the signature of a virtual function in the base class.

Well sometimes I'm not responsible for a base class and sometimes I
simply have to change the code. And the problem also occurs if a derive
from a base class, how do I ensure that my function is overridden ?

> [...]
> severly affecting the derived classes. The problem an 'override'
> keyword would solve, is a really minor problem!

It's perhaps not that simple as it seems:

- Problem occurs on derivation, too. Not only on base class changes
- Compilers behave different on overriding functions when using
   complex arguments (const, template parameters etc.)
- I don't want to be dependent on the compiler, overriding or not
- Sometimes I have to use external written base classes which
   will change. So it would be better if the compiler would give
   me a diagnostic message
- C++ supports multiple base classes, so perhaps additionally
   an explicit override syntax is needed too
- In complex object class hierarchies, especially if templates are
   involved you simply can't ensure and check if all functions are
   correctly overridden. It's the task of the compiler to do and
   ensure this

As I already wrote it's a rare problem. But if you have it IMHO it's a
huge problem to detect where in a complex object hierarchy (templates!!
and meta code generation) the functions are not overridden correctly.

> Bo Persson

Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andre Kaufmann wrote:
> Hi,
>
> the C++ committee is very restrictive in introducing new keywords in the
> C++ standard. An example is the proposal for overriding virtual
> functions. (Sad story is I don't know yet if it will be really in the
> final draft).
>
> It shall have the syntax:
>
> virtual void foo() >= 0;
> virtual void foo() >  0;
>
> Where the natural "human" readable version would be IMHO:
>
> virtual void foo() override abstract;
> virtual void foo() override;

I wanna aks a (maybe a bit silly) question:

What's the reason for introducing such keywords? The compiler does not
need it, it's just syntactic shugar IMO.

It would make code more readable, but documentation would do the same
job, but does not need a new keyword :-).

The only technical reason may be to make the compilers life easier to
determine pure virtual funktioncalls, I'm not sure if this would help in
this situation.

Maybe someone can tell me why this is necessary.

Thanks && Best regards,
Nicolas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Nicolas Pavlidis wrote:
> Andre Kaufmann wrote:
 >>[...]
>> Where the natural "human" readable version would be IMHO:
>>
>> virtual void foo() override abstract;
>> virtual void foo() override;
>
> I wanna aks a (maybe a bit silly) question:
>
> What's the reason for introducing such keywords? The compiler does not
> need it, it's just syntactic shugar IMO.

You are correct the compiler doesn't need keywords.
It's only for a developer easier to read. Isn't that worth to introduce
them ?.

> It would make code more readable, but documentation would do the same
> job, but does not need a new keyword :-).

Let me show you the effect with a short example, where I have replaced
all keywords with "operators":

# c
{
   * c(int a) { -(int i = 0; i < a; ++i) foo(i); } > 0;
}

class c
{
     explicit c(int a) { for (int i =0; i < a; ++i) foo(i); } override;
}

Sure you could read in the documentation that # means class, *explicit
and so one. And even if you know it, which version is more readable and
allows a developer more quickly to interpret what the code does ?


> The only technical reason may be to make the compilers life easier to
> determine pure virtual funktioncalls, I'm not sure if this would help in
> this situation.

Don't know what you mean with "help in this situation". I didn't thought
   about how making the life of the compiler easier, but the life of the
developer.

Currently I have the impression that developers have to "live" with some
let's name it "inherited burdens", because more care is taken about (few
/ single ?)compiler vendors, which argue that my proposal would be too
complex to implement. When I think about the complexity of C++ at all
and some proposals, which will be introduced in the C++ standard, which
IMHO are way more complex to implement for a compiler vendor, I don't
understand why it's so complex now ?

> Maybe someone can tell me why this is necessary.

Not introducing new keywords have effects, same as relying on huge
libraries rather than implementing new features / functions in the
compiler directly have effects too.

Some of these affect "only developers" some the speed and efficiency of
the compiler and the compiled code.

> Thanks && Best regards,
> Nicolas

Best Regards,
Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi!

Andre Kaufmann wrote:
> Nicolas Pavlidis wrote:
>> Andre Kaufmann wrote:
>>>[...]
>>> Where the natural "human" readable version would be IMHO:
>>>
>>> virtual void foo() override abstract;
>>> virtual void foo() override;
>>
>> I wanna aks a (maybe a bit silly) question:
>>
>> What's the reason for introducing such keywords? The compiler does not
>> need it, it's just syntactic shugar IMO.
>=20
> You are correct the compiler doesn't need keywords.

Yes :-).

> It's only for a developer easier to read. Isn't that worth to introduce
> them ?.

Yes you are right. The indent of my posting was why ther's a need for
override, or the =F6perator" > in the context of overriding virtual
methods of some base - class. After some discusion I found out, that it
can easily happen that someone overrides a method "by accident".
Something like this can not happen if you need express that you really
want to override a virtual method of the base class.

Keywords, or in this case operators are great if they make sense, I
didn't saw the reason for intorducing such a functionality in C++.

>> It would make code more readable, but documentation would do the same
>> job, but does not need a new keyword :-).
>=20
> Let me show you the effect with a short example, where I have replaced
> all keywords with "operators":
>=20
> # c
> {
>   * c(int a) { -(int i =3D 0; i < a; ++i) foo(i); } > 0;
> }
>=20
> class c
> {
>     explicit c(int a) { for (int i =3D0; i < a; ++i) foo(i); } override=
;
> }

Maybe I missunderstand your Code, but in this Context c makrs a
constructor, and here the override keyword maks no sense, because
constructors can not be virtual.

> Sure you could read in the documentation that # means class, *explicit
> and so one. And even if you know it, which version is more readable and
> allows a developer more quickly to interpret what the code does ?

As said, I wanted to konw why sunch a "override functionality" should be
added to C++.

>=20
>> The only technical reason may be to make the compilers life easier to
>> determine pure virtual funktioncalls, I'm not sure if this would help =
in
>> this situation.

This was "posintg before thinking" :-(.


> Currently I have the impression that developers have to "live" with som=
e
> let's name it "inherited burdens", because more care is taken about (fe=
w
> / single ?)compiler vendors, which argue that my proposal would be too
> complex to implement. When I think about the complexity of C++ at all
> and some proposals, which will be introduced in the C++ standard, which
> IMHO are way more complex to implement for a compiler vendor, I don't
> understand why it's so complex now ?

I'm not sure what the impact would be, if such keywords would be
intorcued. My point of view is, that the >=3D, > - syntax is more natural
to C++ then override and abstract.

The second point is, how the compiler can distinguish bewteen old code
that overrides methods without explicitly saying that, and new code that
would use the new feature.

Thats the point I think, because C++ 0x must be backward compatible with
C++98, so a new compiler implementing C++0x can only warn.

That would be a problem for the other syntax too, I think.


Best regards,
Nicolas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Nicolas Pavlidis wrote:
> Hi!
>=20
> Yes you are right. The indent of my posting was why ther's a need for
> override, or the =F6perator" > in the context of overriding virtual

Sorry, misinterpreted your question.

> methods of some base - class. After some discusion I found out, that it
> can easily happen that someone overrides a method "by accident".
> Something like this can not happen if you need express that you really
> want to override a virtual method of the base class.

They point with override is that you can express your intention to=20
override a function.
If you derive from a virtual base class and want to override a function=20
and simply mistype a parameter or the functions name the method will not=20
be overridden, though you wanted to. The downside is, if you are lucky=20
the compiler will warn you or better said is able to warn you, if not=20
you will have a runtime error, depending on how you call the function.

Example:

struct base
{
   virtual void foo(unsigned int z) { cout << " base " << endl; }
};

struct derived : public base
{
    virtual void foo(int z) { cout << " derived " << endl; }
};

void call()
{=09
   derived a;
   a.foo(1);
   static_cast<base&>(a).foo(1);
   return 0;
}

will output

"derived"
"base"

Though the intention of the developer was to override the function.
It's only a simple example, but if templates are involved or more=20
complex functions you simply can mistype a parameter type and you can't=20
check if the compiler generated the code you intended to, but only by=20
debugging the code.

> Keywords, or in this case operators are great if they make sense, I
> didn't saw the reason for intorducing such a functionality in C++.

Hope my sample has changed your mind ? ;-)

 > [...]
>> class c
>> {
>>     explicit c(int a) { for (int i =3D0; i < a; ++i) foo(i); } overrid=
e;
>> }
>=20
> Maybe I missunderstand your Code, but in this Context c makrs a [...]

Sorry my fault. I hacked in the code, which should have as many keywords=20
as possible, but didn't think about mixing keywords used for=20
constructors with keywords used for member functions only.
Yes, in C++ you can't make a constructor virtual and therefore can't=20
override it. It should only be pseudo code, illustrating that using "too=20
much" "operators" instead of keywords would lead to more unreadable code.
So from my point of view, in C++ rather new keywords should be used,=20
instead of IMHO "misusing" operators as keywords.


> [...]
> I'm not sure what the impact would be, if such keywords would be
> intorcued. My point of view is, that the >=3D, > - syntax is more natur=
al
> to C++ then override and abstract.

Well, AFAIK > instead of override has been introduced only, because=20
there "hasn't been enough time" to introduce a keyword before the=20
standard has been released.
I find looking at an interface with >=3D; >, =3D 0 and so on mixed isn't=20
that natural for a developer to read. Currently there is only a=20
difference between abstract and virtual functions. Which can be clearly=20
separated by viewing at the interface, but if override is introduced=20
IMHO it will be more hard to read and to search for overridden functions=20
if operators are used.

I agree that it's not "a real big deal" to use > instead of override.=20
Though I think in C++ enough operators are used instead of keywords and=20
this shouldn't be continued (IMHO).

> The second point is, how the compiler can distinguish bewteen old code
> that overrides methods without explicitly saying that, and new code tha=
t
> would use the new feature.

Sadly, the compiler couldn't distinguish between new and old code. So it=20
would have to simply continue compiling code as it has been done before.=20
But if the keyword override is used, it could prompt a diagnostic=20
message. Currently it can't.

> Thats the point I think, because C++ 0x must be backward compatible wit=
h
> C++98, so a new compiler implementing C++0x can only warn.

I don't think so. Introducing modules in C++ would be also a good chance=20
to add some restrictions, in fact IIRC there are already some in the=20
proposal - better said: must be ;-)

> [...]
> Best regards,
> Nicolas

Best regards,
Andre

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]