Warp <war### [at] tagpovrayorg> wrote:

> > I would argue that fully qualifying all types is much worse practice.
>
>   It would be interesting to hear those arguments.

Well lets take the example in front of us - we've got new compiler and library
releases coming down the pipe from various vendors, and we've got a new standard
that is being rolled out by those vendors at different times.

(As an aside, this has been the case for the last 20 years I've been programming
C++; standard tracking by vendors is pretty varied, and upgrading to a new C++
compiler often causes issues in existing codebases - POV is pretty lucky in that
it was all in C for most of it's lifetime, and so you've avoiding a lot of that
pain. Having a large C++ codebase is an exercise in long-term pragmatism when it
comes to these issues.)

So we've chosen boost to give us some useful functionality - a very good choice
BTW - and now boost's success has caused it's most useful low level features to
be included in the new C++ standard. That's good. But in the meantime you've got
a code management task of some vendor/compiler/version/platform/library
combinations having std::shared_ptr, and some having boost::shared_ptr.

What do you do?

Well you can do a global search and replace to make all shared_ptr's into
std::shared_ptr's, but that isn't going to work since most compilers don't have
a std::shared_ptr yet. Or you could globally change them all to
boost::shared_ptr's, which means you're not using the new code that those new
compilers have. It's better to rely on the vendors version of libraries. And
you'd have to wait an awfully long time before you have the situation where
no-one would want to compile POV with a compiler that doesn't support the new
standard.

Or you can leave them as bare shared_ptr's and instead having "using" statements
to intelligently chose (based on compiler and version) whether a particular
compilation of POV uses the version in std or the version in boost. Yes, the
existing "using namespace boost; using namespace std;" causes a problem, but the
solution is to change those two lines, not hundreds of other lines in the file.

I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
implementation (and namespace) over the "global" versions in boost. That will
give you a bit more fine grained control over managing the transition from boost
to the standard.

Also, as I suggested earlier, even that work can be carefully managed by relying
on vendor-specific switches to disable using the new standard until these issues
can be carefully considered, implemented and tested.

Cheers,
Edouard.

Post a reply to this message