>>>>> "SW" == Steve Willer <willer@interlog.com> writes:
[...]
SW> Just out of curiosity: Are minutes of the committee meetings kept?
SW> An archive of proposals and responses? Any documentation other
SW> than the WP itself?

I think the answer to all of these questions is `yes'.

Specifically, there are minutes of the meetings of the full committee,
but not of the meetings of the committee subgroups (at the X3J16/WG21
meetings, much of the work is done in smaller groups that focus on a
fraction of the draft standard; e.g., there is a `C compatibility
subgroup'). I'm always quite amazed at how the secretary (Dan Saks)
of the committee manages to capture all the discussions and debates
that fly across the meeting room into the minutes.

Also, proposals are usually introduced through `papers' which are
archived and made available to committee members; some of these papers
are authored or co-authored by non-members as well. (I think public
comments are treated similarly.) These papers are often a good source
for an explanation of the motivation behind proposals and decisions.
Sometimes, these papers are used for the rebuttal or defense of
proposals.

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

clamage@taumet.eng.sun.com (Steve Clamage) wrote:

>Do you mean 'explicit' for general functions? What would it mean? A
>general function cannot be called implicitly anyway.

Conceivably, the keyword 'explicit' used like this:

    bool myfunc() explicit;

...could indicate to the compiler that the function designer absolutely doesn't
want that returned bool implicitly converted to something else. So, client code
like

    bool b = myfunc();

would be valid, but

    int  b = myfunc(); // yuck

...would not. Presumably, the same rules would apply to any return value of any
function, including member functions.

[I'm not trying to propose this change, or defend it, BTW -- just pointing out
how I would have interpreted it]

>As mentioned in the FAQ below, the book "The Design and Evolution of C++"
>explains the history of C++, covering the reasons for decisions that were
>made, and includes rejected ideas and the reasons they were rejected.

True, although it doesn't go over recent decisions (and there have been a lot
since DE was published).

Just out of curiosity: Are minutes of the committee meetings kept? An archive
of proposals and responses? Any documentation other than the WP itself?


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article VAA11305@blue.abm.si, "denis bider" <denis.bider@abm.si> writes:
>I've heard that introducing a "private:" access keyword to namespaces was rejected
>by the committee (twice, for that matter), but I see no reason why. It doesn't seem
>to me that voting "yes" would delay the standard a lot more than voting "no". It
>would be useful to be able to have things private inside a namespace. If, for
>example, class U is used internally both by classes A and B that are inside a
>namespace of their own, declaring U private to this namespace (and the nested ones)
>would be sensible.

As Stroustrup points out over and over, the most common complaint about
C++ is that it has too many features, making it too big and too complex
to be easily understood and used, and oh, by the way, I can't write
programs in C++ unless you add these two additional features.

For any one suggestion it's easy to say, "Sure, that's no problem," but
then you wind up with every feature anyone ever thought was a good
idea in any language. A feature is added to C++ if it can be shown
to solve a serious programming problem that affects a wide range of
programmers which can't easily be solved already.

Namespaces address the serious problem of name conflicts when combining
libraries, an unavoidable problem which had no other solution. Classes
already address the problem of access control. I have yet to see any
example of a problem which is more easily solved by adding access
control to namespaces than by using an already-existing mechanism.

In your example, make A, B, and U members of an enclosing class
(instead of an enclosing namespace).

>What about the "explicit:" keyword for
>functions (such as the proposed "string::operator bool() explicit", which seems
>reasonable to me)? This is said to have been considered and rejected, too. What is
>the reasoning behind this decision?

Do you mean 'explicit' for general functions? What would it mean? A
general function cannot be called implicitly anyway.

If you mean 'explicit' for type conversion functions (e.g. operator bool()),
there was insufficient support for the idea within the C++ Committee,
because no one presented strong case for it. If you want implicit
conversion to bool (for example), write an operator bool() for the
class. If you want to allow only explicit conversion to bool, write
a named function instead of an operator, such as "to_bool()".

If someone could show a compelling reason for allowing 'explicit' on
type conversion operators, I don't believe there would be a problem
in adopting it.

>[Wouldn't it be wonderful if there was an archive of committee's past decisions with
>a short and factual rationale for each decision made - I know it would sure make my
>postings a lot more scarce...]

As mentioned in the FAQ below, the book "The Design and Evolution of C++"
explains the history of C++, covering the reasons for decisions that were
made, and includes rejected ideas and the reasons they were rejected.

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]