Title: The Casting Vote I

Author: 

Date: 31 January 1997 08:57:00 +00:00 or Fri, 31 January 1997 08:57:00 +00:00

Summary: 

Body: 

In my last column I said that we were poised on the brink of a critical decision: to ship the second Committee Draft after the Hawaii meeting. We succeeded. That means that a sec-ond ANSI public review is about to start and each National Body will study the draft to de-cide its vote in the forthcoming ballot.

The most important effect of shipping CD2 is stability. In Kona in November the committee made very few changes that were anything but editorial. Our charter for the meeting was to clear all our issues lists and create the CD. The latter was particularly unusual: normally the committee vote to accept a bunch of changes and a small team edit them into the working paper after the meeting and the resulting document is approved at the next meeting. In Kona, we voted on a few changes in the middle of the meeting and used the next day to pro-duce the new working paper. This left us with only two motions on Friday: accepting the team managed the job very smoothly.

Those final changes

In theory, very few of the changes accepted in Kona are likely to affect the average pro-grammer. We're mostly fixing the dark cor-ners of the language now but there were a few clarifications that have slightly wider impact.

Now you see it...

The language change that I was most con- cerned about was access checking the delete operator. If you've read what the draft stan-dard says about this, you'll probably agree that it is virtually unimplementable, effectively re-quiring runtime checks that would place a high overhead on implementations. The Core I sub-group considered various ways to clarify this and finally settled on the following:

• When a destructor is defined, a publicly accessible, unambiguous operator delete() must be found (which can include the global operator delete()).

What concerns me about this change is that it breaks the idiom of making a base class operator delete() private in order to restrict the dynamic memory operations used on a class—derived class destructors will be ill-formed because the visible operator delete() is not accessible. I sat in on this discussion: there did not appear to be a reasonable solution that still respected access control so I guess we'll have to live with this one.

Can you point to it?

The other change which bothered me and bothered the UK sufficiently to vote "no" on submitting CD2 - is a library change. The working paper is very vague about allocator classes. The intent is that an allocator encapsu-lates memory allocation and deallocation for a particular memory model (e.g., near, far, huge on Intel architectures). The concept of "memory model" is a broad one and can be taken to encompass shared memory, persistent memory and so on. The allocators described in the working paper supported this, in theory, by having member types for pointer and reference, allowing managed memory that is accessible via smart pointers.

I say "in theory" because in practice the working paper was so vague about pointer and reference that some people argued that it was unimplementable. This was compounded by the fact that allocators are intended to be objects and that the working paper implied that containers must carry around these objects as part of their internal data structures some container operations were very poorly specified in this area.

I, and a few others, argued that the draft was clear enough but you just might not like what it said! In the end, after some heated exchanges and hard bargaining, allocators were crippled but not beyond recovery. What CD2 says of allocators is:

• reference is always T& because C++ does not support smart references,
  
• the standard containers are only guaranteed to work with allocators whose pointer type is T*,
• the standard containers are only guaranteed to work with allocators whose in-stances compare equal and are interchangeable.

I have no real problem with the restriction on reference although it precludes conforming extensions (such things are possible, if rather exotic). The restriction on pointer means that you cannot write an allocator for shared mem-ory, for example, and have it work with the standard template library. The restriction on instances makes it extremely hard to write effi-cient allocators that handle more than one arena of memory.

Despite the claims of unimplementability, I have allocators that work with shared memory and I have containers that work with those allo-cators. Allowing for limitations of current compilers, these allocators and containers are intended to be standard conforming: the change at Kona has effectively broken my code. I believe very strongly that the standard template library should provide better guaran-tees of operation with user-supplied allocators. All is not lost, however, since I intend to work with Matt Austern - one of the authors of the proposal that introduced the restrictions - to specify requirements on pointer and, hopefully, instances that will allow the restrictions to be relaxed during the resolution of CD2 com-ments.

The next step

Expect to see smaller and smaller columns in this series as the committee move into "minutiae mode". Our next meeting is in Nashua, NH and we will be reviewing com-ments from the public review and any that have been forwarded from National Bodies. I sus-pect that most of the public comments will be requests for extensions and they will therefore be rejected - the time for change has passed!

Notes: 

More fields may be available via dynamicdata ..