In article <Cqu0A9.I8u@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>
>Perhaps someone who gets the mailings could compile a list of who has
>had proposals suggested, and how many proposals they have had accepted?
>Then readers here could 'judge' for themselves the situation.  Since the
>votes are suppose to be published in each meetings minutes it should
>be easy to compile such a list, no?
>
 Its not so easy: most proposal initiated by non-members
are submitted by members.

 BTW: I've submitted about 10 proposals for actual
language extensions, all (but the most recent batch) have been
dealt with, and all rejected. Even rejected proposals are valuable:
the ARM contains may "ideas" with annotations one why Bjarne
consider them not good ideas. "Covering the teriitory"
is part of the extensions subgroups job.

 However: some of the things I wanted were also wanted
by others -- such as being able to pass templates to templates
(which has been accepted for template classes).




--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:

RFG> Likewise, the fact that no proposal from any ``outsider'' has
RFG> ever been accepted by the comittee seems to me to be just a bit
RFG> curious.

Now, let me just for argument's sake give an alternative "conspiracy"
theory.  Assume that NO proposal from non-committee members has been
accepted, but several proposals from members have.

The reason is that several committee members, myself included,
blatantly steal reasonable ideas from non-members, work out some
nitty-gritty details (this is mostly footwork, not to be confused with
coceiving the original idea), and then present the result as THEIR
work.  Rarely, if ever, is the original author acknowledged; instead
people hide behind vague references such as "discussed on
comp.lang.c++" or "existing practice."

Let me give you an example: boolean datatype.  Every reasonable
programming language except C has had one for ages.  Every C++ class
library and several other libraries defines one.  Everybody knows what
it is supposed to do.  Yet, Koenig and Bruck write a paper claiming
intellectual rights to it, making big ho-ho how clever it is to make
it a built-in type that takes the values "false" and "true."  Add to
that Stroustrup who chants along by writing an entire section on it in
his "Design and Evolution of C++."

Actually, the whole intellectual theft business is organized by ANSI.
ANSI actively encourages its committees to take existing work, rewording
them in incomprehensible standardese (who else says "ill-formed"
instead of "wrong"), and then publishes the whole lot with a
rubberstamp from ISO.  ISO is pretty gross too; the standard is worked
out (i.e., the intellectual theft is formalized) during the ANSI
meetings, and then a tiny group of international know-it-alls
("technical experts" in ISO lingua) vote "yes" and steal the
intellectual property a second time during the same week.

This is the truth about the C++ standardization committees.
Just vote no.

Dag Bruck

In <DAG.94May31083724@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:

>>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:

>RFG> Likewise, the fact that no proposal from any ``outsider'' has
>RFG> ever been accepted by the comittee seems to me to be just a bit
>RFG> curious.
>
>Now, let me just for argument's sake give an alternative "conspiracy"
>theory.  Assume that NO proposal from non-committee members has been
>accepted, but several proposals from members have.
>
>The reason is that several committee members, myself included,
>blatantly steal reasonable ideas from non-members, work out some
>nitty-gritty details (this is mostly footwork, not to be confused with
>coceiving the original idea), and then present the result as THEIR
>work.  Rarely, if ever, is the original author acknowledged; instead
>people hide behind vague references such as "discussed on
>comp.lang.c++" or "existing practice."
>
>Let me give you an example: boolean datatype.  Every reasonable
>programming language except C has had one for ages.  Every C++ class
>library and several other libraries defines one.  Everybody knows what
>it is supposed to do.  Yet, Koenig and Bruck write a paper claiming
>intellectual rights to it, making big ho-ho how clever it is to make
>it a built-in type that takes the values "false" and "true."  Add to
>that Stroustrup who chants along by writing an entire section on it in
>his "Design and Evolution of C++."
>
>Actually, the whole intellectual theft business is organized by ANSI.
>ANSI actively encourages its committees to take existing work, rewording
>them in incomprehensible standardese (who else says "ill-formed"
>instead of "wrong"), and then publishes the whole lot with a
>rubberstamp from ISO.  ISO is pretty gross too; the standard is worked
>out (i.e., the intellectual theft is formalized) during the ANSI
>meetings, and then a tiny group of international know-it-alls
>("technical experts" in ISO lingua) vote "yes" and steal the
>intellectual property a second time during the same week.
>
>This is the truth about the C++ standardization committees.
>Just vote no.
>
>Dag Bruck

Add to that the fact (from the Weekly World News) that 23% of the ANSI
committee are space aliens and you can see there's a mighty big planetary
problem looming here, folks.  Non-humans are designing the language we'll
all have to put up with for the next 8 years or so, giving Venus a chance
to quietly leapfrog Earth in software development.

Dag didn't tell the whole story, which is _suspicious_ in and of itself.

-simon

(one of us)

===============================================================================
Simon Tooke  (not speaking for) SCO Canada, Inc.         Voice:  (416) 922-1937
....!scocan!simon             simon@sco.com                Fax:  (416) 922-2704
130 Bloor St. West. Suite 1001, Toronto, Ontario, Canada  M5S 1N5

In article <rfgCqMpp7.Ly4@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|Extending it just a bit, let me ask you... If *no one* from North America
|had ever been to some particular continent (e.g. Australia), wouldn't that
|*seem* just a bit curious?
|
|I think that answer is yes.
|
|Likewise, the fact that no proposal from any ``outsider'' has ever been
|accepted by the comittee seems to me to be just a bit curious.
|
|Is this purely a matter of chance?  You be the judge.

Perhaps someone who gets the mailings could compile a list of who has
had proposals suggested, and how many proposals they have had accepted?
Then readers here could 'judge' for themselves the situation.  Since the
votes are suppose to be published in each meetings minutes it should
be easy to compile such a list, no?

In article <CqF5HL.GD0@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <KANZE.94May24193953@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>|But this doesn't mean that non-members cannot contribute.  Some do,
>|even greatly.  And I think that most responsible committee members
>|would be interested in hearing what others not on the committee think.
>
>Not in my experience.  IMHO the committee members are more interested
>in running this as a private club.  Private notes groups being
>one simple example.
>

 Well, I'm not just happy to talk to non-members,
I actually want and need their input. So .. here
is one of my papers for comment. ARM readers note that
9.5 in the ARM is 9.6 in the pre-San Diego WP, the paper below
refers to the WP not the ARM.

 The effect of the changes below is that a union
is a class (and thus may have virtual functions, be a base,
etc). As ought to be typical, a simplification increases
functionality rather than decreasing it: the proposal
is considered an extension. Had an extra restriction
been proposed, such as disallowing references in unions
(that WAS proposed at San Diego and then withdrawn),
it would have been viewed as a core issue.

---------------------------------------------------------------------
            ISO:       WG21/N0xxx
            ANSI:      94-xxxx
            Author:    John Max Skaller
            Date:      May 1994
            Reply to:  maxtal@suphys.physics.su.oz.au


"ENHANCED UNIONS"
-----------------

1) This paper suggests that the ARM, 9.5 Unions,
and the pre-San Diego WP, 9.6/1 [class.union] Unions, which say,
and I quote:

  "A union may be thought of as a structure whose member objects
  all begin at offset zero and whose size is sufficient to
  contain any of its member objects."

should be interpreted literally as the defining property of
a union.

PROPOSAL 1.
-----------

The whole of 9.6/1 is replaced by:

  "A union is a struct whose non-static members
  all begin at offset zero such that the sizeof
  the struct is not less than the sizeof any of
  these members; a union:

        union U {
         // other than non-static data members
         // non-static data members
        }

  is equivalent to

        struct U {
            // other than non-static data members
            union {
                // non-static data members
            };
        }
  which defines unions in terms of anonymous unions."


This substitution removes all the restrictions on unions
given in sentences after the first one of [class.union]/1.
The editorial box 48 (pre-San Diego) should be removed.

-------------------------------------------------------------------------

2) We proceed to clarify the rules for anonymous unions.
Rules [class.union]/2, 4 and 5 remain intact.

PROPOSAL 2
----------

Add to [class.union]/3 the clause:

  "An anonymous union may not have static members."


Add:

[class.union]/6 User constructors.
----------------------------------

    A user written constructor of a class containing an anonymous union
    shall not explicitly specify a mem-initialiser for more
    than one non-static data member of that anonymous union;

    no member of an anonymous union shall be initialised
    unless a mem-initialiser is explicitly written.

    For example:

      union U {
        T1 t1;
        T2 t2;
        U(T1 const& p1) : t1(p1) {}
        U(T2 const& p2) : t1(p2) {}
        U(U const& pu) : t1(pu.t1), t2(pu.t2) {} // error
      };

[class.union]/7 Generated destructor.
-------------------------------------

    A compiler generated destructor of a class containing
    an anonymous union shall not destroy any member of that
    anonymous union; user written destructors do not implicitly
    destroy any member of an anonymous union.


[class.union]/8 Generated copy constructor
  and copy assignment operator.
------------------------------------------

    A compiler generated copy constructor or copy assignment of a class
    containing an anonymous union shall
    perform a bitwise copy of the non-static storage extent of the
    anonymous union.

    If any of the members of the anonymous union
    is not bitwise copyable[ref], the compiler shall not generate
    a copy constructor or copy assignment operator.

[class.union]/9 Generated default constructor.
----------------------------------------------

    A generated default constructor of a class containing
    an anonymous union shall not initialise any members
    of the anonymous union.

Incorporate the following somewhere.
------------------------------------

    Definition: Bitwise copyable type
    ---------------------------------

    Each of an enum type, pointer to member, pointer, bool type,
    or arithmetic type is bitwise copyable(assignable), references
    are not bitwise copyable.

    A struct is bitwise copyable(assignable) if,
    and only if, each non-static data member is bitwise copyable(assignable),
    and provided the user does not supply a copy constructor
    (copy assignment operator).

    An anonymous union is bitwise copyable if the corresponding
    struct is.

    Specification: Copying bitwise copyable types
    ----------------------------------------------

    If a copy constructor (copy assignment operator) is generated
    by the compiler for a bitwise copyable type T,then the
    copy constructor (assignment operator) shall be functionally
    equivalent to a memcpy() of sizeof(T) bytes.


    Specification: Copying bitwise anonymous unions
    ----------------------------------------------
    If a copy constructor (copy assignment operator) is generated
    by the compiler for a bitwise copyable anonymous union,
    then the  copy constructor (assignment operator) shall be functionally
    equivalent to a memcpy() of sizeof the unnamed object.

--------------------------------------------------------------------------

RATIONALE: Problem and Resolution summary
-----------------------------------------

P1) Unions have special rules which introduce complexity
    to the C++ language and the Working Paper.

R1) Unions are classes defined in terms of anonymous unions,
    the complexity is delegated to anonymous unions.

P2) Unions have restrictions on declarations which
    restrict programmers.

R2) All restrictions are removed by treating unions as classes.

P3) In particular, C++ has no safe discriminated unions,
    and the restrictions on ordinary unions make idiomatic
    emulation of discriminated unions quite difficult.

R3) The restrictions are lifted and a sample idiom
    for a discriminated union given below as an example.

P4) Its not clear even for ordinary unions if user written
    constructors may initialise more than one non-static
    data member with explicit mem-initialisers.

R4) Delegated to anonymous unions.

P5) Its not clear for anonymous unions in structs if user written
    constructors may initialise more than one non-static
    data "member" with explicit mem-initialisers.

R5) Precise rules are given.

P6) It is not clear if unions may contain references.

R6) They may just as a class may, so too may an anonymous union.


---------------------------------------------------------------------------
Comparison with classes
-----------------------

                                CLASSES       ENHANCED UNIONS   ARM UNION
-------------------------------------------------------------------------
User constructor:
  Mem-initialiser ..
  Not written                   Default init  No init           No init

  Explictly written             At most one   At most one       Not specified
                                per member    member

Generated non-copy constructor:
  Default init                  Yes           No                No

Generated copy constructor:     Memberwise    Bitwise or error  Bitwise**

Generated copy assignment:      Memberwise    Bitwise or error  Bitwise**


Generated destructor:
  Destroy member automatically  Yes           No                No**

Brace initialise:               If aggegate   First member      First member
                                              if all members    (all members
                                              are aggregates    must be
                                                                aggregates)


Allow constructible member:     Yes           Yes               No

Can have bases, virtuals        Yes           Yes               No

Can be base                     Yes           Yes               No


** The requirements for ARM and Enhanced unions are the same,
the difference is that ARM unions diagnose errors at the
point of declaration even if no member function need be generated;
whereas enhanced unions defer error diagnoses until the point of use.


------------------------------------------------------------------------

EXAMPLE: Safe disriminated union idiom
--------------------------------------

The following code provides a "safe" disciminated union
of two types A and B. It permits an "empty" union.
Invalid accesses are trapped at run time.

    // tag wrapper class
    struct abtag {
      enum abcode {empty, A_t, B_t} tag;
      abtag(abcode x=empty) : tag(x) {}
    };

    union AB : private abtag {
    private:
      A a;
      B b;

    public:

      // default empty union
      AB() : abtag(empty), b(bb) {}

      // individual type constructors
      AB(A const& aa) : abtag(A_t), a(aa) {}
      AB(B const& bb) : abtag(B_t), b(bb) {}

      // copy constructor
      AB(AB const& ab) : abtag(ab.tag)
      {
        switch(tag)
        {
          case A_t: new(&a) A(ab.a); break;
          case B_t: new(&b) B(ab.b); break;
        }
      }

      // real destructor code
      void destroy() // empty the union
      {
        switch(tag)
        {
          case A_t: a.~A(); break;
          case B_t: b.~B(); break;
        }
        tag=empty;
      }

      // destructor
      ~AB(){ destroy(); }

      // copy assignment
      void operator=(AB const& ab)
      {
        if(this != &ab)
        {
           destroy();
           new(this) AB(ab);
        }
      }

      // allow user to get the typecode
      abcode getType()const { return tag; }

      // provided checked references access
      A& refA() { if(tag!=A_t) throw ("wrong type"); return a; }
      B& refB() { if(tag!=B_t) throw ("wrong type"); return b; }

      A const& refA()const { if(tag!=A_t) throw ("wrong type"); return a; }
      B const& refB()const { if(tag!=B_t) throw ("wrong type"); return b; }

      // provide checked pointer access: return 0 for wrong type
      A * ptrA(){ return tag==A_t ? &a : 0; }
      B * ptrB(){ return tag==B_t ? &b : 0; }

      A const* ptrA()const { return tag==A_t ? &a : 0; }
      B const* ptrB()const { return tag==B_t ? &b : 0; }

    };



--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <rfgCq3DGH.2ys@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> So lemme see if I understand what you are saying James.  Are you saying
|> that in the 4+ years that the committee has been in existance, a grand
|> total of ZERO proposals from non-members have been accepted and approved
|> by the standardization committee?

Don't put words in my mouth.  I have no statistics on which of the
accepted proposals were from members, and which weren't.

Obviously, a member is better placed to write an acceptable proposal.
He is aware of the discussions going on, proposals already refused,
etc.  He is also aware of the points the committee will want answered,
and will have prepared answers to these in his proposal.  For this
reason, I suggested that if a non-member wants to make a proposal, it
would be a good idea if he at least discussed the idea with a member
before hand.  There is no point in his wasting his time if the same
proposal has just been voted down.

But this doesn't mean that non-members cannot contribute.  Some do,
even greatly.  And I think that most responsible committee members
would be interested in hearing what others not on the committee think.
(Just remember that most of us also have other jobs; try and keep your
first communications short and to the point.)
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

|> Therefore, for a proposal by a non-member to be considered, some member has
|> to be willing to take responsibility for moving it and arguing for it.
|> It should not be surprising that this doesn't happen very often.

I suspect that it happens more than we think, but in a different form.

Formally, I (a member) have proposed a modification in the
interpretation of NULL.  But pratically, all of the ideas in the
proposal come from Ben-Kiki Oren and Fergus Henderson, neither of whom
are members.  So in a very real sense, they are the proposers, even if
it is my name on the paper.

I know that I am not the only member who discusses issues with
non-members; their comments do affect our interpretation and can lead
to proposals.  And of course, although it is an exception, some
non-members end up doing more work than most members.
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.94May24193953@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|But this doesn't mean that non-members cannot contribute.  Some do,
|even greatly.  And I think that most responsible committee members
|would be interested in hearing what others not on the committee think.

Not in my experience.  IMHO the committee members are more interested
in running this as a private club.  Private notes groups being
one simple example.

In article <ROBERT.94May17015337@mirage.visix.com>,
Robert Mollitor <robert@visix.com> wrote:
>
>This reminds me of an idea that I had thought of trying to propose at
>one time (or trying to get someone else to propose, as I have no standing),
>but the combinatorial complexity scared me away.
>

 There are no "standing" requirements for proposals. All proposals, from
whatever source, are read and considered.
 -- Pete

In article <CpyI7E.K6n@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>In article <ROBERT.94May17015337@mirage.visix.com>,
>Robert Mollitor <robert@visix.com> wrote:
>>
>>This reminds me of an idea that I had thought of trying to propose at
>>one time (or trying to get someone else to propose, as I have no standing),
>>but the combinatorial complexity scared me away.
>>
>
> There are no "standing" requirements for proposals. All proposals, from
>whatever source, are read and considered.

Just curious...

Pete, could you list for us the complete set of proposals from NON-COMITTEE
MEMBERS which have been accepted by the committee?

If the list is too long, perhaps you could put it up for FTP somewhere.

:-)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <rfgCq1Mv3.BB0@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> In article <CpyI7E.K6n@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
|> >In article <ROBERT.94May17015337@mirage.visix.com>,
|> >Robert Mollitor <robert@visix.com> wrote:

|> >>This reminds me of an idea that I had thought of trying to propose at
|> >>one time (or trying to get someone else to propose, as I have no standing),
|> >>but the combinatorial complexity scared me away.

|> > There are no "standing" requirements for proposals. All proposals, from
|> >whatever source, are read and considered.

|> Just curious...

|> Pete, could you list for us the complete set of proposals from NON-COMITTEE
|> MEMBERS which have been accepted by the committee?

He didn't say accepted, just read and considered:-).

More seriously, a lot of proposals by members don't get accepted
either.  And I expect that at least one very important proposal by a
non-member will be accepted.  It is probably normal that a higher
percentage of member proposals will be accepted.  After all, a member
has a feel of the general committee orientation, and will not propose
something they know has no chance.  They also know which proposals
have already been discussed and rejected.

Despite some discussion in the standards committee concerning how open
they should be, constructive contributions from non-members have and
will be accepted.  Much of the significant work behind the proposal to
resolve the order of initialization comes from a non-member.  (Of
course, it is the committee itself which decides what is or isn't
"constructive."  But how else could you do it.)

If you think you have a constructive proposal, there was a paper on
how to write a proposal floating around on the net about a year ago.
I would also suggest getting in touch with a committee member, and
reviewing it with him, if only to know whether you are not just
duplicating work already done.
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <rfgCq1Mv3.BB0@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>>
>> There are no "standing" requirements for proposals. All proposals, from
>>whatever source, are read and considered.
>
>Just curious...
>
>Pete, could you list for us the complete set of proposals from NON-COMITTEE
>MEMBERS which have been accepted by the committee?
>
>If the list is too long, perhaps you could put it up for FTP somewhere.
>

 I don't pay attention to who made any particular proposal, so I do not
have such a list. Despite the insinuation in the posting, what I said is
true: there are no "standing" requirements for proposals. If you want to take
the time to put together a carefully written proposal that solves a significant
language problem go ahead and do so. It will be considered.
 And before you start, I'm not the least bit interested in flames about
how any particular proposal may have been treated.
 -- Pete

In article <MCMURRY.94May16151605@demeter.thphys.ox.ac.uk> mcmurry@demeter.thphys.ox.ac.uk (Andrew McMurry) writes:
>
>As I understand it the current definition of const is that a const
>object will remain constant (barring mutable fields and explicit
>casting away const) from when the constructor returns until the
>destructor is called.

 What current definition?

 IMHO 'const' is not an attribute of objects. Its a property
of expressions that are used to access the objects.

>The problem comes with having a const object being non-const until the
>return from the constructor.

 No. The problem comes because during construction,
the constructor has silently cast a void* to a T*, so you can
construct the fields.
>
>The existance of this problem means that an important optimisation that
>const should make possible, cannot be used.

 The hole can be closed but it would break code and it
is unknown if all constructors can be written without bodies.
(Thats the requirement).

 Can you show a constructor which REQUIRES a body?
If there are none, the hole can be closed.

 Note: even if it isnt, whether changing a "const"
object is allowed or not is a separate issue. If it is not
allowed, then in fact the optimisation may be performed.

 I think that in fact changing a const object is
a nonquestion. But I think that memory bytes may be marked
"WORM" (write once then read only) and a program violating
this is undefined.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <KANZE.94May19161811@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <rfgCq1Mv3.BB0@netcom.com> rfg@netcom.com (Ronald F.
>Guilmette) writes:
>
>|> In article <CpyI7E.K6n@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>|> >In article <ROBERT.94May17015337@mirage.visix.com>,
>|> >Robert Mollitor <robert@visix.com> wrote:
>
>|> >>This reminds me of an idea that I had thought of trying to propose at
>|> >>one time (or trying to get someone else to propose, as I have no standing),
>|> >>but the combinatorial complexity scared me away.
>
>|> > There are no "standing" requirements for proposals. All proposals, from
>|> >whatever source, are read and considered.
>
>|> Just curious...
>
>|> Pete, could you list for us the complete set of proposals from NON-COMITTEE
>|> MEMBERS which have been accepted by the committee?
>
>He didn't say accepted, just read and considered:-).
>
>More seriously, a lot of proposals by members don't get accepted
>either.  And I expect that at least one very important proposal by a
>non-member will be accepted...

So lemme see if I understand what you are saying James.  Are you saying
that in the 4+ years that the committee has been in existance, a grand
total of ZERO proposals from non-members have been accepted and approved
by the standardization committee?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <Cq27Kt.7DJ@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>In article <rfgCq1Mv3.BB0@netcom.com>,
>Ronald F. Guilmette <rfg@netcom.com> wrote:
>>>
>>> There are no "standing" requirements for proposals. All proposals, from
>>>whatever source, are read and considered.
>>
>>Just curious...
>>
>>Pete, could you list for us the complete set of proposals from NON-COMITTEE
>>MEMBERS which have been accepted by the committee?
>>
>>If the list is too long, perhaps you could put it up for FTP somewhere.
>>
>
> I don't pay attention to who made any particular proposal, so I do not
>have such a list. Despite the insinuation in the posting, what I said is
>true: there are no "standing" requirements for proposals. If you want to take
>the time to put together a carefully written proposal that solves a significant
>language problem go ahead and do so. It will be considered.
> And before you start, I'm not the least bit interested in flames about
>how any particular proposal may have been treated.
> -- Pete

I have no flames about any particular proposals.  (I never spent the time
to write any myself, and perhaps I saved myself a lot of time that way.)

What *does* concern me is a certain *appearance* of a `private club', where
`outsiders' and their ideas are uniformly shunned.

(I stress the word ``appearance'', because that may be all there is to it.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <rfgCq3Dp3.3A2@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>
>I have no flames about any particular proposals.  (I never spent the time
>to write any myself, and perhaps I saved myself a lot of time that way.)
>
>What *does* concern me is a certain *appearance* of a `private club', where
>`outsiders' and their ideas are uniformly shunned.
>
>(I stress the word ``appearance'', because that may be all there is to it.)
>

 Once again, accusations without facts. Tell me, have you stopped
beating your wife?
 -- Pete

In article <rfgCq3Dp3.3A2@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
...
>What *does* concern me is a certain *appearance* of a `private club', where
>`outsiders' and their ideas are uniformly shunned.
>
>(I stress the word ``appearance'', because that may be all there is to it.)

I think it is really a matter of appearance.  The committee tends to be
equally harsh with all proposals.  Committee members' proposals are more
likely to be accepted simply because committee members are more likely
to formally submit proposals (and to know how to go about it.)  When I
communicate with committee members, they don't go madly rushing to their
rolls to see if I'm a member.  They look at what I'm saying, and if it doesn't
seem stupid to them (or if it seems dangerously so), they respond.  It's
actually possible to be quite active in the committee without formally
joining.

- Brad
------------------------------------------------------------------------
+ Brad Daniels           | This is a test of the .signature broadcast  +
+ Biles and Associates   | system.  Had this been an actual .signature +
+ My views, not B&A's    | this space would contain a pithy quote.     +
------------------------------------------------------------------------

In article <Cq40rs.B6F@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>In article <rfgCq3Dp3.3A2@netcom.com>,
>Ronald F. Guilmette <rfg@netcom.com> wrote:
>>
>>I have no flames about any particular proposals.  (I never spent the time
>>to write any myself, and perhaps I saved myself a lot of time that way.)
>>
>>What *does* concern me is a certain *appearance* of a `private club', where
>>`outsiders' and their ideas are uniformly shunned.
>>
>>(I stress the word ``appearance'', because that may be all there is to it.)
>>
>
> Once again, accusations without facts. Tell me, have you stopped
>beating your wife?

FACT:  Many proposals from committee members have been accepted and approved.

FACT:  ZERO proposals from non-committee members have been accepted and
       approved.

Pete, if you feel I've gotten the facts wrong, please *do* correct me.  I'd
like nothing better than to be proven wrong in this case.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <rfgCq3Dp3.3A2@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> What *does* concern me is a certain *appearance* of a `private club', where
> `outsiders' and their ideas are uniformly shunned.

It's not private at all: anyone can join who is willing to pay the membership
fee (presently $600 a year, I think).  So it's more like a public club.

It is true, however, that

 1. All committee business is conducted through the usual parliamentary
    mechanism of making motions and then discussing and voting on them.

 2. Only voting members are permitted to make motions.

 3. Not all members are voting members.  Bjarne and I are not, for example.

Therefore, for a proposal by a non-member to be considered, some member has
to be willing to take responsibility for moving it and arguing for it.
It should not be surprising that this doesn't happen very often.

If you don't like the rules, that's tough the committee didn't make them
and is powerless to change them.
--
    --Andrew Koenig
      ark@research.att.com

In article <rfgCq59Mv.Mzw@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>>
>> Once again, accusations without facts. Tell me, have you stopped
>>beating your wife?
>
>FACT:  Many proposals from committee members have been accepted and approved.
>
>FACT:  ZERO proposals from non-committee members have been accepted and
>       approved.
>
>Pete, if you feel I've gotten the facts wrong, please *do* correct me.  I'd
>like nothing better than to be proven wrong in this case.
>

 No, those statements are probably correct. Now that there's actually
a statement of fact to deal with, isn't it immediately clear that this has
nothing whatsoever to do with whether proposals from non-members are
considered? I've never been to Australia. That does not mean that I'm not
allowed to go there.
 -- Pete

In article <Cq5v7w.EG5@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:

>I've never been to Australia. That does not mean that I'm not
>allowed to go there.

 I'm sure you'd be welcome anytime Pete.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <Cq5xD0.M5A@ucc.su.oz.au>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>In article <Cq5v7w.EG5@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>
>>I've never been to Australia. That does not mean that I'm not
>>allowed to go there.
>
> I'm sure you'd be welcome anytime Pete.
>

 And the same applies to proposals from non-members. Q.E.D.
 -- Pete

With his usual degree of accuracy rfg@netcom.com (Ronald F. Guilmette) writes

 > FACT:  ZERO proposals from non-committee members have been accepted and
 >      approved.

The relaxation of the rule for matching return types for overriding functions
was proposed by Alan Snyder. The proposal for mutable was, in the form of ~const,
proposed by Thomas Ngo. The first written proposal came from someone from
Microsoft. Forward declaration of nested classes was proposed by Tony hansen.

In fact, almost all extensions were prompted by suggestions and proposals
from outside the committee.

 - Bjarne

As I understand it the current definition of const is that a const
object will remain constant (barring mutable fields and explicit
casting away const) from when the constructor returns until the
destructor is called. For example

  class MyClass {

  protected:
    int field;

  public:
    MyClass(int i) { field=i; ... }
  };

  const MyClass obj1(34);

The value of obj1.field should remain 34, until obj1 is destroyed.

The problem comes with having a const object being non-const until the
return from the constructor.
This system means that you only need 1 constructor, rather than having
a special one for const objects, and anyway you need to change the
object's fields to assign to set them up in the first place.

Unfortunately this also leads to problems. Consider the following class.

  class ProblemClass: public MyClass {

    static List<ProblemClass *> list;

  public:
    ProblemClass(int i) : MyClass(i) { list.add(this); }
    ~ProblemClass() { list.remove(this); }

    static void addToAll(int);
  };

  void ProblemClass::addToAll(int j)
  {
    for (Iterator it(list); it; it++) // For every list element
      it->field += j;
  }

Now declare an object

  const ProblemClass obj2(34);

We would expect obj2.field to keep the value 34 until obj2 is
destroyed. This will not be the case if ProblemClass::addToAll()
is ever called.

obj2.field has not been declared "mutable" and its const'ness has not
been explicitly cast away, yet its value has changed!

The class definitions are not purpously made up in order to break the
const'ness. I have defined useful classes with the 2 important
features of ProblemClass:
  - A static list of all instances of the class,
  - A function that changes every thing on that list.
I admit that I have not yet needed to make an instance of such a class
const, but I am worried that it is so easy to break the const
guarantee. Writing a compiler that can detect such cases and not put
them in ROM, and not optimise them to constants in the assembly code
does not seem simple to me. A compiler should be able to compile
  a += obj1.field
to
  ADD Ra, Ra, #34  (add 34 to Ra and put the result in Ra)
assuming that the value of a is held in register Ra.

If the compiler did the same to
  a += obj2.field
then the code would not have the same affect as it would without the
optimisation.

The existance of this problem means that an important optimisation that
const should make possible, cannot be used.

 Andrew

As I understand it the current definition of const is that a const
object will remain constant (barring mutable fields and explicit
casting away const) from when the constructor returns until the
destructor is called. For example

  class MyClass {

  protected:
    int field;

  public:
    MyClass(int i) { field=i; ... }
  };

  const MyClass obj1(34);

The value of obj1.field should remain 34, until obj1 is destroyed.

The problem comes with having a const object being non-const until the
return from the constructor.
This system means that you only need 1 constructor, rather than having
a special one for const objects, and anyway you need to change the
object's fields to assign to set them up in the first place.

Unfortunately this also leads to problems. Consider the following class.

  class ProblemClass: public MyClass {

    static List<ProblemClass *> list;

  public:
    ProblemClass(int i) : MyClass(i) { list.add(this); }
    ~ProblemClass() { list.remove(this); }

    static void addToAll(int);
  };

  void ProblemClass::addToAll(int j)
  {
    for (Iterator it(list); it; it++) // For every list element
      it->field += j;
  }

Now declare an object

  const ProblemClass obj2(34);

We would expect obj2.field to keep the value 34 until obj2 is
destroyed. This will not be the case if ProblemClass::addToAll()
is ever called.

obj2.field has not been declared "mutable" and its const'ness has not
been explicitly cast away, yet its value has changed!

The class definitions are not purpously made up in order to break the
const'ness. I have defined useful classes with the 2 important
features of ProblemClass:
  - A static list of all instances of the class,
  - A function that changes every thing on that list.
I admit that I have not yet needed to make an instance of such a class
const, but I am worried that it is so easy to break the const
guarantee. Writing a compiler that can detect such cases and not put
them in ROM, and not optimise them to constants in the assembly code
does not seem simple to me. A compiler should be able to compile
  a += obj1.field
to
  ADD Ra, Ra, #34  (add 34 to Ra and put the result in Ra)
assuming that the value of a is held in register Ra.

If the compiler did the same to
  a += obj2.field
then the code would not have the same affect as it would without the
optimisation.

The existance of this problem means that an important optimisation that
const should make possible, cannot be used.

 Andrew

In article <MCMURRY.94May16152049@demeter.thphys.ox.ac.uk> mcmurry@demeter.thphys.ox.ac.uk (Andrew McMurry) writes:


   Unfortunately this also leads to problems. Consider the following class.

     class ProblemClass: public MyClass {

       static List<ProblemClass *> list;

     public:
       ProblemClass(int i) : MyClass(i) { list.add(this); }
       ~ProblemClass() { list.remove(this); }

       static void addToAll(int);
     };

     void ProblemClass::addToAll(int j)
     {
       for (Iterator it(list); it; it++) // For every list element
         it->field += j;
     }

   Now declare an object

     const ProblemClass obj2(34);

   We would expect obj2.field to keep the value 34 until obj2 is
   destroyed. This will not be the case if ProblemClass::addToAll()
   is ever called.

   obj2.field has not been declared "mutable" and its const'ness has not
   been explicitly cast away, yet its value has changed!

The committee was aware of this gap in the const safety system when
they accepted the mutable proposal.  We concluded that saving "this"
while in a constructor and later using the saved pointer to modify the
object resulted in undefined behavior, just as if you had explicitly
cast away const and tried to modify the object through the resulting
pointer.

Its an unfortunate hole in the "const safety system", but there didn't
seem to be any reasonable ways to plug it.

  -- Jerry Schwarz(jss@lucid.com)

In article <JSS.94May16171706@summit.lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <MCMURRY.94May16152049@demeter.thphys.ox.ac.uk> mcmurry@demeter.thphys.ox.ac.uk (Andrew McMurry) writes:
>
>
>     Unfortunately this also leads to problems. Consider the following class.
>
> class ProblemClass: public MyClass {
>
>   static List<ProblemClass *> list;
>
> public:
>   ProblemClass(int i) : MyClass(i) { list.add(this); }
>   ~ProblemClass() { list.remove(this); }
>
>   static void addToAll(int);
> };
>
> void ProblemClass::addToAll(int j)
> {
>   for (Iterator it(list); it; it++) // For every list element
>     it->field += j;
> }
>
>     Now declare an object
>
> const ProblemClass obj2(34);
>
>     We would expect obj2.field to keep the value 34 until obj2 is
>     destroyed. This will not be the case if ProblemClass::addToAll()
>     is ever called.
>
>     obj2.field has not been declared "mutable" and its const'ness has not
>     been explicitly cast away, yet its value has changed!
>
>  The committee was aware of this gap in the const safety system when
>  they accepted the mutable proposal.  We concluded that saving "this"
>  while in a constructor and later using the saved pointer to modify the
>  object resulted in undefined behavior, just as if you had explicitly
>  cast away const and tried to modify the object through the resulting
>  pointer.
>
>  Its an unfortunate hole in the "const safety system", but there didn't
>  seem to be any reasonable ways to plug it.


This reminds me of an idea that I had thought of trying to propose at
one time (or trying to get someone else to propose, as I have no standing),
but the combinatorial complexity scared me away.

Basically, you could qualify the signature of constructors (and maybe
destructors) so that different constructor bodies get called depending
on the the context of object definition.

So instead of just

   class A
     {
       A();
       ~A();
     }

you could have something like

   class B
     {
       B();
       B() const;
       ~B();

       int isConst;
     }

   B::B()
   {
     isConst = FALSE;
   }

   B::B() const
   {
     isConst = TRUE;
   }


My concern, however, was mainly for a "new" qualifier.

   C::C()
   {
     wasNewed = FALSE;
   }

   C::C() new
   {
     wasNewed = TRUE;
   }


It bugs me to no end that an object cannot (easily) know the simple fact
of whether it was created on the stack (or as the part of some other
object) or on the heap.  The compiler certainly knows it.


For those who care, here is my "complete" list of constructor qualifiers
(in ascending degree of craziness):

   my_class() new; // called, basically, when the my_class::operator new
                        //   function is used (assuming the new is not
                        //   explicitly scoped)

   my_class() const;    // called when an instance is declared const or
                        //   is a non-mutable member of a const object

   my_class() volatile; // likewise

   my_class() [];       // called when the instance is part of an array

   my_class() auto;     // called when the instance is an automatic variable

   my_class() static;   // called when the instance is a global

   my_class() class;    // called when the instance is a subobject (base
                        //   or member)

   my_class() class :;  // (crazy syntax) called when the instance is a base

   my_class() class .;  // (crazy syntax) called when the instance is a member

   my_class() ::new;    // called when the global operator new was used

   my_class() [size_t index]; // called when the instance is part of an array
                              //   (like above), but the constructor has
                              //   access to an 'extra' argument which is
                              //   the position inside the array

   my_class() new(size_t size);
   my_class() new(size_t size, void *mem);
   my_class() new(size_t size, /* random args */);
                        // these allow the constructor to see the specific
                        //   arguments used in the new invocation, with
                        //   and without placement syntax.


Obviously, I went nuts with the idea.  It would be way too hard to
implement a full complement of constructors.  I could see it working for
a class, but once you inherit from it, you would lose all of the sublety.
It would work better if you could have some type of constructor template
that recorded all of necessary information for that tree of classes
and then called a single common initialization function.


Oh well.  Just idle speculation.



robt

--
Robert Mollitor            robert@visix.com
Visix Software Inc.     ...!uupsi!visix!robert
--
--
Robert Mollitor            robert@visix.com
Visix Software Inc.     ...!uupsi!visix!robert