[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