On Apr 23, 8:09 pm, "Marco Nef" <maill...@shima.ch> wrote:
> When refactoring an application with lots of classes one of the most
> dangerous things are virtual / abstract methods. Today one does not
> have to repeat the virtual keyword in derived classes. So when
> refactoring / reading an interface it is not obvious which methods are
> virtual overrides. I think it would be an advantage if the the
> standard required the repeated declaration of virtual.
>
> class A
> {
>   virtual f() = 0;
>
> };
>
> class B : public A
> {
>   f() { ... }                // Does compile today, but shall not anymore.
>   virtual f() { ...}       // Does compile today and shall forever.
>
> };

I don't really see much need for that. A conforming implementation
today can warn you about the "dangerous" case anyway, and you can
compile with warnings as errors if you want. If your implementation
doesn't do that, then you may want to raise the issue with its
authors, as it's a reasonable thing to warn about.


--
[ 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 Apr 24, 5:09 am, "Marco Nef" <maill...@shima.ch> wrote:
> When refactoring an application with lots of classes one of the most
> dangerous things are virtual / abstract methods. Today one does not
> have to repeat the virtual keyword in derived classes. So when
> refactoring / reading an interface it is not obvious which methods are
> virtual overrides. I think it would be an advantage if the the
> standard required the repeated declaration of virtual.
>
> class A
> {
>   virtual f() = 0;
> };
>
> class B : public A
> {
>   f() { ... }                // Does compile today, but shall not anymore.
>   virtual f() { ...}       // Does compile today and shall forever.
> };
>
> The only argument against this idea that I can think of is
> compatibility. But as the compiler shows an error with a (hopefully)
> self-describing message there is no danger of error.

Unfortunately this "only" argument is a very important one. If this
proposal would be introduced, it would cause a significant portion
of currently valid *working* and *well-defined* C++ code to break.

But there is still hope. Note that the currently discussed paper

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html

proposes an attribute-based approach, that would exactly solve
your problem via a non-breaking mechanism. Using the proposed
attribute syntax, B would be written as

class B [[check_names]] : public A
{
   f [[override]] () { }  // OK
   virtual f [[override]] () { ...}   // Also OK
   f() { }  // Error: overriding without [[override]]
};

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ 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                      ]

Marco Nef wrote:
> Hi there
>
> When refactoring an application with lots of classes one of the most
> dangerous things are virtual / abstract methods. Today one does not
> have to repeat the virtual keyword in derived classes. So when
> refactoring / reading an interface it is not obvious which methods are
> virtual overrides. I think it would be an advantage if the the
> standard required the repeated declaration of virtual.
>
> class A
> {
>  virtual f() = 0;
> };
>
> class B : public A
> {
>  f() { ... }                // Does compile today, but shall not anymore.
>  virtual f() { ...}       // Does compile today and shall forever.
> };
>
> The only argument against this idea that I can think of is
> compatibility. But as the compiler shows an error with a (hopefully)
> self-describing message there is no danger of error.
>                  ]
>

There's a proposal
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html) in
the latest mailing that does something similar using the new attributes
syntax.

Joe Gottman

--
[ 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                      ]

Hi Marco,

On Apr 24, 12:14 pm, "Marco Nef" <maill...@shima.ch> wrote:
> When refactoring an application with lots of classes one of the most
> dangerous things are virtual / abstract methods. Today one does not have to
> repeat the virtual keyword in derived classes. So when refactoring / reading
> an interface it is not obvious which methods are virtual overrides. I think
> it would be an advantage if the the standard required the repeated
> declaration of virtual.

Have a look at this paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html

It (and the papers it references) discusses issues related to this
concern and proposes a solution that I believe would address your
issue. Requiring derived classes to always re-specify virtual would
break a lot of code and has other problems (e.g. it won't catch cases
where the function you intended to override doesn't actually exist in
the base class or has a slightly different type).

Stefanus


--
[ 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 Apr 24, 9:38 pm, daniel.krueg...@googlemail.com wrote:
> On Apr 24, 5:09 am, "Marco Nef" <maill...@shima.ch> wrote:
> > When refactoring an application with lots of classes one of
> > the most dangerous things are virtual / abstract methods.
> > Today one does not have to repeat the virtual keyword in
> > derived classes. So when refactoring / reading an interface
> > it is not obvious which methods are virtual overrides. I
> > think it would be an advantage if the the standard required
> > the repeated declaration of virtual.

> > class A
> > {
> >   virtual f() = 0;
> > };

> > class B : public A
> > {
> >   f() { ... }                // Does compile today, but shall not anymore.
> >   virtual f() { ...}       // Does compile today and shall forever.
> > };

> > The only argument against this idea that I can think of is
> > compatibility. But as the compiler shows an error with a
> > (hopefully) self-describing message there is no danger of
> > error.

> Unfortunately this "only" argument is a very important one. If
> this proposal would be introduced, it would cause a
> significant portion of currently valid *working* and
> *well-defined* C++ code to break.

> But there is still hope. Note that the currently discussed paper

> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html

> proposes an attribute-based approach, that would exactly solve
> your problem via a non-breaking mechanism. Using the proposed
> attribute syntax, B would be written as

> class B [[check_names]] : public A
> {
>    f [[override]] () { }  // OK
>    virtual f [[override]] () { ...}   // Also OK
>    f() { }  // Error: overriding without [[override]]
> };

Presumably, there's also a proposal for an attribute to make
functions "final".

Basically, there are two almost orthogonal aspects to be
considered: does this function override a function in a base
class (or rather, was that the intent, and I want an error if it
doesn't), and can this function be overridden in a derived
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 24 Apr., 05:09, "Marco Nef" <maill...@shima.ch> wrote:
> Hi there
>
> When refactoring an application with lots of classes one of the most
> dangerous things are virtual / abstract methods. Today one does not
> have to repeat the virtual keyword in derived classes. So when
> refactoring / reading an interface it is not obvious which methods are
> virtual overrides.

True. But is an explicit "virtual" for overriding really any better?

There *are* more ambitious proposals: Expressing the overriding intent
explicitly since using (or not using) "virtual" might just declare a
new virtual (or non-virtual) function by accident instead of
overriding a base class virtual function. See the following proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html

The syntax is not that pretty -- especially considering the asymmetry
between "virtual" and "[[override]]" -- but at least it enables you to
document what you meant and enables the compiler to check that. Also,
it doesn't render old C++ code invalid.

I would have liked to see an override keyword which is placed infront
of the function's declaration instead of an attribute behind the
function's name ...

Then again, if you stick to publicly deriving from abstract base
classes only, you shouldn't run into those problems since any
accidental non-overriding makes your class also abstract and thus not
constructible.

If you virtual functions to be overridden by saying "virtual" this
would be a rule for your coding standard.


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                      ]

Marco Nef wrote:

> Hi there
>
> When refactoring an application with lots of classes one of the most
> dangerous things are virtual / abstract methods. Today one does not
> have to repeat the virtual keyword in derived classes. So when
> refactoring / reading an interface it is not obvious which methods are
> virtual overrides. I think it would be an advantage if the the
> standard required the repeated declaration of virtual.
>
<snip>
> The only argument against this idea that I can think of is
> compatibility. But as the compiler shows an error with a (hopefully)
> self-describing message there is no danger of error.

There is indeed not a great danger of errors, but there is an enormous
danger of large numbers of programmers being unable to do their jobs
because the third-party libraries they use have not yet caught up with
the new requirement.

That is the big problem with breaking compatibility: All those millions
of lines of code that have to be updated and retested and revalidated
without any benefit.

>
> Marco
>
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/


[ 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 26 Apr., 00:12, James Kanze <james.ka...@gmail.com> wrote:
> On Apr 24, 9:38 pm, daniel.krueg...@googlemail.com wrote:

[..]

> > But there is still hope. Note that the currently discussed paper
> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html
> > proposes an attribute-based approach, that would exactly solve
> > your problem via a non-breaking mechanism. Using the proposed
> > attribute syntax, B would be written as
> > class B [[check_names]] : public A
> > {
> >    f [[override]] () { }  // OK
> >    virtual f [[override]] () { ...}   // Also OK
> >    f() { }  // Error: overriding without [[override]]
> > };
>
> Presumably, there's also a proposal for an attribute to make
> functions "final".

<nod>, you are right, James, and it's already part of the current
draft. As of 7.6.4 [dcl.attr.final] :

"1 The attribute-token final specifies overriding semantics for a
virtual function. It shall appear at most once in each attribute-list
and no attribute-argument-clause shall be present. The attribute
applies to class definitions and to virtual member functions being
declared in a class definition. If the attribute is specified for a
class definition, it is equivalent to being specified for each
virtual
member function of that class, including inherited member
functions.

2 If a virtual member function f in some class B is marked final
and in a class D derived from B a function D::f overrides B::f, the
program is ill-formed; no diagnostic required.

3 [ Example:
struct B {
   virtual void f [[ final ]] ();
};
struct D : B {
   void f(); // ill-formed
}; ?end example ]

> Basically, there are two almost orthogonal aspects to be
> considered: does this function override a function in a base
> class (or rather, was that the intent, and I want an error if it
> doesn't), and can this function be overridden in a derived
> class.

Yes.

Greetings from Bremen,

- Daniel


--
[ 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                      ]

> But there is still hope. Note that the currently discussed paper
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2852.html
>
> proposes an attribute-based approach, that would exactly solve
> your problem via a non-breaking mechanism. Using the proposed
> attribute syntax, B would be written as

Thank you for the link. This would really solve the problem and some other.
Just that it is not coded in the base classes and by that not derived.
But I
understand the compatibility issue. That issue could also be solved by
having compiler flags like "this is old code" and "this is new code". Like
that the external library from the seventies could be included, tagged by a
flag.

But really: The syntax of the proposal is the worst thing I've ever
seen! It
makes the code not readable anymore, mainly because the attributes are
placed between the function name and its parameters. I would rather want 50
new keywords than that...

Example taken from the linked page and adopted:

struct base
{
   virtual void some_func();
   virtual void h(int);
};
struct checknames derived1 : base
{
   void some_func();  // error, accidental override with check_names
attribute
};
struct checknames derived2 : base
{
   override void some_func(); // OK, override with virtual keyword
   virtual hiding void h(char*); // OK, new virtual function hides base
};

Marco


--
[ 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                      ]

Hi there

When refactoring an application with lots of classes one of the most
dangerous things are virtual / abstract methods. Today one does not
have to repeat the virtual keyword in derived classes. So when
refactoring / reading an interface it is not obvious which methods are
virtual overrides. I think it would be an advantage if the the
standard required the repeated declaration of virtual.

class A
{
  virtual f() = 0;
};

class B : public A
{
  f() { ... }                // Does compile today, but shall not anymore.
  virtual f() { ...}       // Does compile today and shall forever.
};

The only argument against this idea that I can think of is
compatibility. But as the compiler shows an error with a (hopefully)
self-describing message there is no danger of error.

Marco

--
[ 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                      ]

Hi there

When refactoring an application with lots of classes one of the most
dangerous things are virtual / abstract methods. Today one does not have to
repeat the virtual keyword in derived classes. So when refactoring / reading
an interface it is not obvious which methods are virtual overrides. I think
it would be an advantage if the the standard required the repeated
declaration of virtual.

class A
{
     virtual f() = 0;
};

class B : public A
{
     f() { ... }                // Does compile today, but shall not
anymore.
     virtual f() { ...}       // Does compile today and shall forever.
};

The only argument against this idea that I can think of is compatibility.
But as the compiler shows an error with a (hopefully) self-describing
message there is no danger of error.

Marco


--
[ 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                      ]