Re: [boost] Help with policy_ptr
David B. Held [EMAIL PROTECTED] writes: This is a request for anyone who is willing and able to help finish writing the tests for policy_ptr in the sandbox. I'm afraid that I just don't have the time to dedicate to this library to come anywhere close to the April meeting of the LWG (or whoever it is that's meeting). While most of the basic functionality for the default configuration should be covered by the tests I've written, none of the other policy configurations have been seriously tested. The one that has, destructive_copy, does not give the desired size on bcc. That's a serious problem that I have not had time to investigate. That might be a problem for Boost, but it shouldn't stand in the way of a proposal for the library TR. The committee doesn't expect a pre-existing *maximally-efficient* implementation of every library it considers. I imagine that the checking policies will not present any trouble. The conversion policy might be troublesome, as it seems that bcc and VC++ don't like the funky implicit conversion operator much. The array storage policy hasn't been tested at all. The no_copy policy should not be problematic except for the size. The deep_copy policy should be similar. ...nor does the committee care about implementability on broken compilers. I wanted to implement mojo_ptr, but did not have the time. It should be possible to do so as a storage policy, but I didn't investigate it seriously. The platforms I tested on are bcc 5.5.1, gcc 3.0, and VC++ 6.5. It's probably wishful thinking to believe that the library can get finished and reviewed by mid-March, but that would be a nice goal to achieve. I would like to apologize to Andrei for not being as diligent with this library as it deserves, and I hope there's still a chance for it to be considered for the next version of the standard library. If that's what you're after, you probably shouldn't be worrying about these minor portability issues. They're important in practice for real developers, but in the standards committee we operate in the rarified air where all compilers are perfectly conforming (just kidding, but it's almost like that). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Help with policy_ptr
At 03:56 AM 2/15/2003, David Abrahams wrote: ... in the standards committee we operate in the rarified air where all compilers are perfectly conforming (just kidding, but it's almost like that). It is indeed like that. There wasn't a compiler in the world that could handle the standard library when we designed it. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Help with policy_ptr
At 01:47 AM 2/12/2003, David B. Held wrote: ...I hope there's still a chance for it to be considered for the next version of the standard library. The April meeting deadline is not for the next version of the Standard Library; rather it is for the Library Technical Report. While nothing has been formally decided, I'm personally hoping that the LWG will start accumulating proposals for a 2nd Technical Report right away. Proposals accepted for a second TR might miss the next revision of the standard, but they still would be on track for eventual inclusion. Regardless of the details, please don't give up on this or any other valuable work just because it isn't going to be ready for the April C++ committee meeting. Rather, concentrate on getting it ready for Boost review and acceptance. That's a big step forward for a library. Standardization can come later. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Help with policy_ptr
This is a request for anyone who is willing and able to help finish writing the tests for policy_ptr in the sandbox. I'm afraid that I just don't have the time to dedicate to this library to come anywhere close to the April meeting of the LWG (or whoever it is that's meeting). While most of the basic functionality for the default configuration should be covered by the tests I've written, none of the other policy configurations have been seriously tested. The one that has, destructive_copy, does not give the desired size on bcc. That's a serious problem that I have not had time to investigate. I imagine that the checking policies will not present any trouble. The conversion policy might be troublesome, as it seems that bcc and VC++ don't like the funky implicit conversion operator much. The array storage policy hasn't been tested at all. The no_copy policy should not be problematic except for the size. The deep_copy policy should be similar. I wanted to implement mojo_ptr, but did not have the time. It should be possible to do so as a storage policy, but I didn't investigate it seriously. The platforms I tested on are bcc 5.5.1, gcc 3.0, and VC++ 6.5. It's probably wishful thinking to believe that the library can get finished and reviewed by mid-March, but that would be a nice goal to achieve. I would like to apologize to Andrei for not being as diligent with this library as it deserves, and I hope there's still a chance for it to be considered for the next version of the standard library. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
