[std-interval] Portland standardization meeting feedback

Steve Clamage Stephen.Clamage at Sun.COM
Sat Oct 21 09:13:51 PDT 2006

A minor correction: A new version of the standard has a longer approval 
cycle than a TR, and during the approval cycle, work on TRs can 
continue. It is possible for TR2 to be available around the same time as 
the new standard.

Steve Clamage, stephen.clamage at sun.com

Sylvain Pion wrote:

> Dear std-intervallers,
> Here are some news from the discussions that just took place at the ISO
> C++ (WG21) meeting in Portland, concerning the interval and bool_set
> proposals.
> The proposals have been discussed by the Library Working Group.
> The discussions have not entered much details, because the committee
> is very busy, and almost nobody had looked at the details before the
> presentation.
> The LWG nevertheless ran the following 3 straw polls, which results
> are still positive for us.  I guess a more formal vote for inclusion
> in TR2 will take place at one of the next meetings.  ( TR2 itself will
> probably take a few years to be closed, as work on C++0x has higher
> priority. )
>                                  ++  +  -  --
> Interest in bool_set :            3  5  0  0
> bool_set for C++0x (vs TR2) :     0  1  2  4
> Interest in interval for TR2 :    2  5  2  1
> So both proposals are still supported, targetting TR2 rather than
> C++0x.  We're still on track!
> [ Notes :
>   - C++0x is the code-name for the next standard
>     (hopefully published in 2009),
>   - TR2 is the name for a technical report which is non-normative,
>     but published, and which compiler vendors try to follow.  It serves
>     as a place to expose the proposals on a large public scale.
>     For example, Boost has an almost complete implementation of TR1,
>     and GCC and Dinkumware as well (the standard lib of Visual C++).
> ]
> The only reason raised by those against the proposal is the
> implementation difficulty.  One of them would be OK if there was
> some non "open-source" (in the sense of "lawyer-frightening")
> code available that he could base his code on.
> I told him I hoped that IEEE754r will hopefully imply that such
> code will be made available at some point through the libC...
> Boost people would appreciate if a default implementation would be
> made available.  So, one question : is there any volunteer here
> to do that ?  Something based on MPFR or CRLIBM or any other open
> source code would do it, as long as it follows the specification,
> and has the Boost License.  It's pretty important to get support
> from them.  It does not have to be top-efficient nor top-precise,
> but it has to exist and match the specs.
> I did not get much technical questions, only minor things :
> - the I/O specification as we did it is the right thing for now,
>   but breaks the ABI (it adds a virtual function to a class).
>   It is a general problem, and this most probably means it will
>   be solved by others, and we will just have to follow.
> - some remarks have been raised for the choice of free functions
>   versus member functions (by Jeff Garland).  But after discussion,
>   I think I convinced him that we do something reasonnable.
> - bool_set should most probably not offer the && and || operators.
> I'm sure we'll get more questions once people seriously look at
> the specifications, but it may not come soon.
> I guess that the next task for us is to issue revisions of the
> proposals, and then ask for a formal vote for inclusion in the
> TR2 working draft.

More information about the Std-interval mailing list