Stefan Slapeta wrote:
Robert Ramey wrote:
CW two-phase lookup threw me for a loop.
What I meant was it left me dazed and confused.
This seems _very_ strange to me because two-phase lookup should also be turned on for Intel 8, so I don't understand why all the tests pass on this compiler. Please could you mail me a particular test case or code sequence which you think was failing because of two-phase lookup issues?
Is this something that can be turned off/on at will for intel? And/or other compilers? I use boost-build defaults as much as possible. Hmmm - maybe two phase lookup should turned off by default for boost? This experience has convinced me that two phase lookup is a bad idea. A couple of months ago I tested the library with intel 8.0 . After resolving one anomally (related to typeid of const/non-const) 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. 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. 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. I think C++ would be much improved if the standards committee would be a little more conservative about "mandating" untested features. 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. I've had huge difficulties traced to arcane areas of C++ that are really too hard to understand for the normal person. Anyway - one man's two cents. Robert Ramey