"Metaclasses: Thoughts on generative C++" 2017-07-26 by Herb Sutter

[Lynn McGuire]

"Metaclasses: Thoughts on generative C++" 2017-07-26 by Herb Sutter
https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/

"I’ve been working on an experimental new C++ language feature
tentatively called “metaclasses” that aims to make C++ programming both
more powerful and simpler."

Looks a little complicated to this old Fortran hacker.

Lynn

[Alf P. Steinbach]

I haven't looked at it but in Smalltalk terminology a metaclass is the
class of class. Because in Smalltalk a class is an object, so, it's an
object of some class: its metaclass. I fear if Herb's metaclasses are
something else, then we're in for some terminological confusion.

Anyway, the only C++ features that I miss – or that I see as clearly
missing in the language – apart from modules, are support for covariant
features, e.g. a clone method, and support for expressing const and
non-const variants of a member function, in a concise & clear way.



Cheers!,

- Alf

[David Brown]

I'd like to see something Ada attributes for types. I had a little look
at the proposed "reflections" for C++20, and they are an overly complex
mess. It should be simple to get a compile-time method of doing things
like converting enum names back and forth with values, or finding the
maximum value in an enum. For a struct, you should be able to iterate
over the data fields with name and types - it would be marvellous for
database programming. This is all information that the compiler knows
anyway, but it is inaccessible to the programmer.

[woodb...@gmail.com]

I think C++ 2023 is the earliest that would have a
chance. In the meantime, the C++ Middleware Writer
automates the creation of serialization functions.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Scott Lurndal]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>On 26.07.2017 19:06, Lynn McGuire wrote:
>> "Metaclasses: Thoughts on generative C++" 2017-07-26 by Herb Sutter
>> https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/

>

>I haven't looked at it but in Smalltalk terminology a metaclass is the
>class of class. Because in Smalltalk a class is an object, so, it's an
>object of some class: its metaclass. I fear if Herb's metaclasses are
>something else, then we're in for some terminological confusion.

The proposal is more related to introspection and his metaclasses
are more like a template for the underlying 'struct'/'class' semantics
within the compiler itself.

[Scott Lurndal]

woodb...@gmail.com writes:
>On Wednesday, July 26, 2017 at 12:06:33 PM UTC-5, Lynn McGuire wrote:
>> "Metaclasses: Thoughts on generative C++" 2017-07-26 by Herb Sutter

>> https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-=
>c/
>>=20
>> "I=E2=80=99ve been working on an experimental new C++ language feature=20
>> tentatively called =E2=80=9Cmetaclasses=E2=80=9D that aims to make C++ pr=
>ogramming both=20
>> more powerful and simpler."
>>=20

>> Looks a little complicated to this old Fortran hacker.

>>=20
>> Lynn
>
>
>I think C++ 2023 is the earliest that would have a=20
>chance.

Gratuitous advertisement elided.

Note that the aforementioned feature is already implemented
in clang.

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<olahui$707$1...@dont-email.me> thusly:

It's easier to understand if you watch the YouTube video from ACCU 2017:

Thoughts on Metaclasses
<https://www.youtube.com/watch?v=6nsyX37nsRs>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[woodb...@gmail.com]

Concepts were implemented in a C++ compiler around 2008.
Not sure of the year, but it was before 2011. Possibly in
2020 Concepts will become a part of C++.


Brian
Ebenezer Enterprises - "We few, we happy few, we band of
brothers." http://shakespeare.mit.edu/henryv/henryv.4.3.html

http://webEbenezer.net

[Manfred]

The thing looks of some appeal, but then rethinking about it I recalled
what I had experienced in large organizations about code generation.

'Cause the thing is closely related with code generation, and I recalled
things like an 'interface' metaclass being considered, and then
discarded, because, even if they are of wide use:
They are typically intentionally designed to be very thin, not to pose
excessive overhead on the project as a whole. The advantage of having
them generated is therefore very limited - since they are designed to be
thin, it is trivial to write an interface class in plain C++.
And on the other hand, adding the new feature to the framework (or even
the language as in this case), poses some adaptation costs for the
programmers, so in my experience, when it was considered, it was not
worth it.

This is only my personal experience, so, by definition, very limited.

Moreover, the way I see it, other metaclasses like 'value' tend to pose
too much cost in terms of constraints on the programming ability of the
developer, compared to the gain in enforced project structure.
I mean that, when developing some specific application software (i.e. in
the real world), there can very well be patterns that fit well in the
specific application domain, but deviate from general preferred use - if
you need a 'value' metaclass, I may imagine it can be significantly
customized for the application domain, so I am in doubt if a metaclass
construct would be that more convenient than a plain C++ template class.

Nonetheless, the ability of creating some 'keywords' of your own sounds
appealing.

[Richard]

[Please do not mail me a copy of your followup]

Manfred <non...@invalid.add> spake the secret code
<olfrfh$1h0g$1...@gioia.aioe.org> thusly:

>'Cause the thing is closely related with code generation, and I recalled
>things like an 'interface' metaclass being considered, and then
>discarded, because, even if they are of wide use:
>They are typically intentionally designed to be very thin, not to pose
>excessive overhead on the project as a whole. The advantage of having
>them generated is therefore very limited - since they are designed to be
>thin, it is trivial to write an interface class in plain C++.

I agree with your analysis ('interface' is thin), but disagree with
your conclusion.

I have seen lots of people write 'interface' classes where they forget
the virtual d'tor or implementation methods start leaking into the
interface, or they have other concrete methods in the interface.

Having a compiler enforce what it means for something to be an
interface is a solution to all these problems that arise from a lack
of self discipline.

If we considered it sufficient to rely on self discipline alone, then
we would just use C. But we don't, we value the extra checks that the
type system of C++ can provide and we lean on that to prevent
ourselves from getting sloppy in this regard.

I found the more compelling examples to be in his YouTube video, which
I encourage you to watch if you've only looked at the proposal and the
blog post. The flags enum example was particularly useful. He also
shows how it cleans up a whole bunch of crufty things like having to use
IDL compilers or the Qt moc compiler, making them entirely unnecessary
without imposing costs on people who don't use these facilities.
Furthermore, having them be testable libraries that can be distributed,
tested, improved upon and ultimately standardized via the library working
group is much better for the community than attempting to standardize
them through the language working group in the standards body.

One advantage of the approach advocated by Herb Sutter is that if you
don't like these metaclasses, you're not paying for them in any way.
Even if the standard library starts using them in conjunction with
concepts, I can't see that any of your code would be affected by their
use. If you provide implementations that are different from the
default supplied by a metaclass, it doesn't change your code.

[Alf P. Steinbach]

On 29.07.2017 00:35, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Manfred <non...@invalid.add> spake the secret code
> <olfrfh$1h0g$1...@gioia.aioe.org> thusly:
>
>> 'Cause the thing is closely related with code generation, and I recalled
>> things like an 'interface' metaclass being considered, and then
>> discarded, because, even if they are of wide use:
>> They are typically intentionally designed to be very thin, not to pose
>> excessive overhead on the project as a whole. The advantage of having
>> them generated is therefore very limited - since they are designed to be
>> thin, it is trivial to write an interface class in plain C++.
>
> I agree with your analysis ('interface' is thin), but disagree with
> your conclusion.
>
> I have seen lots of people write 'interface' classes where they forget
> the virtual d'tor or implementation methods start leaking into the
> interface, or they have other concrete methods in the interface.
>
> Having a compiler enforce what it means for something to be an
> interface is a solution to all these problems that arise from a lack
> of self discipline.

One nice feature of C++ interfaces is that they can include shallow
public non-virtual wrapper methods for the private or protected virtual
methods. For example, a public method can check preconditions and
possibly also some postcondition. Java lacks this nicety.

Then we already have two kinds of interfaces: pure Java-style, with only
virtual methods, and C++ style, with a mix.

But wait, Java-style... Then one needs to use virtual inheritance to
support inherit-in-an-implementation. I hope Herb's thing doesn't
enforce that: usually people find the virtual inheritance cost unacceptable.


Cheers!,

- Alf

[David Brown]

On 29/07/17 00:35, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Manfred <non...@invalid.add> spake the secret code
> <olfrfh$1h0g$1...@gioia.aioe.org> thusly:
>
>> 'Cause the thing is closely related with code generation, and I recalled
>> things like an 'interface' metaclass being considered, and then
>> discarded, because, even if they are of wide use:
>> They are typically intentionally designed to be very thin, not to pose
>> excessive overhead on the project as a whole. The advantage of having
>> them generated is therefore very limited - since they are designed to be
>> thin, it is trivial to write an interface class in plain C++.
>
> I agree with your analysis ('interface' is thin), but disagree with
> your conclusion.
>
> I have seen lots of people write 'interface' classes where they forget
> the virtual d'tor or implementation methods start leaking into the
> interface, or they have other concrete methods in the interface.
>
> Having a compiler enforce what it means for something to be an
> interface is a solution to all these problems that arise from a lack
> of self discipline.
>
> If we considered it sufficient to rely on self discipline alone, then
> we would just use C. But we don't, we value the extra checks that the
> type system of C++ can provide and we lean on that to prevent
> ourselves from getting sloppy in this regard.

Like many features in C++, there is a lot here that could be of some
interest to many people, but major use-cases (like a good "interface"
metaclass) involves a lot more thought, testing, discussion, knowledge
and experience than most developers can provide. But that's okay -
that's why we have a standard library.

What proportion of C++ programmers could honestly say they could make a
full implementation of std::unique_ptr, or std::move ? They are
implemented using normal C++11, with features like templates, classes,
overloading, rvalue references, etc., that can be useful for many
programmers.

The same, I think, applies to metaclasses. When they hit the standards,
they will be accompanied by a set of standard metaclasses like
interface, value, literal, flags_enum, etc. No one will expect "normal"
C++ programmers to write their own interface metaclasses.

[woodb...@gmail.com]

Anyone who thinks on-line code generation is not here
to stay needs counseling.

> without imposing costs on people who don't use these facilities.
> Furthermore, having them be testable libraries that can be distributed,
> tested, improved upon and ultimately standardized via the library working
> group is much better for the community than attempting to standardize
> them through the language working group in the standards body.
>
> One advantage of the approach advocated by Herb Sutter is that if you
> don't like these metaclasses, you're not paying for them in any way.

I think other alternatives capture the essence of C++
better, but it will be interesting to see how it unfolds.

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<olgi1c$36l$1...@dont-email.me> thusly:

>On 29.07.2017 00:35, Richard wrote:
>> I have seen lots of people write 'interface' classes where they forget
>> the virtual d'tor or implementation methods start leaking into the
>> interface, or they have other concrete methods in the interface.
>>
>> Having a compiler enforce what it means for something to be an
>> interface is a solution to all these problems that arise from a lack
>> of self discipline.
>
>One nice feature of C++ interfaces is that they can include shallow
>public non-virtual wrapper methods for the private or protected virtual
>methods. For example, a public method can check preconditions and
>possibly also some postcondition. Java lacks this nicety.

>[...]

>I hope Herb's thing doesn't
>enforce that: usually people find the virtual inheritance cost unacceptable.

Since it's a library you can define your own idea of the requirements
of an interface or whatever you want to call it. Personally, I would
stick to interface being a pure abstract base class and what you
describe above is simply a base class, so 'base_class' derives from
'interface'.

The advantage of what Herb is proposing is that these choices --
does 'interface' for our team mean abstract base class? -- are left up
to you based on what libraries you consume and/or write. His proposed
metaclasses give you this general mechanism without requiring the
language to impose a particular interpretation on you as a user of the
language and if you're not using any of this stuff, you're not paying
for it.

However, if this mechanism makes it into the language then I see the
standard library evolving to encompass a tried-and-tested library of
such standard metaclasses and I would not be surprised if the thing
named 'interface' ends up being a pure abstract base class and not a
combination of pure virtual methods and base class methods.

[Alf P. Steinbach]

I think you misunderstood me.

In Eiffel, as I recall, an interface can be adorned with preconditions
and postconditions on methods.

This is also possible in C++, though not as a language feature: it must
be done as wrappers. There was a DBC proposal once, to get core language
support (including maybe syntax). It stranded.

With Java you're restricted to a silly semantics-less notion of
interface. It would be sad to have that imposed on C++.


Cheers!,

- Alf

[Alf P. Steinbach]

On 02.08.2017 14:57, Stefan Ram wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

>> In Eiffel, as I recall, an interface can be adorned with preconditions
>> and postconditions on methods.
>> This is also possible in C++, though not as a language feature: it must
>> be done as wrappers. There was a DBC proposal once, to get core language
>> support (including maybe syntax). It stranded.
>> With Java you're restricted to a silly semantics-less notion of
>> interface. It would be sad to have that imposed on C++.
>

> Do you want to say that in Java one cannot write
> wrappers at least as one can do in C++?
>
> I am not sure whether I understood your requirements,
> but here's a Java program that prints »-22«:
>
> The interface Negate defines some conditions for an
> implementation via assertations in a wrapper.
>
> The class NegateImpl then provides the implementation
> and the client Main calls it via a method that does the
> assertations.
>
> interface Negate
> {
> /** Returns the negative of its argument.
> @param arg a number between -2000000000 and 2000000000.
> @return the negative of arg */
> default int negate( final int arg )
> { assert arg <= 2000000000;
> assert arg >= -2000000000;
> final int result = negateImpl( arg );
> assert result + arg == 0;
> return result; }
>
> /** Returns the negative of its argument.
> @param arg a number between -2000000000 and 2000000000.
> @return the negative of arg */
> int negateImpl( int arg ); }
>
> class NegateImpl implements Negate
> { public int negateImpl( final int arg )
> { return -arg; }}
>
> public final class Main
> { public static void main( final java.lang.String[] args )
> { final Negate negate = new NegateImpl();
> java.lang.System.out.println( negate.negate( 22 )); }}
>
> This is one example. Java offers several similar
> possibilities by other means, like abstract classes
> (to hide the implementation method »negateImpl«).

Looks like things have changed.

In Java 7 the language spec said “Every method declaration in the body
of an interface is implicitly abstract, so its body is always
represented by a semicolon, not a block”.

But Java 8 introduced the `default` mechanism. I wasn't aware of that.
It's discussed in <url:
https://stackoverflow.com/questions/31578427/what-is-the-purpose-of-the-default-keyword-in-java>.

Thanks for that feedback!


Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code

<ols2m8$brf$1...@dont-email.me> thusly:

>In Eiffel, as I recall, an interface can be adorned with preconditions
>and postconditions on methods.

Uh... if you want to impose precondition and postcondition
verificatino you can do that right now with existing mechanisms. This
seems unrelated to metaclasses, although I suppose you could use
metaclasses to generate the post/precondition validating boiler plate.

That's all metaclasses are doing: give you a better way of doing
boiler plate than external tools (Qt's moc, COM's IDL) or macros.

>With Java you're restricted to a silly semantics-less notion of
>interface. It would be sad to have that imposed on C++.

Have you watched the video? There is no "imposition" being discussed.

[Ross A. Finlayson]

These days Java seems a lot more well read.

Though, maybe there's as much C++ written, these days.

I almost always find Java well-engineered (the language
and the libraries).

Now I'm thinking of the program model and the runtime
and especially the JVM loading with commands that run
Java, here C++ definitely excels in the extended program
model for example a process model. It loads so much faster
then to the idea of breaking up the commands and otherwise
starting the virtual machine each time with then the
idea of the "java" server basically running refreshed
versions of the environment. (Just as an example of
an accommodation for Java that C++ would make "simple".)

[asetof...@gmail.com]

With all as object and Objects Oriented languages, especially C++ even in old standards
that allow to write constructor and destructor of objects too
All it is already easy
(if one not use too much portion of language)

I think would more easy if something goes wrong in a object
the object has some flag that say that object is wrong and one place where there is the last error it meet

If I name that error object with

E

Than each operator or function use E as argument for calculate its result has to return as result one error object that I call E'

All this it is easy because if I print one object, the print function check if that is error object
if yes print that would be some error
and who see the program know there is something that went wrong...

Disclaimer:
Yes it is only theory I don't know if this could be ok because I not had implement all this