Conference turris::tle_trips

215.0. "trip report for ANSI C++ meeting in Nashua" by TLE::WHITMAN () Wed Mar 19 1997 11:27

Trip Report for ANSI C++ Standards Meeting in Nashua, NH
March 10-14, 1997

1. Summary

I attended the ANSI/X3J16 and ISO/WG21 C++ standards meeting in
Nashua, NH from March 10 - March 14 1997.  Digital hosted the 
meeting at the Crowne Plaza Hotel.  I thought all the arrangements 
were really nice and that Randy Meyers did an excellent job with 
the preparations.  Approximately 50 people representing the USA, 
Canada, UK, Sweden, Germany, and Ireland attended.  As before 
attendees represented C++ compiler vendors, C++ library vendors 
and C++ users.

The objective of this meeting was to review the open language and
library issues as well as public comments and recommend which of these
should move to the list of comments used by the US TAG (Technical
Advisory Group) to develop an official U.S. position on CD-2.  Because
the Nashua meeting fell in the middle of CD-2 balloting (which started
in January and ends in June) no formal votes on specific issues or
non-editorial changes to the working draft could be made.  In my
opinion this made the tone of the Nashua meeting less contentious than
other meetings I have attended.  Whenever any discussion got too
heated we were reminded that our goal was not to find solutions, but
rather to identify a list of CD-2 comments for the U.S.  (Although a
goal for each working group was to identify a recommended solution on
each issue.)  I believe that the July meeting will be different in
that it does occur after CD-2 balloting and each U.S. comment will
need to be addressed.

At the conclusion of the meeting there were approximately 160
non-editorial issues for CD-2. (There were additional strictly
editorial issues).  There were approximately 70 library issues,
approximately 11 Core 1 (chapters 3 and 12) issues, approximately 7
Core 2 (Chapter 5) issues and approximately 70 Core 3 (templates and
exception handling) issues.

When the US TAG met to determine the US official position on CD-2 24
U.S voting members were present.  Although there was concern over the
number of issues the official vote on CD-2 was "yes, with comments".
This vote says that the U.S. believes that CD-2 should continue
progressing towards a Draft International Standard and that the
U.S. open CD-2 issues should be addressed.  21 members voted "yes,
with comments", and 3 (EDG, MetaWare, and someone from HP) voted "no,
with comments".

2. Standardization Schedule (still on track)

After the Nashua meeting the ANSI C++ standard is still on schedule.
The schedule is:
  
    7/96  Complete technical issues for CD-2
    8/96  Start public comment period
   11/96  Vote in CD-2
    1/97  Start of Final CD balloting
    3/97  Nashua Meeting,  US TAG voted "yes, with comments" on CD-2
    6/97  End of Final CD balloting
    7/97  UK Meeting, work on resolving CD-2 comments
   11/97  NJ Meeting
   12/97  Complete DIS Draft
    1/98  Start Final DIS Draft balloting
    2/98  End Final DIS Draft balloting
    3/98  France Meeting, Final DIS Draft successful ?
    7/98  Rochester NY Meeting
    8/98  Expect DIS complete, create IS copy
    9/98  IS publication (est.)
 

3. Technical Library Issues Addressed in Nashua

We addressed six major library issues.  The first two, relaxing rules
for void and default template arguments were discussed at a full
committee meeting.  The reason was to determine whether the best
solutions required core language changes or library work-arounds.  The
next two, STL allocator class cleanup and exception safety in the STL
were discussed among the full library working group since they
represent significant problems.  The last two, basic_string element
access and iterator lifetime were discussed within the library working
group dealing with clauses (17-21,23-26).  A brief summary of each
issue follows along with the recommended resolution posted in the CD-2
comments.

3.1 Library Issue 1: Relaxing rules for void

A year ago the committee added several adapter classes to allow member
functions to be used with STL algorithms.  Adapter classes basically
create a function object for a member function which allows them to be
passed to STL algorithms. One of the adapters is:

template <class S, class T>
class mem_fun_t  : public unary_function<T*,S>
{
  S (T::*pmf)();

  public:
    explicit mem_fun_t(S (T::*p)()) : pmf(p) { ; }
    S operator()(T* p) { return (p->*pmf)(); }
};

The problems occurs when the return type of the member function "mf"
is  void.  The current language rules do not allow a void function
return here.  So there are two solutions to the problem 1) relax the
language rules for void so that a void return expression is allowed or
2) add partial specializations for void to the library.  In general
the committee seemed favorable to relaxing the language rules for void
in this specific context.  A year ago a more comprehensive proposal to
relax the rules for void was rejected but this particular change was
viewed as OK.

3.2 Default arguments in templates

The language currently states that template default arguments are
checked when a template is instantiated.  This means that in the
following:

    template <class T>
    class C {
        C (int, const T& = T()) 
    }

any T must have a default constructor even if the default argument is
never used.  This poses a severe problem in the STL which relies
heavily on default template arguments.  Consider the following:

template <class T>
class C {
    public:
        C();
        C(int);
        C(int, const T&);
}

Using default arguments you can collapse the 2nd and 3rd constructors
into:

       C(int, const T& = T())

At the moment the library is actually broken in this regard.The proposed
resolutions are to 1) change the language rules to allow default
arguments to be instantiated such that a default constructor is not
required if the default argument is not used or 2) break up each STL
function relying on default template arguments into the correct set of
overloaded functions.  The language change here was fairly
controversial.  Many people felt the core change was to risky, many
felt that without it default template arguments were useless which was
too risky.

3.3 STL allocator class

Allocators are classes used to encapsulate information about the
memory model a program is using.  Allocators are used by STL
containers and algorithms to allocate and deallocate memory.  The
problem is that many details of Allocator behavior as well as
alternate pointer types were never specified in the Working Paper.
This led to ambiguity regarding what the Allocator typedefs
"reference" and "pointer" meant.  The issue here is to specify the
details of allocator and alternate pointer types.  Most of the work
was done by Matt Austern at SGI who works on developing additional 
library components for the STL.

The main idea was to develop a list of requirements on allocator
pointer types.  Some of the topics clarified what operators are
allowed on general pointers, what it means for a pointer to be a
random access iterator, describe null pointers, specify the conversion
rules between Allocator::pointer and Allocator::const_pointer,
between Allocator::pointer of one type and Allocator::pointer of 
another type, and between Allocator::pointer and built-in pointers.
Not all the details of this proposal were agreed upon but the 
general direction of the  proposal was.  Details will be worked
out for July.

3.4 exception safety in the STL  

The question here is what guarantees can we make on how library
containers behave when user code throws exceptions.  The idea is that
if library users know how much they can count on they will be able to
take advantage of the library more completely.  Up to this time, no
mention was made of exception safety in the Working Paper.

The proposal we discussed in the working group was submitted by 
Matt Austern (who did the work above).  He did not look at all library
containers but he gave a thorough analysis of vectors with the intent
of examining remaining containers before July.

Based on vector he concluded that the library can make the following 
guarantees:
    1. a vector can be destroyed after an exception from user code
    2. exceptions won't prevent properly constructed vector elements
       from being destroyed
    3. you will be able to call any vector member function after
       an exception
    4. a vector's destructor does not throw an exception.

If a user follows the following four restrictions on 
vector<T,Allocator>'s template parameters.

    1. T's destructor does not throw exceptions
    2. No operations on T can put it into a non-destructable state
    3. Allocator::deallocate may not throw an exception
    4. Objects of type Allocator::pointer, Allocator::const_pointer,
       Allocator::size_type, and Allocator::difference_type may 
       not throw exceptions.

A user would also need to guarantee that uninitialized_copy,
uninitialized_fill, and uninitialized_fill_n would be able to destroy
any objects that it had constructed if an exception were thrown.
These algorithms provide this guarantee if:

    1. the template arguments that are iterators or integral types can't 
       throw exceptions upon valid iterator operations
    2.  The value type's destructor can't throw exceptions.


The recommendation of the working group was to continue the
specifications for the remainder of the STL containers.  There was
some debate over whether we should just specify what a user needs to
do to get the guarantee that the elements of a container can be
destroyed after an exception is thrown or if we should specify exactly
what guarantees should be made for each member function.

3.4 s[0] = s[1]

The problem here is that the basic_string non-const operator[] is
invalid after a subsequent call to any non-const member function.  In
theory (although I doubt any implementation would get it wrong)
therefore s[i] = s[j] might be invalid.  When s is non-const the
second call to operator[] could invalidate the reference returned by
the first call to operator[].

We discussed solutions to this in detail and the resolution was to add
requirements to the WP for the lifetime of references which would
mandate that the above example work.

3.5 lifetime of iterators

The question here is whether pointers/references remain valid during
vector::insert.  A complete resolution will need to be investigated
before the July meeting.  At this meeting we decided that the issue
applies to deque and string as well as vector and that
vector::insert(iterator position) (which inserts a value of type T at
position) and vector::insert(iterator position, const T& x) ( which
inserts x at position) should be changed so that pointers/ references
do remain valid during insertion.


4. Conclusions

I thought that this meeting was somewhat low-key since we were unable
to actually vote on technical issues.  I believe that the July meeting
will be very different.  We have a fairly large issues list. Certainly
some of the library issues are long-standing and controversial and
will definitely impact Digital's standard library users.  For example
Judy and I submitted the following library issues:

    1.  We would like to see C library names removed from 
        namespace std.  The Working Paper says that the C++
        standard library will provide the 18 ISO C library headers 
        in a <cname> form which brings ISO C names into the namespace 
        std and a <name.h> form which brings ISO C names into both the 
        std and global namespace (excluding macros).  The problem, we believe,
        is that the implementation for this is highly error prone and
        will lead to unmaintainable C headers and serious bugs.  We
        would likely end up with duplicate .h headers one supplied by C
        and one by C++.

    2.  We would like to change the fstream classes so that they can
        access an underlying C file descriptor/pointer from a streambuf.
        This functionality was available in the non-ANSI fstream
        classes.  Without it C++ users who need to work with C library
        features like sockets and extensions to stdio for special file
        types will have a problem.

Not many library vendors participate in the library working groups.
The only really active library vendors other than Digital were
SGI (who only provides the STL), Plum/Hall and Bill Plauger.
If we want to influence the direction that the standard will take in
the library area on the remaining open issues we should plan to be
actively involved in the next meetings.

As before I have copies of all the papers passed out at the meeting as
well as the list of library/core issues.  I also have notes on the
topics discussed above.  I will leave these on my desk in case anyone
wants to look at them.
    

Feel free to redistribute this to whomever you think might
be interested.

Trip Report for ANSI C++ standards meeting in Nashua, NH
Mar 10-14, 1997

Judy Ward

1. Introduction

The ANSI/X3J16 and ISO/WG21 C++ standards committee met
in Nashua, NH during the week of Mar 10 - Mar 14th 1997.
Digital sponsored this event at the Crowne Plaza Hotel off exit 8.
There were approximately 50 attendees representing different
C++ compiler vendors, C++ library vendors and C++ users.
Besides Randy Meyers, Sandra Whitman, and myself, other
Digital guest attendees included Mark Davis, Coleen Phillimore,
Alan Martin, Brian McCarthy, Jeff Zeeb and Rich Phillips. 

2. Status of Standardization

The purpose of this meeting was to try to get a jump start
on the U.S. public comments (the comment period does not
end until March 18th) and to vote on what the U.S. position
should be on whether to accept the committee draft. 

There were approximately 36 public comments received as
of the start of the meeting, many of them broken down
into smaller separate issues. About 25% were closed as having
already been discussed or as request for extensions or
as misunderstandings of the current standard. The rest
were migrated to "open issues lists" (there is one
list for all library issues, and one for each of the
three core language groups.) I have copies of these
if anyone is interested. The group with the largest
number of open issues is the language extensions group,
which have many unresolved template issues. There was
discussion of that subgroup having an interim meeting
between now and July to work on proposed resolutions.

At the end of the meeting, the US TAG voted 21 to 3 
to recommend that the US vote "Yes, with comments"
on forwarding the CD. EDG, HP, and Metaware representatives
were the only ones who voted no. At least with regard to 
EDG I think their reason for voting No was that they thought 
the committee needed more time to resolve all of the open 
template language issues.

To summarize the current schedule:

Mar-97          NASHUA Meeting -- US TAG position resolved
Mar 18 97	public comment period ends
Apr-97
May-97
Jun-97
Jul-97                UK Meeting
Aug-97                Complete DIS Draft
Sep-97
Oct-97 DIS Ballot
Nov-97 DIS Ballot     New Jersey Meeting
Dec-97 DIS Ballot
Jan-98 DIS Ballot
Feb-98
Mar-98                Sophia Antipolis, France Meeting
Apr-98                Complete IS copy
May-98
Jun-98
Jul-98 IS Publication (est.) Rochester, NY
Aug-98

At the next meeting (UK) the schedule calls for the
X3J16 committee to review all national body issues 
and vote on final changes to the draft before submitting
it as a DIS (Draft International Standard). After the draft 
is submitted as a DIS only editorial changes are allowed,
so this will be the last chance for any non-editorial changes
to be passed by the committee.

3. Marketing Issues

Rogue Wave sent one new representative to this meeting, Sree
Natarajan. According to Sree, Randy Smithey and him
are the only developers on the standard library project
since Phillipe Le Mouel left to work on JAVA development. 
Sree does all the porting of the standard library to various 
compilers and Randy does all the bug fixes. 

IBM has bought the Plum-Hall/Plaugher standard library.
They cited Microsoft compatibility as a major factor in
their decision.

Borland did not send a representative to this meeting;
they usually send Pete Becker but he is too busy closing
down the Boston office of Open Environment Corporation
(which Borland recently purchased). Microsoft again did
not send any representative.

Jerry Schwarz's company,  Intrinsa, sells a tool called
Prefix which is designed to do static checking of your
C++ code for potential errors, i.e. dereferencing a null,
returning an address of a local variable from a function,
etc. He said a license would cost about the same as Purify.

One of the attendees commented that the major problem with
JAVA performance is that the language does not guarantee
that arrays will be allocated in contiguous storage.
He said that without this guarantee JAVA programmers
will never get the efficiency of a language like C.

Also, I heard the EDG folks saying they had gotten requests
for them to work on a JAVA compiler, but they cannot start
on this until they are finished with C++.

4. Technical Issues 

4A. Library Issues

There were two major library issues discussed at this
meeting - exception safety for the STL and allocator issues.

My last trip report described some of the allocator issues.
The unresolved part of the allocator specification discussed
extensively at this meeting was what the description of an 
allocator "pointer" typedef must support. Some vendors want
to use "smart pointers" as their allocator pointers and they
need to know what behaviour STL container writers will expect
from these smart pointers.

For example, must these pointers be convertible to and from
void pointers, to and from derived/base pointers, and to 
and from the equivalent const pointers? Must you be able
to compare them against 0 or against NULL or should we
have a special null typedef inside the allocator class? 
Must there be a total ordering on all your pointers,
not just pointers in the same array? Must the following
be true about the lifetime of the pointers:

// p1 and p are allocator::pointer types
p1 = &*p;
// do not deallocate or destroy pointer p
// here, but can apply operator++ to it
Is p1 still valid? 

David Abrahams from a company called "Mark of the Unicorn"
attended this meeting for the first time because he is
very concerned about exception safety in the STL. Matt
Austern from SGI presented his current thoughts on what
the library can/should guarantee about exceptions. 

He proposed that with the following restrictions on user-defined
types and algorithms:

1. T::~T() can't throw
2. No operations on T, including assignment, can ever put
an object of class T into a non-destructable state.
3. allocator::deallocate() can't throw
4. valid manipulations (i.e. pointer arithmetic) on
allocator::pointer , allocator::const_pointer, allocator::size_type 
and allocator::difference_type can't throw exceptions. 
5. The algorithms uninitialized_copy(), uninitialized_fill() and 
uninitialized_fill_n() must be responsible for destroying anything
they've partially constructed if an exception is thrown.

that the library might be able to support a "weak guarantee"
on exceptions, i.e. any time an exception is thrown the container
will be left in a state where the container elements can be destroyed
safely and there will be no resource leaks.

David wanted stronger guarantees in some situations, i.e. that
not only can you safely destroy all your resources when the
container throws an exception but you can also continue with
program execution safely. There was some doubt about the
feasibility of implementing this guarantee along with keeping the
library efficient.

Sandra Whitman and I submitted two public comments that were added 
to the library open issues list.  One had to do with whether standard 
"C" library names should have to be in the "std" namespace and
the other was whether an fstream user could have a way to 
access the underlying C file. Both of these issues
have been discussed before but with no consensus. We hope
that in England our recommendations will be accepted. 

4B. Language Issues

The two major language issues discussed at this meeting.
They were relaxation of void and default template arguments.

The relaxation of void issue was relatively non-controversial.
The problem is that many of the STL function objects are
supposed to work arbitrary functions, including ones that
return void. The language currently does not let you return 
a void object, i.e. if you try to write a generic pointer
to function class:

template <class RETURN_TYPE>
class pointer_to_function {
private:
	RETURN_TYPE (*pf)(); // pointer to function "f"
public:
	RETURN_TYPE operator() 
	{ return (*pf)(); } // currently illegal if RETURN_TYPE is void
}; 

and then instantiate this class with a function pointer "pf"
that returns void, the compiler will complain. 
The committee decided that it should recommend that 
the language be changed to make returning void legal.

The most controversial issue was default template arguments.
Currently the following code is illegal:

template <class T>
class vector {
	vector(int size, const T& = T());
};

class myelement {  // myelement does not have a default ctor
	myelement(int);  
};

vector<myelement> m(4,myelement(0));

Even though the default constructor for myelement
is not ever needed, the compiler will complain at
the point of instantiation of vector because it typechecks
every default argument expression even if the expression
is never used.

The STL as it is currently specified makes heavy use
of the default template arguments because its designer
did not realize the implications of this rule. So at
this point the draft needs to be changed to either remove
all of the default template arguments in the STL (instead
specifying an equivalent set of overloaded functions)
or the language needs to be changed so that the above
code is legal. The committee was about split evenly on 
whether the library or the language should be changed.

Some other minor language issues discussed were:

1. Do default arguments that are not used have
to be defined, i.e:

int f();
void foo(int j = f()) {;}
foo(3); // does f() need to be defined?

The resolution of the above will probably depend
on the resolution of the default template argument
issue.

2. Do static initializers have to be invoked at
the point of instantiation, i.e.:

void f() {;}

template <class T>
class C {
	static int i;
};

template <class T>
int C<T>::i = f();

C<int> c; // f() called??

The resolution at the last meeting that static initializers
need not be defined unless they are used implies that the
answer to this is no, f() is not called until i is used.
An example will be added to the draft to make this clear.

5. Conclusions

I think Digital reclaimed some of its reputation by choosing 
a nice site and having a well-organized meeting (Good job, Randy!). 
It's too bad the weather didn't cooperate. Some people did make 
comments that their managers were getting concerned about 
them attending meetings in Stockholm, Hawaii, and Santa Cruz but 
when they asked to go to Nashua there was no problem. (:

I think the committee will be very busy at the next meeting 
in England trying to finish up the large number of open unresolved 
issues. Hopefully they will not make any major blunders in the pressure
to resolve all of them.

A new draft will not be available until after the next meeting 
since the committee is not allowed to make changes until all of 
the national bodies have submitted their comments. There was
some dispute as to whether the project editor is even allowed
to fix obvious typos or misspellings without national body
approval, it seems that some countries just look at the number
of "diff" marks and will vote no if there are too many of them -
even if they are all trivial differences.

Feel free to stop by my office if you want more information.  
I have lists of all the open issues with proposed resolutions 
(if available).