[boost] Re: serialization and cwpro status

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-11 14:14:09

"Robert Ramey" <ramey_at_[hidden]> writes:

> Is this something that can be turned off/on at will for intel?

Sort of.

> And/or other compilers?  

Some but not all.

> I use boost-build defaults as much as possible.

That's good.

> Hmmm - maybe two phase lookup should turned off by default for
> boost?

No, the Boost practice is to make compilers conform where possible.

> This experience has convinced me that two phase lookup is a bad
> idea.

I think we'd all have to be convinced, and we'd also have to be
convinced that it was bad enough to warrant breaking the rule
of using conforming C++ where possible.

> A couple of months ago I tested the library with intel 8.0 .  After
> resolving one anomally (related to typeid of const/non-const) 

Yeah, another Intel MSVC bug-compatibility problem.  They also don't
strip top-level references, as they should.

> things compiled and everything passed.  My 30 day license exprired
> so I haven't been able to test here since.
>
> When I went to cw pro version 9, I had the tests for non-intrusive
> serialization failed.  This uses function template overload.  This
> turned out that to be the same problem I had with Commeau.  After
> much effort I came to understand the issue.  I made adjustments to
> address this. This resulted in more changes than I wanted to make at
> this point.  Oh well.  It has also resulted in a slightly more
> complex explanation of how to use non-intrusive serialization
> portably.  This works but it offends my sense of aesthetics.  On the
> other hand, It did force me implement ADL for finding overloads.

"implement ADL??"  ADL is implemented by the compiler.

> This was the one feature that had been asked for but hadn't
> implemented.  I didn't see a way to do it without causing a two
> large ripple effect through the API, docs, etc.  Martin Ecker showed
> me how to fix this so now we have ADL for overloading serialize
> functions.
>
> So I would think that if Intel implements two-phase lookup, things
> would have failed much sooner. 

It's hard to get the Intel Windows compiler to stop being
bug-compatible with some version of VC++.  As a result, even if
2-phase lookup is enabled, the compiler may suppress errors in cases
where VC++ would've compiled the code.

This is one reason I was trying to encourage you to check in the
library before you had it ported to every compiler under the sun, so
we could get test results on a variety of compilers.

> On the other hand, during my 30 test trial of Intel 8.0 I got two?!
> Notices for updates.  It wouldn't surprise me if there are multiple
> versions named Intel 8.0.
>
> In spite of all the pain I've experienced in porting code like this
> to all such platforms.  I've come to appreciate the general high
> quality of these compilers.  They all have quirks and errors.  But
> now having had to delve much deeper into details of C++ than I ever
> had to before, I have a much better appreciation of how difficult is
> has to be to write something like this.  

Yeah, the core language is too complicated.  The library too, in some
places.

> I think C++ would be much
> improved if the standards committee would be a little more
> conservative about "mandating" untested features.  

Which features are you talking about?  In general the policy is
not to mandate untested features.  There are very few features in the
C++98 standard that someone hadn't implemented and tested at the time
of ratification.  That said, it would've been better if we'd had more
experience with quite a few features at the time of standardization.

> Sometimes I wonder if its not just a group of really smart guys
> sitting around a table thinking up the hardest stuff they can for
> other people to implement - Sort of like the marketing department.

Your point of view is just wrong.  If I wasn't in such a good mood,
I'd probably be offended at that statement.  Suffice it to say that
you'll probably offend someone who has volunteered lots of his/her own
time to make C++ better with musings like that one.

Most of the compiler implementors are on the committee, and they have
a lot to do with specifying changes to the core language.  When they
raise a big enough stink about the difficulty of implementing
something, it is usually dropped.  Export is a notable exception, but
there are only a few of those.

> I've had huge difficulties traced to arcane areas of C++ that are
> really too hard to understand for the normal person.  

Yep, we need to do better at explaining it, and we need to simplify
the specification somehow.  But substantially simplifying without
breaking lots of code and while adding the new features everyone
"needs" seems impossible :(

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com