[boost] Re: shifted_ptr: why?

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-04 06:37:05

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uvfr6c4yi.fsf_at_boost-consulting.com...
> "David B. Held" <dheld_at_[hidden]> writes:
> > [...]
> > I guess it depends on what you call "unsolved exception
> > safety issues".  You can solve any exception safety issue
> > with a suitable number of constraints on user code (the
> > extreme case being "user code will not throw any
> > exceptions"). ;)
>
> Seriously, constraints on user code *are* an important part
> of the picture.  I expected those to be part of the solution.

Good, because after I wrote that, it occurred to me that some
guarantees simply are not obtainable, no matter how much
library code you write.

> [...]
> > The latest version of the code is available on CUJ at:
> > [...]
>
>  Uhm.  Is this the same as the sandbox?  I'd rather use the
> sandbox, especially if I might check in portability fixes.
>
> Or did you mean "the latest version of"... something else?

Well, here's the problem.  Because the latest version was
designed to work, and not be portable, I ripped out some
portability stuff from the version in the sandbox.  Whether
that affects the compilers you intend to use or not, I don't
know.  So re-integrating my latest changes with the sandbox
is going to be a trick.  What really needs to happen is that
we need to come up with a list of compilers that could
realistically work with the library, and decide how far we
are willing to go to make them work.  At this point, I think
there are too many c'tor issues for VC6 and bcc 5 to be
serious contenders.  The vast majority of the work goes
on in the c'tors, and there are a lot lot lot of them getting
called at many different levels for the compiler to get
confused with.  Heck, I get confused!

> [...]
> It's a lot easier to wade through and kill off specific
> errors...  Porting can be tedious, but it tends to be tractable.

Well, I put in a lot of hair-pulling hours with VC6 and bcc 5.
In the end, they would pass one test or another, but not all
of the ones I wanted.  VC7.1 comes really close, but has a
few nasty bugs to contend with.

> > Like I said, the latest version, which includes all the tests,
> > is on my own CVS server, but if people are really
> > interested in helping to port it to other platforms, I will
> > update the sandbox with the latest version.
>
> Please do.  I'd like to take a poke at it.

I guess what I'll do for now is put the latest "non-portable"
version in a subdirectory of policy_ptr.  If you do check out
the sandbox, note that the docs are horribly out of date now.

> > The tests aren't technically complete, because one issue
> > that has remained unresolved for quite a while is how to
> > deal with move policies.  So there are no tests for the
> > move configuration, and if you do an archive search, you
> > can see why in a discussion here on Boost.
>
> A clue; a link?
> [...]

Too many c'tors, of course. ;)  Namely, the fact that the
move policy relies on the by_ref<> c'tor, which uses a
user-defined conversion, which is worse than the
conversion c'tor (templated), which uses no user-defined
conversions.

template <typename U, ...>
smart_ptr(smart_ptr<U, ...> const&); // this gets called...

smart_ptr(by_ref<smart_ptr>); // ...instead of this

So one would like to disable the conversion c'tor, but
enable-if is a bit too tricky for the compilers I was using.
The obvious approach is to partially specialize for move
policies, but frankly, I don't want to put in the work to do
that.  We've been hoping that a non-obvious but simpler
approach would magically appear from the sky.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003