From: David B. Held (dheld_at_[hidden])
Date: 2003-10-04 06:37:05
"David Abrahams" <dave_at_[hidden]> wrote in message
> "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
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.
--- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk