On 3 Jan., 04:47, James Kanze <james.ka...@gmail.com> wrote:
> Sort of.  It's clear that I think such an idea has a certain
> number of advantages; it allows the compiler to enforce things
> that I otherwise enforce by documentation and code review (and
> while good code reviewers don't miss much, the compiler misses
> even less).  On the other hand, I also have a lot of existing
> C++ code that I don't want to have to rewrite.  Enough so that I
> consider that the cost outweighs the advantages, and I'd argue
> against such a change in the existing language.  It's just
> something to think of if anyone is designing a new language.

I may have pulled this out of context but I think there's a
misunderstanding here. The original poster's suggested meaning for
"override" won't render old C++ code ill-formed.  Overriding functions
won't require the use of the "override" keyword.  But the presence of
"override" in a declaration makes the compiler verify that the
function is indeed overriding some base class virtual function.  So,
the only case where code will be ill-formed is when you use "override"
without actually overriding a function which is clearly a mistake.
This might happen if a virtual function in a base class is renamed for
example.  I don't see any disadvantage of this use of "override".

Cheers!
SG

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

SG wrote:
>
> On 3 Jan., 04:47, James Kanze <james.ka...@gmail.com> wrote:
>>
>> Sort of.  It's clear that I think such an idea has a certain
>> number of advantages; it allows the compiler to enforce things
>> that I otherwise enforce by documentation and code review (and
>> while good code reviewers don't miss much, the compiler misses
>> even less).  On the other hand, I also have a lot of existing
>> C++ code that I don't want to have to rewrite.  Enough so that I
>> consider that the cost outweighs the advantages, and I'd argue
>> against such a change in the existing language.  It's just
>> something to think of if anyone is designing a new language.
>
> I may have pulled this out of context but I think there's a
> misunderstanding here. The original poster's suggested meaning for
> "override" won't render old C++ code ill-formed.

You have lost the context; at this point, we're no longer discussing
the OP's suggestion, but the the more comprehensive concept that James
Kanze mentioned, which would in fact render old C++ code ill-formed.

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

There is one feature that I'd really like to see be a part of C++0x
(or C++1x, as the case may be), and one feature that I'd kind of like
to see. I had come here to post about these and, in doing some
research before posting, found out that these features are actually
already Microsoft extensions to the language (something I believe they
did right with C++). Therefore, I'll reference the MS documentation
below.

===

First, I would really like to see a keyword "override" introduced.
This keyword can be used to modify member functions that override base
members:

class Base {
       virtual void member ();
       virtual int function ();
};

class Derived : public Base {
       void member () override;
       int function (int) override; // <-- illegal
};

void Derived::member () { // note: not in definition
}

The purpose of the keyword is solely to tell the compiler that members
are intended to override a base member. If one does not, then
compilation fails.

The MS documentation for this extension, which actually came from C#,
can be found here:

http://msdn.microsoft.com/en-us/library/41w3sh1c.aspx

While I did just find out that MS provided this extension, I actually
originally thought about it because a relatively new feature of Java
provides the same feature (the @Override annotation).

I think this keyword is extremely useful in moderately to extremely
large applications as a way to minimize programming error and increase
maintainability. Particularly, it allows a programmer to change the
Base function signature and immediately know what the effects are
rather than possibly introducing subtle errors into the code. This
also catches more subtle mistakes, e.g. adding an incorrect const
modifier to the base declaration, etc.

I believe the "override" keyword is justified in the same way "const"
is justified. The const keyword, afaik, has no effect on the generated
code itself, but rather is a way to specify to the compiler what you
mean to help eliminate programming errors. I think "override-
correctness" and "const-correctness" are in the same spirit.

===

Secondly, I would kind of like to see a keyword "sealed". This is
something that I see asked about relatively frequently on C++ forums
and newsgroups. The "sealed" keyword prevents derived classes from
overriding a virtual function. For example (note I have not made the
example "override-correct" for the sake of clarity):

class Base {
       virtual void member ();
};

class Derived : public Base {
       void member () sealed;
};

class DerivedAgain : public Derived {
       void member (); // <--- illegal
};

void Derived::member () { // note: not in definition
}

The MS documentation for this extension, which also came from C#, can
be found here:

http://msdn.microsoft.com/en-us/library/0w2w91tf.aspx

Again, while I did just find out that it was an MS extension,
originally I had thought about it because of the "final" keyword
provided by Java.

I think this keyword is useful in lieu of (or as a supplement to)
documentation in situations where it is no longer appropriate for a
derived class to override a base function. It provides compile-time
enforcement that a base function is not overridden.

However, the reason I "kind of" want to see this rather than "really"
is I feel like there is a large potential for incorrect usage.
Unnecessary use of "sealed" when, in fact, a derived class may need to
override a function, only makes maintenance and modification more
difficult, not less, which is contrary to the spirit of the keyword.
Unlike "const", "sealed" can arbitrarily be placed on a member
function without adding restrictions to that function, which means
it's easy to misuse ("const", on the other hand, requires that the
function does not modify any non-const data or call other non-const
functions, and it is difficult to use it unnecessarily).

That said, in my personal experience I have not run in to frequent
incorrect usage of the "final" keyword in Java, and therefore that may
be a non-issue.

===

An combination of the above examples, just for illustration:

class Base {
       virtual void member ();
       virtual int function ();
       virtual void another ();
};

class Derived : public Base {
       void member () override sealed;
       int function (int) override; // <--- illegal
       void another () const; // <--- valid, but probably a mistake.
};

class DerivedAgain : public Derived {
       void member () override; // <--- illegal
       int function () override;
       void another ();
};

===

Personally, I think the "override" keyword would add a lot to the
language, and fill in a big maintainability gap that I think has
existed for quite some time. As for the "sealed" keyword, while I
think it is useful, especially based on how relatively often I have
seen the question asked, I don't think it is quite as useful of an
addition "override", and does have the potential to cause more
problems than it solves when used inappropriately.


Jason

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

"JC" <jason.cipriani@gmail.com> wrote:
> There is one feature that I'd really like to see be a part of C++0x
> (or C++1x, as the case may be), and one feature that I'd kind of like
> to see. I had come here to post about these and, in doing some
> research before posting, found out that these features are actually
> already Microsoft extensions to the language (something I believe they
> did right with C++). Therefore, I'll reference the MS documentation
> below.
>

It is far too late in the process to adopt these suggestions,
but the underlying features are useful.

One thing to note is that these features are of the form, that a compiler
that ignores the keywords would still compile correct code identically, but
would also accept incorrect code too. In orther words, a compiler caqn
ignore these keywords, without making any correct programs incorrect.
Thus these features are an excellent choice for an attribute, rather than
new keywords.

Indeed, we already have the equivlent to sealed in the latest c++0x draft,
namely the 'final' attribute.

struct A{
virtual void foo(int);
}

struct B:A {
virtual void foo [[ final ]] (int);
}

struct C:B {
virtual void foo (int); //Ill formed
}

However, the standard does not require a diagnostic here.
(In other words, a compiler is allowed to ignore this attribute).

However, most compilers will diagnose this issue, because it should not be
very difficult to add.

An attribute with the semantics of the override keyword you describe sounds
useful. Perhaps you should propose it for one of the post C++0X TRs.


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

JC wrote:
>
> First, I would really like to see a keyword "override" introduced.
> Secondly, I would kind of like to see a keyword "sealed".

  That's a big language change.

  It should at least be required that non-virtual destructors cannot
be overridden.  Overriding a non-virtual destructor is almost always
an error.  Then, one can express the "sealed" concept simply by
making a destructor non-virtual.

                               John Nagle

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

"John Nagle" wrote:
>
> JC wrote:
>>
>> First, I would really like to see a keyword "override" introduced.
>> Secondly, I would kind of like to see a keyword "sealed".
>
>  That's a big language change.
>
>  It should at least be required that non-virtual destructors cannot
> be overridden.  Overriding a non-virtual destructor is almost always
> an error.  Then, one can express the "sealed" concept simply by
> making a destructor non-virtual.
>

The sealed concept he descibed was specific to virtual functions, and
is in fact equivlent to the [[final]] attribute on a function. I don't
see how destructors come into it.

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

On Dec 29, 3:50 pm, John Nagle <na...@animats.com> wrote:
> JC wrote:
>
> > First, I would really like to see a keyword "override" introduced.
> > Secondly, I would kind of like to see a keyword "sealed".
>
>   That's a big language change.
>
>   It should at least be required that non-virtual destructors cannot
> be overridden.  Overriding a non-virtual destructor is almost always
> an error.  Then, one can express the "sealed" concept simply by
> making a destructor non-virtual.

"Sealed" applies to virtual functions only. I did not realize the
"final" attribute was one of the new additions, and so my suggestion
for "sealed" is moot anyways.

There is not much to be done about overriding non-virtual functions.
If you operated under the assumption that doing so was probably a
mistake, then you could require a compiler to generate a diagnostic --
but I'm not sure that assumption is correct enough to justify that.

Jason


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

On Dec 29, 9:50 pm, John Nagle <na...@animats.com> wrote:
> JC wrote:

> > First, I would really like to see a keyword "override"
> > introduced.  Secondly, I would kind of like to see a keyword
> > "sealed".

> That's a big language change.

Yes.  Logically, there are two orthogonal issues: does this
function override a virtual function in a base class or not, and
can it be overridden in a derived class.  This gives four types
of functions, and it would be nice to have to specify for each
function which it is.  Doing so would simply break all existing
C++ code, however, so is pretty much out of the question.

> It should at least be required that non-virtual destructors
> cannot be overridden.  Overriding a non-virtual destructor is
> almost always an error.  Then, one can express the "sealed"
> concept simply by making a destructor non-virtual.

Nonsense.  That would mean that you couldn't derive from
std::iterator<>, for example, and would break a lot of other
widespread idioms.  And I don't see any relationship with his
proposal for "sealed", which applies to individual functions,
and not to the destructor or the entire class.

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 29, 9:50 pm, John Nagle <na...@animats.com> wrote:
>
> > JC wrote:
> > > First, I would really like to see a keyword "override"
> > > introduced.  Secondly, I would kind of like to see a keyword
> > > "sealed".
> > That's a big language change.
>
> Yes.  Logically, there are two orthogonal issues: does this
> function override a virtual function in a base class or not, and
> can it be overridden in a derived class.  This gives four types
> of functions, and it would be nice to have to specify for each
> function which it is.  Doing so would simply break all existing
> C++ code, however, so is pretty much out of the question.

This is simply not true.

If "sealed" is not used, a function can be overridden. This
corresponds to existing C++.

If "override" is not used, then no check is performed for a
corresponding base function. This also corresponds to existing C++.

Therefore all existing C++ code would still be accepted and have the
correct behavior, and no existing code would be broken.

Jason


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

"James Kanze" wrote:
>
> Yes.  Logically, there are two orthogonal issues: does this
> function override a virtual function in a base class or not, and
> can it be overridden in a derived class.  This gives four types
> of functions, and it would be nice to have to specify for each
> function which it is.  Doing so would simply break all existing
> C++ code, however, so is pretty much out of the question.

True, but his only real proposal is minor, if interpeted as a request
for an additional attribute, namely "override", which requests a
diagnostic in the case that it is not overriding a virtiual function
in one of the ancestor classes.

If the wording of the final attribute was borrowed, then compilers
would be free to ignore the attribute. This means that such an
addition to the standard could be staisfied by as little as a single
line addition to an otherwise complete C++0x compiler. (A line to
recognize the attribute in the case of member functions.)

This has no API, or ABI considerations, absolutely could not break any
existing code, would require an additon to the standard of only a
handful of lines (no more than the number of lines the final attribute
takes).

Overall, I would doubt there would be oposition to such an addition to
the standard if it were not for the fact that it is way too late in
the process to be considering new proposals.

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

James Kanze wrote:
>
> On Dec 29, 9:50 pm, John Nagle <na...@animats.com> wrote:
>>
>> JC wrote:

>> It should at least be required that non-virtual destructors
>> cannot be overridden.  Overriding a non-virtual destructor is
>> almost always an error.  Then, one can express the "sealed"
>> concept simply by making a destructor non-virtual.
>
> Nonsense.  That would mean that you couldn't derive from
> std::iterator<>, for example, and would break a lot of other
> widespread idioms.  And I don't see any relationship with his
> proposal for "sealed", which applies to individual functions,
> and not to the destructor or the entire class.

 I know that's done in some wierdo metaprogramming stuff, like

http://www.boost.org/doc/libs/1_37_0/boost/iterator/iterator_facade.hpp

but do derived iterators actually appear in operational production code?

                               John Nagle

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

JC wrote:
> On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
....
>> Yes.  Logically, there are two orthogonal issues: does this
>> function override a virtual function in a base class or not, and
>> can it be overridden in a derived class.  This gives four types
>> of functions, and it would be nice to have to specify for each
>> function which it is.  Doing so would simply break all existing
>> C++ code, however, so is pretty much out of the question.
>
> This is simply not true.
>
> If "sealed" is not used, a function can be overridden. This
> corresponds to existing C++.
>
> If "override" is not used, then no check is performed for a
> corresponding base function. This also corresponds to existing C++.

He said "it would be nice to have to specify for each function which it
is". What you describe doesn't match that description, because there's
two different cases that occur by default, without being explicitly
specified. To match his "it would be nice" requires at least two
additional keywords: one that would have to be used to specify that a
function can be overridden ("overrideable"?) and one to specify that no
check need be performed for a corresponding base function (nooverride).
Requiring such keywords would indeed break all existing C++ code.

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

On Dec 28, 8:02 pm, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
> "JC" <jason.cipri...@gmail.com> wrote:
> > There is one feature that I'd really like to see be a part of C++0x
> > (or C++1x, as the case may be), and one feature that I'd kind of like
> > to see. I had come here to post about these and, in doing some
> > research before posting, found out that these features are actually
> > already Microsoft extensions to the language (something I believe they
> > did right with C++). Therefore, I'll reference the MS documentation
> > below.
>
> It is far too late in the process to adopt these suggestions,
> but the underlying features are useful.
>
> One thing to note is that these features are of the form, that a compiler
> that ignores the keywords would still compile correct code identically, but
> would also accept incorrect code too. In orther words, a compiler caqn
> ignore these keywords, without making any correct programs incorrect.
> Thus these features are an excellent choice for an attribute, rather than
> new keywords.
>
> Indeed, we already have the equivlent to sealed in the latest c++0x draft,
> namely the 'final' attribute.
>
> struct A{
> virtual void foo(int);
>
> }
>
> struct B:A {
> virtual void foo [[ final ]] (int);
>
> }
>
> struct C:B {
> virtual void foo (int); //Ill formed
>
> }
>
> However, the standard does not require a diagnostic here.
> (In other words, a compiler is allowed to ignore this attribute).
>
> However, most compilers will diagnose this issue, because it should not be
> very difficult to add.
>
> An attribute with the semantics of the override keyword you describe sounds
> useful. Perhaps you should propose it for one of the post C++0X TRs.

To be honest, I would rather see final as a keyword than an attribute,
as I somewhat dislike the C++0x attribute system, but having it as an
attribute mostly gets the job done.

In any case, I will definitely propose "override" in some form for one
of the TRs... what is the normal procedure for that and when is an
appropriate time to do it (it seems I missed the boat this time)?

Thanks,
Jason


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

On Dec 31, 1:44 am, JC <jason.cipri...@gmail.com> wrote:
> On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Dec 29, 9:50 pm, John Nagle <na...@animats.com> wrote:

> > > JC wrote:
> > > > First, I would really like to see a keyword "override"
> > > > introduced.  Secondly, I would kind of like to see a keyword
> > > > "sealed".
> > > That's a big language change.

> > Yes.  Logically, there are two orthogonal issues: does this
> > function override a virtual function in a base class or not, and
> > can it be overridden in a derived class.  This gives four types
> > of functions, and it would be nice to have to specify for each
> > function which it is.  Doing so would simply break all existing
> > C++ code, however, so is pretty much out of the question.

> This is simply not true.

> If "sealed" is not used, a function can be overridden. This
> corresponds to existing C++.

> If "override" is not used, then no check is performed for a
> corresponding base function. This also corresponds to existing
> C++.

> Therefore all existing C++ code would still be accepted and
> have the correct behavior, and no existing code would be
> broken.

What would break all existing code is requiring that every
function in the class be categorized into one of the four cases.
That doesn't mean that somewhat less inclusive proposals could
not be made to work.

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 31, 12:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
> JC wrote:
> > On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
> ....
> >> Yes.  Logically, there are two orthogonal issues: does this
> >> function override a virtual function in a base class or not, and
> >> can it be overridden in a derived class.  This gives four types
> >> of functions, and it would be nice to have to specify for each
> >> function which it is.  Doing so would simply break all existing
> >> C++ code, however, so is pretty much out of the question.
>
> > This is simply not true.
>
> > If "sealed" is not used, a function can be overridden. This
> > corresponds to existing C++.
>
> > If "override" is not used, then no check is performed for a
> > corresponding base function. This also corresponds to existing C++.
>
> He said "it would be nice to have to specify for each function which it
> is". What you describe doesn't match that description, because there's
> two different cases that occur by default, without being explicitly
> specified. To match his "it would be nice" requires at least two
> additional keywords: one that would have to be used to specify that a
> function can be overridden ("overrideable"?) and one to specify that no
> check need be performed for a corresponding base function (nooverride).
> Requiring such keywords would indeed break all existing C++ code.

I suggested "sealed" and "override".

John Nagle went on to say the suggestion was a big language change.

James Kanze agreed and cited "breaking existing C++ code" as a reason.

If James Kanze was referring to two additional keywords (or
attributes, perhaps) along the lines of "not_sealed" and
"not_an_override" (for example) as breaking existing code, the some
continuity was lost in the communication somewhere -- please excuse my
confusion.

In any case, I personally don't feel the need for things like
"not_sealed" and "not_an_override", and it isn't part of the original
suggestion. They certainly would break existing code, and that is not
desirable. It would instead make more sense to have the default if
"sealed" or "override" was not specified be "not sealed" and "not
override", and that is part of the original suggestion. Opposite
keywords/attributes do not make sense for the same reason a "nonconst"
modifier does not make sense.

Note that the discussion of "sealed" is moot, as "final" already
exists (although it is an attribute not a keyword, it serves the same
purpose).

Jason


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

On Dec 31, 6:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
> JC wrote:
> > On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
> ....
> >> Yes.  Logically, there are two orthogonal issues: does this
> >> function override a virtual function in a base class or not, and
> >> can it be overridden in a derived class.  This gives four types
> >> of functions, and it would be nice to have to specify for each
> >> function which it is.  Doing so would simply break all existing
> >> C++ code, however, so is pretty much out of the question.

> > This is simply not true.

> > If "sealed" is not used, a function can be overridden. This
> > corresponds to existing C++.

> > If "override" is not used, then no check is performed for a
> > corresponding base function. This also corresponds to existing C++.

> He said "it would be nice to have to specify for each function
> which it is". What you describe doesn't match that
> description, because there's two different cases that occur by
> default, without being explicitly specified. To match his "it
> would be nice" requires at least two additional keywords: one
> that would have to be used to specify that a function can be
> overridden ("overrideable"?) and one to specify that no check
> need be performed for a corresponding base function
> (nooverride).  Requiring such keywords would indeed break all
> existing C++ code.

If I were designing the language today (without any concerns of
existing code), then I'd use:

   /* nothing */    doesn't override, cannot be overridden
   virtual          doesn't override, can be overridden
   overrides        overrides, can be overridden
   final            overrides, can't be overridden

But of course, that would break a lot of code.  (And I should
have been clearer that this is what I meant when I said it would
break all existing code.)  Adding overrides and final, without
changing the current defaults, would probably be an acceptable
compromise.  But it's far too late for a proposal this round of
standardization.

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Dec 31, 1:45 am, John Nagle <na...@animats.com> wrote:
> James Kanze wrote:

> > On Dec 29, 9:50 pm, John Nagle <na...@animats.com> wrote:

> >> JC wrote:
> >> It should at least be required that non-virtual destructors
> >> cannot be overridden.  Overriding a non-virtual destructor
> >> is almost always an error.  Then, one can express the
> >> "sealed" concept simply by making a destructor non-virtual.

> > Nonsense.  That would mean that you couldn't derive from
> > std::iterator<>, for example, and would break a lot of other
> > widespread idioms.  And I don't see any relationship with
> > his proposal for "sealed", which applies to individual
> > functions, and not to the destructor or the entire class.

>  I know that's done in some wierdo metaprogramming stuff, like

> http://www.boost.org/doc/libs/1_37_0/boost/iterator/iterator_facade.hpp

> but do derived iterators actually appear in operational production code?

It's done in a lot of cases.  Using non-virtual protected
destructors is a classical idiom where there must be
preconditions for destruction, to force all deletes through a
member function which validates the preconditions.  User defined
iterators which derive from std::iterator<>, and user defined
functional objects which derive from std::unary_function<> or
std::binary_function<> are also fairly common.

And none of the above necessarily use metaprogramming in the
user code.  The derivations from the std:: class templates are
used to enable a few very simple metaprogramming techniques in
the standard library.  And are required if you intend to use the
standard library---most code written today does.

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

JC wrote:
> On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Dec 29, 9:50 pm, John Nagle <na...@animats.com> wrote:
> >
> > > JC wrote:
> > > > First, I would really like to see a keyword "override"
> > > > introduced.  Secondly, I would kind of like to see a keyword
> > > > "sealed".
> >
> > > That's a big language change.
> >
> > Yes.  Logically, there are two orthogonal issues: does this
> > function override a virtual function in a base class or not, and
> > can it be overridden in a derived class.  This gives four types
> > of functions, and it would be nice to have to specify for each
> > function which it is.  Doing so would simply break all existing
> > C++ code, however, so is pretty much out of the question.
>
> This is simply not true.
>
> If "sealed" is not used, a function can be overridden. This
> corresponds to existing C++.
>
> If "override" is not used, then no check is performed for a
> corresponding base function. This also corresponds to existing C++.
>
> Therefore all existing C++ code would still be accepted and have the
> correct behavior, and no existing code would be broken.

Well, code which already had identifiers named "sealed" and/or "override"
would be broken. Otherwise, agreed.

By the way, I wrote about the same idea years ago on a web page ("sealed"
was called "final"), with plenty of examples. I found ways of applying
final to objects too. I think it's worth a read:

http://slack.net/~ant/cpp/final.html

http://slack.net/~ant/cpp/override.html

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

JC wrote:
ds would indeed break all existing C++ code.
>
> I suggested "sealed" and "override".
>
> John Nagle went on to say the suggestion was a big language change.
>
> James Kanze agreed and cited "breaking existing C++ code" as a reason.
>
> If James Kanze was referring to two additional keywords (or
> attributes, perhaps) along the lines of "not_sealed" and
> "not_an_override" (for example) as breaking existing code, the some
> continuity was lost in the communication somewhere -- please excuse my
> confusion.
>
> In any case, I personally don't feel the need for things like
> "not_sealed" and "not_an_override", and it isn't part of the original
> suggestion. They certainly would break existing code, and that is not
> desirable. It would instead make more sense to have the default if
> "sealed" or "override" was not specified be "not sealed" and "not
> override", and that is part of the original suggestion. Opposite
> keywords/attributes do not make sense for the same reason a "nonconst"
> modifier does not make sense.

But it does. If we were designing a language from scratch, 'const' would
be the default and storage we wanted to modify would need to be
explicitly declared mutable. There are several places where the current
default (and they will remain exactly because we do not wish to break
existing code) is exactly wrong.

In the case of override, we want to prevent accidental overriding. The
best we can now do is to introduce an attribute and have compilers warn
when we override without the attribute being present. Notice that such
warnings would be QoI and must be able to be switched off because there
is nothing wrong with overriding from the language perspective.


>
> Note that the discussion of "sealed" is moot, as "final" already
> exists (although it is an attribute not a keyword, it serves the same
> purpose).

Well it is in the current Committee Draft. And please note that one of
the strengths of attributes is that they allow programmers to document
intent in the code and enable compilers to help support their intentions
without requiring that they do so. One of the important features of
attributes is that if the code compiles both with and without the
attribute the observed behaviour should be the same. An attribute might
make otherwise well-formed code fail to compile but IMHO it should never
work the other way round.
--
Note that robinton.demon.co.uk addresses are no longer valid.

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

On Jan 1, 9:47 am, JC <jason.cipri...@gmail.com> wrote:
> On Dec 31, 12:13 am, James Kuyper <jameskuy...@verizon.net> wrote:

      [...]
> James Kanze agreed and cited "breaking existing C++ code" as a
> reason.

> If James Kanze was referring to two additional keywords (or
> attributes, perhaps) along the lines of "not_sealed" and
> "not_an_override" (for example) as breaking existing code, the
> some continuity was lost in the communication somewhere --
> please excuse my confusion.

No.  I understood your proposal.  I was just extending it to
what I thought would be the ideal solution, and pointed out that
implementing the ideal solution would break all existing code.
I'm the one who wasn't very clear.

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2009-01-01 11:42:37 -0500, Francis Glassborow
<francis.glassborow@btinternet.com> said:

>
> If we were designing a language from scratch, 'const' would
> be the default and storage we wanted to modify would need to be
> explicitly declared mutable.
>
> [...]
>
> In the case of override, we want to prevent accidental overriding.

For some unspecified value of "we". On the other hand, some of us
don't think that making C++ a mother-may-I language like Pascal is a
good idea.

--
 Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)



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

JC wrote:
> On Dec 31, 12:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
>> JC wrote:
>>> On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
>> ....
>>>> Yes.  Logically, there are two orthogonal issues: does this
>>>> function override a virtual function in a base class or not, and
>>>> can it be overridden in a derived class.  This gives four types
>>>> of functions, and it would be nice to have to specify for each
>>>> function which it is.  Doing so would simply break all existing
>>>> C++ code, however, so is pretty much out of the question.
>>> This is simply not true.
>>> If "sealed" is not used, a function can be overridden. This
>>> corresponds to existing C++.
>>> If "override" is not used, then no check is performed for a
>>> corresponding base function. This also corresponds to existing C++.
>> He said "it would be nice to have to specify for each function which it
>> is". What you describe doesn't match that description, because there's
>> two different cases that occur by default, without being explicitly
>> specified. To match his "it would be nice" requires at least two
>> additional keywords: one that would have to be used to specify that a
>> function can be overridden ("overrideable"?) and one to specify that no
>> check need be performed for a corresponding base function (nooverride).
>> Requiring such keywords would indeed break all existing C++ code.
>
> I suggested "sealed" and "override".
>
> John Nagle went on to say the suggestion was a big language change.
>
> James Kanze agreed and cited "breaking existing C++ code" as a reason.

James Kanze wrote:
"... it would be nice to have to specify for each function which it is.
   Doing so would simply break all existing C++ code, however, so is
pretty much out of the question."

He is not giving "breaking existing C++ code" as a reason why your
suggestion is a big change; he gave it as a reason why his "nice" idea
is "out of the question".

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

On Jan 1, 3:59 am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31, 6:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
>
>
>
> > JC wrote:
> > > On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
> > ....
> > >> Yes.  Logically, there are two orthogonal issues: does this
> > >> function override a virtual function in a base class or not, and
> > >> can it be overridden in a derived class.  This gives four types
> > >> of functions, and it would be nice to have to specify for each
> > >> function which it is.  Doing so would simply break all existing
> > >> C++ code, however, so is pretty much out of the question.
> > > This is simply not true.
> > > If "sealed" is not used, a function can be overridden. This
> > > corresponds to existing C++.
> > > If "override" is not used, then no check is performed for a
> > > corresponding base function. This also corresponds to existing C++.
> > He said "it would be nice to have to specify for each function
> > which it is". What you describe doesn't match that
> > description, because there's two different cases that occur by
> > default, without being explicitly specified. To match his "it
> > would be nice" requires at least two additional keywords: one
> > that would have to be used to specify that a function can be
> > overridden ("overrideable"?) and one to specify that no check
> > need be performed for a corresponding base function
> > (nooverride).  Requiring such keywords would indeed break all
> > existing C++ code.
>
> If I were designing the language today (without any concerns of
> existing code), then I'd use:
>
>    /* nothing */    doesn't override, cannot be overridden
>    virtual          doesn't override, can be overridden
>    overrides        overrides, can be overridden
>    final            overrides, can't be overridden
>
> But of course, that would break a lot of code.  (And I should
> have been clearer that this is what I meant when I said it would
> break all existing code.)  Adding overrides and final, without
> changing the current defaults, would probably be an acceptable
> compromise.  But it's far too late for a proposal this round of
> standardization.

Nobody suggested adding keywords like that, nor would anybody want
them. The discussion about it is somewhat irrelevant. The suggestion
was for the following and nothing more:

    override: Overrides a base member, period.
    sealed: Can not be overridden, period.

The two keywords are independent of each other. If "override" is not
used then standard rules apply. If "sealed" is not used than standard
rules apply. "Adding overrides and final, without changing the current
defaults" is, in fact, the suggestion. Whatever extra rules or
keywords/attributes you are bringing up are, to be honest, confusing
the heck out of me. Where are they coming from? Am I missing
something?

Jason


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

You may safely ignore the following post, which suffered from some
moderation lag; James Kanze's recent response cleared up my confusion.
Sorry for my impatience.

Jason


On Jan 1, 7:59 pm, JC <jason.cipri...@gmail.com> wrote:
> On Jan 1, 3:59 am, James Kanze <james.ka...@gmail.com> wrote:
>
>
>
> > On Dec 31, 6:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
>
> > > JC wrote:
> > > > On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
> > > ....
> > > >> Yes.  Logically, there are two orthogonal issues: does this
> > > >> function override a virtual function in a base class or not, and
> > > >> can it be overridden in a derived class.  This gives four types
> > > >> of functions, and it would be nice to have to specify for each
> > > >> function which it is.  Doing so would simply break all existing
> > > >> C++ code, however, so is pretty much out of the question.
> > > > This is simply not true.
> > > > If "sealed" is not used, a function can be overridden. This
> > > > corresponds to existing C++.
> > > > If "override" is not used, then no check is performed for a
> > > > corresponding base function. This also corresponds to existing C++.
> > > He said "it would be nice to have to specify for each function
> > > which it is". What you describe doesn't match that
> > > description, because there's two different cases that occur by
> > > default, without being explicitly specified. To match his "it
> > > would be nice" requires at least two additional keywords: one
> > > that would have to be used to specify that a function can be
> > > overridden ("overrideable"?) and one to specify that no check
> > > need be performed for a corresponding base function
> > > (nooverride).  Requiring such keywords would indeed break all
> > > existing C++ code.
>
> > If I were designing the language today (without any concerns of
> > existing code), then I'd use:
>
> >    /* nothing */    doesn't override, cannot be overridden
> >    virtual          doesn't override, can be overridden
> >    overrides        overrides, can be overridden
> >    final            overrides, can't be overridden
>
> > But of course, that would break a lot of code.  (And I should
> > have been clearer that this is what I meant when I said it would
> > break all existing code.)  Adding overrides and final, without
> > changing the current defaults, would probably be an acceptable
> > compromise.  But it's far too late for a proposal this round of
> > standardization.
>
> Nobody suggested adding keywords like that, nor would anybody want
> them. The discussion about it is somewhat irrelevant. The suggestion
> was for the following and nothing more:
>
>     override: Overrides a base member, period.
>     sealed: Can not be overridden, period.
>
> The two keywords are independent of each other. If "override" is not
> used then standard rules apply. If "sealed" is not used than standard
> rules apply. "Adding overrides and final, without changing the current
> defaults" is, in fact, the suggestion. Whatever extra rules or
> keywords/attributes you are bringing up are, to be honest, confusing
> the heck out of me. Where are they coming from? Am I missing
> something?


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

On Jan 1, 5:42 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> > Note that the discussion of "sealed" is moot, as "final" already
> > exists (although it is an attribute not a keyword, it serves the same
> > purpose).
>
> Well it is in the current Committee Draft. And please note that one of
> the strengths of attributes is that they allow programmers to document
> intent in the code and enable compilers to help support their intentions
> without requiring that they do so. One of the important features of
> attributes is that if the code compiles both with and without the
> attribute the observed behaviour should be the same.

IMHO, this is the biggest weakness of attributes, at least given the
choice of default attributes as well as lists of suggested attributes
that I have seen thrown around. It is, in fact, why I would want to
see "final" as a keyword, not an attribute.

If a compiler such as MSVC, where Microsoft seems to have indicated
that C++0x attribute support is on the bottom of the todo list [1][2],
ignores "final", then it is basically useless except on a subset of
compilers.

Even conforming compilers could ignore the attribute versions of
"final" and "override" under the C++0x attribute standard, and this
entirely defeats the purpose of using them as a reliable way to ease
the burden of developing and maintaining large and complex class
hierarchies -- it may even make it more complex because of uncaught
inappropriate use of the attributes on compilers that ignore them
anyways. It is almost a joke to see "final" as an attribute and not a
keyword, as much as it would be a joke to have "const" be an
attribute.

"Override" is somewhat more appropriate as an attribute as it is used
to warn you when you are violating your intent but does not place
actual constraints on a class hierarchy. I would still want to see
override as a keyword, not an attribute, but having it as an attribute
is not as damaging as having "final" as an attribute.

To clarify, my position is not that C++0x attributes have no use, but
rather that "final" and other such attributes where the allowance of
"optional" support basically breaks (or severely limits) the
usefulness of those attributes would much better be represented as
keywords. "Final" is useful only if it places reliable constraints on
a class hierarchy -- if it does not, then it is semantically
equivalent to a comment.

If I'm not mistaken, some form of "align" is also slated for use as a
standard attribute. If this is true, this is equally nonsensical, and
was a severely misguided choice on the part of the person(s) who
pressed for alignment specifications to be optionally supported by
conforming compilers. If you specify data alignment, in most cases you
either need it, or your application simply does not function. There is
no "optional" support. Relying on compiler-specific alignment
attributes may make portability a bit of an issue, but at least it
provides guarantees that you are getting precisely what you ask for,
which C++0x attributes do not. If alignment is going to be part of the
language, support should be required, otherwise it should not be made
part of the language, as developers requiring reliable support will
default to reliable compiler-specific attributes anyways, disregarding
C++0x's entirely. "Align" is, again, an example of a poor choice for
an attribute because it has direct effects on generated code and is
broken when made optional.

Things like "deprecated" are much more appropriate for attributes --
with something like "deprecated", it does indeed take the place of
documentation, and does not place constraints on code or have direct
effects on compilation. Things like, say, "const" are not appropriate
for attributes. Imagine if "const" were an attribute, without a
requirement of compiler support: The notion of "const-correctness"
basically moves from common knowledge to the realm of obscure
nitpicking, if not going out the window entirely, as the amount of
programmers actually using it may be significantly reduced by poor
support of conforming (and non-confirming) compilers. I believe a
similar scenario applies to "final".

Bottom line: It seems to have been a poor (shameful, even) and
nonsensical choice to make "final" an attribute, as well as
"align" (assuming it is, I may be wrong and that may have been changed
to something not an attribute since the last time I looked). As a
required keyword, it would reliably serve its purpose, at least on
conforming compilers, and because of similarities with the existing
language, would probably be more likely to be accepted by certain non-
conforming, yet important, compilers as well. On the other hand, I
believe "override" would greatly benefit from being a keyword rather
than an attribute, but even as an attribute it could still serve its
purpose adequately, if not reliably.

Jason

References:
[1] http://www.codeguru.com/forum/showthread.php?t=466893 (post #14 by
joncaves)
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2784.html
(7.1, motion 8)


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

JC wrote:
>
> On Jan 1, 3:59 am, James Kanze <james.ka...@gmail.com> wrote:
>>
>> On Dec 31, 6:13 am, James Kuyper <jameskuy...@verizon.net> wrote:

....
>>>
>>> JC wrote:
>>>>
>>>> On Dec 30, 10:46 am, James Kanze <james.ka...@gmail.com> wrote:
>>>
>>> ....
>>>>>
>>>>> Yes.  Logically, there are two orthogonal issues: does this
>>>>> function override a virtual function in a base class or not, and
>>>>> can it be overridden in a derived class.  This gives four types
>>>>> of functions, and it would be nice to have to specify for each
>>>>> function which it is.  Doing so would simply break all existing
>>>>> C++ code, however, so is pretty much out of the question.

....
>>
>> If I were designing the language today (without any concerns of
>> existing code), then I'd use:
>>
>>   /* nothing */    doesn't override, cannot be overridden
>>   virtual          doesn't override, can be overridden
>>   overrides        overrides, can be overridden
>>   final            overrides, can't be overridden
>>
>> But of course, that would break a lot of code.  (And I should
>> have been clearer that this is what I meant when I said it would
>> break all existing code.)  Adding overrides and final, without
>> changing the current defaults, would probably be an acceptable
>> compromise.  But it's far too late for a proposal this round of
>> standardization.
>
> Nobody suggested adding keywords like that, nor would anybody want
> them.

James Kanze isn't "nobody", and he did indeed suggest the basic idea
in his earlier message quoted above, though not in as much detail as
in his later message. He said, of this idea, that "it would be nice",
and later says that "If I were  designing the language today, ... I'd
use". This make it pretty clear that he, at least, does want them.

> ... The discussion about it is somewhat irrelevant. The suggestion
> was for the following and nothing more:

There's a prohibition somewhere on extending your suggestion?

> ... Whatever extra rules or
>
> keywords/attributes you are bringing up are, to be honest, confusing
> the heck out of me. Where are they coming from? Am I missing
> something?

They are coming from him. What you're apparently missing is his right
to extend to your suggestion with a further suggestion of his own.

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

Francis Glassborow wrote:
>
> Well it is in the current Committee Draft. And please note that one of
> the strengths of attributes is that they allow programmers to document
> intent in the code and enable compilers to help support their intentions
> without requiring that they do so. One of the important features of
> attributes is that if the code compiles both with and without the
> attribute the observed behaviour should be the same. An attribute might
> make otherwise well-formed code fail to compile but IMHO it should never
> work the other way round.

Not all attributes can be safely ignored. For example ignoring the
alignas attribute may cause serious problems in certain cases. (The
code should compile, but the program may crash badly in the case that
the align attribute is ignored).

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

I really like the idea of an override specification, I've wished for
it many times myself.  I did think of a workaround that gives you
something similar though:

template <class A,class B,class T>
inline void overrides(T A::*,T B::*)
{
}

struct A {
 virtual void f(int) { }
 virtual ~A() { }
};

struct B {
 void f(float) { overrides(&A::f,&B::f); } // compile error because
the type signatures do not match.
};

A more sophisticated version could probably be created that handles
covariant types properly with some of the Boost techniques.

 - Vaughn

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

On Jan 1, 11:42 pm, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> JC wrote:

      [...]
> > In any case, I personally don't feel the need for things
> > like "not_sealed" and "not_an_override", and it isn't part
> > of the original suggestion. They certainly would break
> > existing code, and that is not desirable. It would instead
> > make more sense to have the default if "sealed" or
> > "override" was not specified be "not sealed" and "not
> > override", and that is part of the original suggestion.
> > Opposite keywords/attributes do not make sense for the same
> > reason a "nonconst" modifier does not make sense.

> But it does. If we were designing a language from scratch,
> 'const' would be the default and storage we wanted to modify
> would need to be explicitly declared mutable. There are
> several places where the current default (and they will remain
> exactly because we do not wish to break existing code) is
> exactly wrong.

There are lots of cases where I'm not too happy with the default
in C++, but I'm not sure this is one of them.  Most of the time,
all of the member variables are mutable---you can't really
support value semantics otherwise.  And for entity types, const
functions are the exception.  So for these two large categories,
const is really only a good default for member functions of
objects with value semantics (and then, of course, only when
said member function doesn't have an '=' in its name---a const
operator= should be rather exceptional).

> In the case of override, we want to prevent accidental
> overriding.

Accidental overriding is probably less of a problem than
accidentally not overriding when you meant to, at least in my
experience.  All that's necessary is that the base function is
declared const, and you forget the const, or vice versa.  Of
course, most of the time, the compiler detects the problem,
because it's fairly rare to want to override a function which
isn't pure virtual (so you get an error when you try to
instantiate the class), but it does happen.

Accidental overriding seems to be less of a problem, since all
of the virtual functions of the base class are part of the
documented interface.

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 2, 9:41 am, James Kuyper <jameskuy...@verizon.net> wrote:
> JC wrote:

      [...]
> >> If I were designing the language today (without any
> >> concerns of existing code), then I'd use:

> >>   /* nothing */    doesn't override, cannot be overridden
> >>   virtual          doesn't override, can be overridden
> >>   overrides        overrides, can be overridden
> >>   final            overrides, can't be overridden

> >> But of course, that would break a lot of code.  (And I
> >> should have been clearer that this is what I meant when I
> >> said it would break all existing code.)  Adding overrides
> >> and final, without changing the current defaults, would
> >> probably be an acceptable compromise.  But it's far too
> >> late for a proposal this round of standardization.

> > Nobody suggested adding keywords like that, nor would
> > anybody want them.

> James Kanze isn't "nobody", and he did indeed suggest the
> basic idea in his earlier message quoted above, though not in
> as much detail as in his later message. He said, of this idea,
> that "it would be nice", and later says that "If I were
> designing the language today, ... I'd use". This make it
> pretty clear that he, at least, does want them.

Sort of.  It's clear that I think such an idea has a certain
number of advantages; it allows the compiler to enforce things
that I otherwise enforce by documentation and code review (and
while good code reviewers don't miss much, the compiler misses
even less).  On the other hand, I also have a lot of existing
C++ code that I don't want to have to rewrite.  Enough so that I
consider that the cost outweighs the advantages, and I'd argue
against such a change in the existing language.  It's just
something to think of if anyone is designing a new 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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 1, 11:43 pm, blargg....@gishpuppy.com (blargg) wrote:
> JC wrote:

      [...]
> By the way, I wrote about the same idea years ago on a web
> page ("sealed" was called "final"), with plenty of examples. I
> found ways of applying final to objects too.

There was some discussion in the committee concerning adding a
keyword final, some years back (when I was a lot more active in
it than I am now).  For whatever reasons, the idea didn't seem
to fly with the committee members---I suspect part of it had to
do with the fact that the distinction between a final class
(which couldn't be derived from) and a final function (which
couldn't be overridden) wasn't really being made, and there are
apparently very strong reasons not to allow the former.
(Something to do with metaprogramming---I didn't understand
enough metaprogramming then to follow, but from what I know now,
I suspect that the ability to derive from a type could be used
to distinguish class types from other types.)

--
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++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]