In article <D552nG.6qw@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
> In article <1995Mar8.071916.2704@mole-end.matawan.nj.us>,
>  <mat@mole-end.matawan.nj.us> wrote:
> >In article <3jfilh$m8s@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:

> >> Sealed classes.
> >
> >Not important enough to add to C++ at this time.
> >
> >Besides, this is the wrong place, and you are using the wrong way, to
> >propose a language extension.
> >
> >And you are about 24 months too late.

>  That is a bit unfair and not necessarily true.
 ...
>  Second, anyone can propose an extension during the
> ANSI public review, and the committee is bound to consider
> such a request (even if only to politely reject it).

True.  It's hard to imagine that anything less than a compelling argument
will be accepted, given that it takes about three meetings for even a good,
sound proposal without glitches of any kind to actually be presented to
the committee as a whole.

 ...
>  Thirdly, the timing and agenda set by the committee
> is not an end, but a plan to achieve a Standard.
> The committee does not decide on the Standard, the National
> Bodies of SC22 make that decision. If they choose, they
> can send the Working Paper back to the committee for revision,
> irrespective of any "plan" of the committee.

True enough--but the hurry is (in part) the requirement of the
organizations to which those national bodies belong that if the
work isn't completed in a certain (fuzzy) time frame, it be abandoned.
(Almost) nobody on the committee wants to rush--but The Powers That
Can Make Us Throw Our Work Away are forcing the point.

 ...
>  Fifthly, whether or not the committee had much,
> or even any, choice in the matter, the details of the
> Standardisation process have been withheld from the users --
> the public. And we are going to PAY for not leaking
> details to the public earlier. More important, the public
> is going to pay.
>
>  A lot of users are going to write comments
> on issues the committee has _already_ considered.
> How can they know, since they do not have access to
> the minutes of meetings?

Then let's make the minutes public--at the appropriate time, when the
committee feels the work is ready to go to the public.

How would you like to take an exam with the exam's grader looking over
your shoulder and taking points away before you've had a chance to check
your work?  How would you like to try to write a proposal with someone
broadcasting your speculations to the proposal's audience before you've
had a chance to decide what belongs in the proposal and what doesn't?

You _need_ some time and space for deliberation before you present the
work.  ANY work.  Would any union contracts ever get written if the entire
membership of the union and every stockholder of the company were given a
seat at the negotiating table?  I think not.

Of course, what's really needed may be a live Rationale document--and
that's what we haven't got.  Most of the answers should be in that
Rationale; we shouldn't have to comb the deliberations to find each one.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

In article <1995Mar11.130641.21198@mole-end.matawan.nj.us>,
 <mat@mole-end.matawan.nj.us> wrote:
> ...
>>  Second, anyone can propose an extension during the
>> ANSI public review, and the committee is bound to consider
>> such a request (even if only to politely reject it).
>
>True.  It's hard to imagine that anything less than a compelling argument
>will be accepted, given that it takes about three meetings for even a good,
>sound proposal without glitches of any kind to actually be presented to
>the committee as a whole.

 I think you have the idea backwards. You seems to be saying
the committee can decide to accept or not accept a proposal. This
is "arse about". It is the world at large which will accept or
reject the _committee's_ proposal. More specifically, the
National Bodies will either accept or reject the _proposed_
Standard for C++.

 The committee's _task_ is to meet the requirements
of SC22 participants. I guess it is ANSI's task to somehow
determine it's position -- which it does partly using the ANSI
public review. How it does that is an internal matter which
will lead by means unknown to me to the USA National Body
vote and comments.


>>  Thirdly, the timing and agenda set by the committee
>> is not an end, but a plan to achieve a Standard.
>> The committee does not decide on the Standard, the National
>> Bodies of SC22 make that decision. If they choose, they
>> can send the Working Paper back to the committee for revision,
>> irrespective of any "plan" of the committee.
>
>True enough--but the hurry is (in part) the requirement of the
>organizations to which those national bodies belong that if the
>work isn't completed in a certain (fuzzy) time frame, it be abandoned.

 There is no such requirement that I know of.
on the contrary, it is quite usual for Working Groups to
fail to deliver the goods on schedule, and ISO regularly
extends the time frame. Exactly that happened at the last
SC22 Plenary. Sam asked for more time and got it --
as a matter of course.

>(Almost) nobody on the committee wants to rush--but The Powers That
>Can Make Us Throw Our Work Away are forcing the point.

 Rot. Certain National Bodies have a vested interest
in a Standard ASAP.

>Then let's make the minutes public--at the appropriate time, when the
>committee feels the work is ready to go to the public.

>How would you like to take an exam with the exam's grader looking over
>your shoulder and taking points away before you've had a chance to check
>your work?  How would you like to try to write a proposal with someone
>broadcasting your speculations to the proposal's audience before you've
>had a chance to decide what belongs in the proposal and what doesn't?

 I wouldn't.

>You _need_ some time and space for deliberation before you present the
>work.

 I agree. I voted AGAINST applying for CD registration
because I did not think we were ready.

 Applying for CD registration is a way of saying
"we're ready for the first review, we have done enough
and are happy enough to receive comments.. and yes, we know
it isn't perfect yet"


>Of course, what's really needed may be a live Rationale document--and
>that's what we haven't got.  Most of the answers should be in that
>Rationale; we shouldn't have to comb the deliberations to find each one.

 I suggest Rationale can be added to the Working Paper itself.
Provided it is _clearly_ marked as such so it is taken as explanatory
rather than normative.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <D5Dxp9.IyG@ucc.su.OZ.AU>,
John Max Skaller <maxtal@Physics.usyd.edu.au> wrote:
>
> I suggest Rationale can be added to the Working Paper itself.
>Provided it is _clearly_ marked as such so it is taken as explanatory
>rather than normative.

 I've just been told that the WP has been edited so that
Rationale and explanatory material is labelled -- and retained -- in the text.
Which I think is a good thing. It is hard to understand -- and verify --
a set of complex rules without knowing the purpose of the rules.

 The ARM is a fine example of a document which uses such
"annotation" effectively. We lost quite a bit dropping the commentary
out to create the initial WP.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <1995Mar8.071916.2704@mole-end.matawan.nj.us>,
 <mat@mole-end.matawan.nj.us> wrote:
>In article <3jfilh$m8s@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
>> Sealed classes.
>
>Not important enough to add to C++ at this time.
>
>Besides, this is the wrong place, and you are using the wrong way, to
>propose a language extension.
>
>And you are about 24 months too late.

 That is a bit unfair and not necessarily true.

 First, Bjarne is slightly guilty of encouraging
people to write extension proposals WELL after there was
a strong feeling in the committee that extensions should
be curtailed.

 Second, anyone can propose an extension during the
ANSI public review, and the committee is bound to consider
such a request (even if only to politely reject it).

 And National Bodies of SC22 can also propose
and/or require extensions at ANY stage in the Standardisation
process -- many have only recently seen the Working Paper
and the recent CD Registration ballot was the first offical
chance they have had to state any requirements formally.

 Thirdly, the timing and agenda set by the committee
is not an end, but a plan to achieve a Standard.
The committee does not decide on the Standard, the National
Bodies of SC22 make that decision. If they choose, they
can send the Working Paper back to the committee for revision,
irrespective of any "plan" of the committee.

 Fourthly, the committee is probably considering
major extensions to the language right now in Austin.
(I refer to partial specialisations). At least, I sure
hope they are, because I think they are important,
and so does the Australian National body. And I suspect
several other National Bodies will agree, as well as
the individual members of the committee.

 Fifthly, whether or not the committee had much,
or even any, choice in the matter, the details of the
Standardisation process have been withheld from the users --
the public. And we are going to PAY for not leaking
details to the public earlier. More important, the public
is going to pay.

 A lot of users are going to write comments
on issues the committee has _already_ considered.
How can they know, since they do not have access to
the minutes of meetings?


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3jfilh$m8s@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
> Sealed classes.
>
>    A sealed class (terminology borrowed from Dylan) is one that prohibits
> derivation.  Andrew Koenig gives a clever method of achieving this in C++
> (see B. Stroustrup "The Design and Evolution of C++", section 11.4.3).
> Here is a variant that I occasionally use:
>
>
> /* Prohibit class derivation; to prevent derivation from a class foo,
>    simply inherit privately and virtually from seal<foo>:
>
>  class foo :  ... private virtual seal<foo> ... { ... };
>
>    Relies on fact that virtual bases must be initialized by leaves.
>    Costs a word of storage in the sealed class. */
>
> template<class T>
> class seal {
>  typedef T thing; // friend T; and friend class T; don't work (why?)
>  friend thing;
>  seal() {};   // only T can access private ctor.
> };
>
>    I propose that the idea of a sealed class be elevated to a language
> construct, largely for efficiency purposes.  If the compiler knows that
> a class is sealed, it may optimize away virtual function dispatch
> through pointers/references to that class.  ...

Not important enough to add to C++ at this time.

Besides, this is the wrong place, and you are using the wrong way, to
propose a language extension.

And you are about 24 months too late.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

>>>>> Timothy Murphy <tmurphy@panix.com> writes:

>    I propose that the idea of a sealed class be elevated to a language
> construct, largely for efficiency purposes.

It seems to me that a good compiler can get the efficiency you mention
without adding another construct.

jason

In article <3jfilh$m8s@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
>Sealed classes.
>
>   A sealed class (terminology borrowed from Dylan) is one that prohibits
>derivation.  Andrew Koenig gives a clever method of achieving this in C++
>(see B. Stroustrup "The Design and Evolution of C++", section 11.4.3).
>Here is a variant that I occasionally use:
>
>
>template<class T>
>class seal {
> typedef T thing;
> friend thing;
> seal() {};
>};
>
>   I propose that the idea of a sealed class be elevated to a language
>construct, largely for efficiency purposes.

 Hm. Generally, as you say, concrete classes should not
be derived from. But it seems far from certain.

 Also, the technique above doesn't quite work.
You need to make the copy constructor private too. Because:

 class X;
 seal<X> x=x; // initialise with self!

 class X : private virtual seal<X> {};
 class Y : X {
  Y() : seal<X> (x) {} // OK!
 };


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Sealed classes.

   A sealed class (terminology borrowed from Dylan) is one that prohibits
derivation.  Andrew Koenig gives a clever method of achieving this in C++
(see B. Stroustrup "The Design and Evolution of C++", section 11.4.3).
Here is a variant that I occasionally use:


/* Prohibit class derivation; to prevent derivation from a class foo,
   simply inherit privately and virtually from seal<foo>:

 class foo :  ... private virtual seal<foo> ... { ... };

   Relies on fact that virtual bases must be initialized by leaves.
   Costs a word of storage in the sealed class. */

template<class T>
class seal {
 typedef T thing; // friend T; and friend class T; don't work (why?)
 friend thing;
 seal() {};   // only T can access private ctor.
};

   I propose that the idea of a sealed class be elevated to a language
construct, largely for efficiency purposes.  If the compiler knows that
a class is sealed, it may optimize away virtual function dispatch
through pointers/references to that class.  Since most instantiable
classes are sealed (or at least should be :-), this could lead to
great gains in efficiency.  Right now, the only way to achieve this is
to use pass-by-value which itself can be quite inefficient and often
leads to semantic confusion as well.  Of course, a really smart
compiler/linker could maintain a complete inheritance graph of an
application and automatically recognize "leaf" classes, but that
can force a lot of recompilation and be generally messy.


-- Timothy S. Murphy: A serious user and admirer of C++.
   tmurphy@panix.com