[std-interval] Portland standardization meeting feedback

[George Corliss]

WONDERFUL! ! !

Congratulations, and thanks for all the hard work.

Dr. George Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee, WI 53201-1881
George.Corliss at Marquette.edu
414-288-6599 (office); 288-4400 (GasDay);
    288-6280 (Dept.); 288-5579 (fax)
Office: Haggerty Engineering 296
Www.eng.mu.edu/corlissg



On 10/20/06 7:50 PM, "Sylvain Pion" <Sylvain.Pion at sophia.inria.fr> 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.