Topic: Defect report: abstract final classes


Author: "Richard Smith"<richard@metafoo.co.uk>
Date: Thu, 1 Dec 2011 07:51:23 -0800 (PST)
Raw View
Hi,

C++11 permits an abstract class to be marked final. Such a class is nearly
useless, and very likely to indicate user error. The clang developers would
very much like to treat such classes as ill-formed; see:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018865.html

Thanks,
Richard


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




Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@googlemail.com>
Date: Thu, 1 Dec 2011 13:05:36 -0800 (PST)
Raw View
On 2011-12-01 16:51, Richard Smith wrote:
>
> C++11 permits an abstract class to be marked final. Such a class is nearly
> useless, and very likely to indicate user error. The clang developers would
> very much like to treat such classes as ill-formed; see:
>
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-November/018865.html

<nod> I recently posted a similar problem description to the LWG, the
situation is even worse:

a) There is no requirement for a virtual class, just define

struct F1 final {};

b) The problem extends to other situations as well, where the
destructor is final, like in

struct F2 {
 virtual ~F2() final;
};

The problem is expected to be observed not too rarely in the future,
once people start to use final in their daily code, because nowadays
libraries use EBCO quite extensively.

As a short term solution libraries will need an intrinsic that tests
whether given some type T the derived class definition

struct derived : T {};

would be well-formed.

Further, "user-code", especially third-party libraries, will
presumably need a standardized trait, e.g. std::is_derivable to
realize the same thing.

Hopefully there will be other long-term solutions, where final classes
or final destructors do not have such draw-backs. One idea that is
currently thought of is to invent a new attribute - name it
[[allow_empty]] - that can be even used for data members to allow
empty-data-member-optimization:

template<class T>
struct C {
      [[allow_empty]] T t;
};

This last approach is very appealing because this would actually
promote better programming practices that do not abuse inheritance for
space optimization purposes.

HTH & Greetings from Bremen,

- Daniel Kr   gler


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