Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-15 05:56:12

"David B. Held" <dheld_at_[hidden]> 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

> 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at