Agenda

[Jim Dehnert]

Sorry, it appears that I did not send this.  My apologies...

Following is an updated agenda.  The status pages are updated and on
the web at:

	http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html

The contact info page is now also there, in password-protected PDF only
for privacy.  The password is "not an orc".

A reminder:  At this meeting, I'd like to clear away most of
the significant and solvable issues, as I'll be gone for the following
5 Thursdays, and several implementations are far enough along to need
resolution.  That means:

  - Please look over the open issues carefully, and try to sort out
    your ideas/position on them.

  - This is a good time to not miss the meeting if
    you care about the issues.

  - I'd like to try real hard to start on time, and we might go
    overtime.

As usual, most of the updates are in the ABI layout document, in color.
The significant changes from last week are:

 - Fix ordering of the construction vtable.
 - Add destructor, demangler APIs.
 - Yet another try at substitution grammar in mangled names.
 - Don't substitute builtin types, reverse mangling substitution order.
 - Vague Linkage of template instantiations.
 - Specify location of unwind tables.

Please take a careful look at the colored text, and raise any issues
you observe.  In particular, be prepared to list other things which
need to be mentioned in the vague linkage section.

Take a look at the material associated with the following issues.
Many of them are issues we think we've resolved, and all that's missing
is final approval of the descriptions.  If you see something, please
send it by email, and it might get fixed before the meeting.

  1) C-2:  Priority for constructors.  The base ABI group is not
     particularly interested in this, because they are not getting
     pressure from their C++ people to worry about it.  So, if we want
     to standardize this, we need to apply pressure within our
     companies.  There was substantial interest in pressing ahead at
     the last meeting, and I can raise it again with the base ABI, but
     it won't go anywhere unless the others have heard from their C++
     people!

  2) F-2:  Mangled name size.  Our hope has been that the substitution
     mechanism will make further efforts unnecessary.  How do we go
     about validating this?  Martin's first data are excellent.
     Martin and Alex both plan to try the library's names -- any luck?

  3) F-2:  Substituting
     I notice that we're counting the function name in the substitution
     count before the parameters.  I presume this makes no sense, since
     it's not a real entity without them.  True?  (This may be my
     doing...)

     Also, Alex brings up the question of the nested name grammar, and
     whether 'tis nobler to have a simple grammar or a precise one.
     Any strong opinions?

  4) E-*:  Do we go anywhere with templates?  Note that our mangling
     and vague linkage specifications should be sufficient to make
     instantiations play together -- the principal issue is whether to
     attempt to specify how to deal with instantiations that aren't
     produced when the reference occurs, i.e. export templates.

  5) H-*:  Do we go anywhere with the runtime library interface?
     I have been convinced that the extensive use of templates and
     associated helper functions probably makes it impractical in the
     short term to connect all but the simplest objects compiled with
     one vendor's header files with another vendor's libC.

     An intermediate model that might be more tractable is this:
     Suppose that one compiles objects with multiple vendors'
     compilers, but all with the header files for the target system.
     Then the key issue in making them work together will be whether
     the various non-Standard-Library interfaces used by the compilers
     (e.g. internal math functions or some such) play together.  If the
     ABI specifies that such runtime routines be named to avoid
     conflicts (e.g. __cxa_sgi_foo) and be placed in a library separate
     from libC so that each vendor's set could be linked into the end
     program, this seems doable.  Comments?

  6) G-4, C-14:  Specify form of local-scope single-initialization.

After the hiatus, we will talk about:

  8) F-3:  Mangling instantiation/specialization.
     F-4:  Empty throw specifications.
     F-10: Mangling return types.

Also, note that it doesn't usually work to try to contact me by email
or phone the morning of the meeting, as I come directly from home.  If
you come in physically to the meeting, and the receptionist won't let
you come back to the conference room on your own, have her call the
conference room (it has a phone other than the one we use for the
meeting).

Jim

-		Jim Dehnert  x3-4272