From: David C. <unc...@un...> - 2005-03-24 03:59:32
|
Here are some more issues. In ui_core_implementation.hpp, there are a bunch of warnings about "specializing 'struct adobe::delete_ptr<something>' in a different namespace". It looks like all those specialization macros ought to be in a namespace adobe {} block. Other errors: client_assembler.cpp:1314: error: parse error before `>' token headers/mac/ui_core_implementation.hpp:168: error: `struct adobe::window_t::implementation_t' is private headers/mac/ui_core_implementation.hpp:674: error: within this context ui_core_implementation.cpp:68: error: no matching function for call to `adobe::auto_resource<const __CFString*, adobe::ptr_traits<const __CFString*> >::auto_resource(adobe::auto_resource<const __CFString*, adobe::ptr_traits<const __CFString*> >)' adobe/test/visual/sources/mac/ui_core_implementation.cpp:4952: error: specialization of ReturnType adobe::view_for_element(DisplayElement&) [with ReturnType = OpaqueControlRef*, DisplayElement = adobe::window_t] after instantiation adobe/test/visual/sources/mac/ui_core_implementation.cpp:5062: error: specialization of ReturnType adobe::view_for_element(DisplayElement&) [with ReturnType = OpaqueControlRef*, DisplayElement = adobe::static_text_t] after instantiation There are lots of warnings about assigning float values to int variables, and the like. Apparently gcc isn't as happy about those implicit conversions as CodeWarrior. For example: adobe/test/visual/sources/mac/ui_core_implementation.cpp:536: warning: assignment to `short int' from `float' Maybe the tracking loop (line 1160) should be a do-while loop, so finding a useful initial MouseTrackingResult value wouldn't be an issue: adobe/test/visual/sources/mac/ui_core_implementation.cpp:1117: warning: initialization of negative value `-1' to `MouseTrackingResult' -- David Catmull unc...@un... http://www.uncommonplace.com/ |