In article <332C1AD0.B01@vandevoorde.com> daveed@vandevoorde.com writes:
>Steve Clamage wrote:
>[...]
>> All features in the draft have been implemented by somebody.
>
>Who has implemented the separate compilation model for templates?
>Template template parameters?
>Function-try-blocks?
>Extended Koenig lookup?
>

The fact that a given feature can be implemented as specified is certainly
a minimum requirement for anything in a standard, but it is not sufficient
to demonstrate that the feature is correctly specified.  That can only
be determined through use of the feature.

There have been many cases in which features were specified and implemented
only to find out that they didn't work as intended.  In some cases the
errors have been severe.  One particularly severe error was the original
set of rules for name lookup in template instantiations within namespaces.
It turned out that the original rules did not work correctly for multi-level
instantiations (when the instantiation of one template leads to the
instantiation of another template).

The separate compilation model, extended Koenig lookup, and the elimination
of friend injection are all features that have complex interactions with
other areas of the language, such as name lookup, and that are certain
to have unexpected consequences.

John Spicer
Edison Design Group

--
John Spicer
Edison Design Group
jhs@edg.com
---
[ 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
]

Steve Clamage wrote:
[...]
> All features in the draft have been implemented by somebody.

Who has implemented the separate compilation model for templates?
Template template parameters?
Function-try-blocks?
Extended Koenig lookup?

 Daveed
---
[ 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                             ]

Regrettably, the public comment period is over and we're still finding
bugs in the draft.  The following looks like one of these.

The member traits::eos is used by the following sections of the
public December 1996 draft:

    [lib.string.access]
    [lib.string.ops]
    [lib.istream::extractors]
    [lib.istream.unformatted]

However, traits::eos is not defined by the draft.  In particular,
section [lib.char.traits.specializations.char] makes no mention of it.

Are the referencing sections supposed to fail at compile time when the user
uses plain char?

General point and rant: The draft should not be ratified until implementors
have at least had a chance to *attempt* implementation of the features.
I'm not asking for a *complete* implementation, but enough such that
the interactions of the features can be thought out.  Stroustrup warned
about building the Vasa, and I fear the excess cannon have been ordered
one at a time.

The rumor that companies have in-house versions of C++ that implement all
draft-standard features is clearly untrue, as the draft is self-contradictory.
In fact, some of the errors in the draft would suggest that the language has
become so complicated that not even the designers of the library understand it!
E.g., [lib.vector.bool] specifies a default argument for Allocator in the
partial specialization vector<bool,Allocator>.  But [temp.class.spec.match],
paragraph 6, specifically says:

 The template parameter list of a specialization shall not contain
 default template argument values.

This is not the only self-contradictory point.  Some of the others are
so complicated that only hardened language lawyers can spot them.
E.g., Clause 27 specifies inherently ambiguous definitions of operator<< ,
according to our language lawyers.  If the designer gods have built a
language so complicated that they don't understand it, how are mere mortals
supposed to use it?

Arch D. Robison       Kuck & Associates Inc.
robison@kai.com       1906 Fox Drive
217-356-2288        Champaign IL 61820
Lead Developer for KAI C++     http://www.kai.com/C_plus_plus/index.html
---
[ 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                             ]

Arch Robison <robison@kai.com> writes:

>Regrettably, the public comment period is over and we're still finding
>bugs in the draft.  The following looks like one of these.

The ANSI public-comment comment is not quite over. It extends until
March 18. That does not mean the end of consideration of errors
in the draft, however. The ISO comment period has about another
month to run. Committee members will continue to look for and fix
problems, and the final draft will not be submitted until after the
meeting of November 1997.

The significance of the ANSI public-comment period is that all
reports received through channels must be logged and must receive
a formal response. The committee members are always glad to receive
at any time reports of problems via informal channels (such as
comp.std.c++), and will attempt to correct all problems found.

>The member traits::eos is used by the following sections of the
>public December 1996 draft:

>    [lib.string.access]
>    [lib.string.ops]
>    [lib.istream::extractors]
>    [lib.istream.unformatted]

>However, traits::eos is not defined by the draft.  In particular,
>section [lib.char.traits.specializations.char] makes no mention of it.

That problem has been known for a while and will be fixed.

>General point and rant: The draft should not be ratified until implementors
>have at least had a chance to *attempt* implementation of the features.
>I'm not asking for a *complete* implementation, but enough such that
>the interactions of the features can be thought out. ...

>The rumor that companies have in-house versions of C++ that implement all
>draft-standard features is clearly untrue, as the draft is self-contradictory.
No 700-page document is free from error, and the standard when published
will still contain errors. For example, errors continue to be found in
the C standard, which is much smaller and which was published in 1989.

All features in the draft have been implemented by somebody. Usually
attempts at implementation find problems such as the above which
are brought to the attention of the committee and fixed.

The ISO "Defect Report" mechanism exists precisely to allow for
correction of errors discovered after publication of the standard.
The C standard (to continue the example) has been the subject of
Technical Corrigenda, and so will the C++ standard.
---
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                             ]