"Robert Ramey" <ramey@rrsd.com> 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