
Rene, Here is my assessment of the status of the serialization library as it relates to the Metrowerks compiler. all versions of CodeWarrior C++ CW two-phase lookup threw me for a loop. It took me long time to really understand this. Now that I do, I'm strongly convinced that it's a really bad idea. I don't know if its true - but I think I heard that it was implemented in order to make template export work - which looks like another bad idea to me. Oh well. CWPro 9.2 - my home copy All tests using utf8-codecvt fail. This includes the test for utf8-codecvt itself. I have come to believe that its an error somewhere in the MSL 9.2 implementation of the standard library. CWPro 8.3 - your machine The tests which serialize arrays fail - I haven't looked at this too carefully. There might be an issue regarding references to arrays decaying into pointers. Borland also has this problem. test_diamond fails with this compiler - I haven't figured out why it fails only here. CWPro 8.3 and 9.2 Hashed set serialization fails to produce the correct result at runtime. I haven't looked real closely at this. Since its particular to this version of CWpro I suspect it might be a library problem. I don't know how many standard libraries include support for hashed sets so I don't know for a fact that other compilers are in fact testing this. serialization of polymorphic derived pointers. Forward declaration method. I had reorganize code in archive_pointer_oserialize etc and use MSVC specific key words (used by BOOST_FORCE_INCLUDE) in order to get certain things to instantiate static variables whose pre-runtime construction is necessary for this to function. This seems like a bad idea as CW supports lots of other platforms. I tried every alternative I could find but wasn't able to find a better one that worked. "Export" functionality suffers from a variation of the above which I have not been able to overcome. So tests which use export fail. I've spent even more time on this - without success. It seems to me that CW is too smart in eliminating code that it "knows" it won't need. Actually I'm not even sure it's a CW issue. Comeau has the same symptom. That would suggest it's another manifestation of the problem I'm having comprehending two-phase lookup. CW < 8 I believe that these versions will pass 100 % Robert Ramey

On Aug 10, 2004, at 3:33 PM, Robert Ramey wrote:
CWPro 9.2 - my home copy
All tests using utf8-codecvt fail. This includes the test for utf8-codecvt itself. I have come to believe that its an error somewhere in the MSL 9.2 implementation of the standard library.
If you can send me an independent demo of anything you believe is a CodeWarrior bug, I would be most grateful. If your demonstration is depending heavily on boost, a preprocess is usually the best way to go. If you can minimize the demonstration by eliminating irrelevant code, that also helps a lot. Thanks, Howard

Robert Ramey wrote:
CW two-phase lookup threw me for a loop.
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? Stefan

Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
Robert Ramey wrote:
CW two-phase lookup threw me for a loop.
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.
Intel for windows has the "MSVC bug compatibility" switch turned on. On linux it actually detects 2-phase problems, except insofar as it's trying to emulate GCC bugs :( -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Robert Ramey" <ramey@rrsd.com> writes:
Rene,
Here is my assessment of the status of the serialization library as it relates to the Metrowerks compiler.
all versions of CodeWarrior C++
CW two-phase lookup threw me for a loop. It took me long time to really understand this. Now that I do, I'm strongly convinced that it's a really bad idea. I don't know if its true - but I think I heard that it was implemented in order to make template export work - which looks like another bad idea to me. Oh well.
Give it a chance to sink in. It's a good idea even if you ignore export because it reduces the chance that a template's meaning will change based on definitions that follow it, allows syntax checking before instantiation, and adds rigor. <snip>
CW < 8
I believe that these versions will pass 100 %
I wouldn't count on it. CW 7.x couldn't handle the "sizeof() trick", so *lots* of basic TMP things (like is_convertible) fail there. Of course, maybe you're sure that none of these things are used...? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (4)
-
David Abrahams
-
Howard Hinnant
-
Robert Ramey
-
Stefan Slapeta