Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering

Hi Peter ----- Mensaje original ----- De: Peter Dimov <pdimov@mmltd.net> Fecha: Sábado, Diciembre 18, 2004 11:15 pm Asunto: Re: [boost] [config][gcc 3.4.2] Request for test aboutfunctiontemplate ordering
JOAQUIN LOPEZ MU?Z wrote:
Hi Martin. Well, seems my snippet does not capture the problem, but defiintely there's some difference wrt function template ordering handling between GCC 3.3.x and GCC 3.3.4: the issue is shown here:
http://tinyurl.com/3nkgw (GCC 3.4.3 on your regression machine)
This is a test for serialization capabilities of Boost.MultiIndex, and it works for GCC <3.4.x. In GCC 3.4.4, hoeever, a user-provided overload of boost::serialization::load_construct_data is not picked up.
It's probably two-phase lookup related; have you tried putting the user overload in the user class' namespace, where it belongs?
Indeed it is a 2-phase lookup issue, as Robert has pointed out.
Don't automatically jump to conclusions that partial ordering is broken; more often than not, it is the code that is broken.
How I wished that was true :) more often than not, making my library work for a wide range of compilers had nothing to do with my code compliance. This particular case is, to my delight, an exception. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

JOAQUIN LOPEZ MU?Z wrote:
Hi Peter
Don't automatically jump to conclusions that partial ordering is broken; more often than not, it is the code that is broken.
How I wished that was true :) more often than not, making my library work for a wide range of compilers had nothing to do with my code compliance. This particular case is, to my delight, an exception.
You are right. Sorry. It's just that I notice a disturbing tendency to define global defect macros to work around a particular failure in a particular library. Even if the compiler is indeed at fault, and sometimes it is not, the shortcoming usually does not affect the other 50+ libraries in Boost. Defining the global defect macro would be a bit harsh. This has been true in the old Boost days as well, but lately the compilers are more right and the code is more wrong. :-)
participants (2)
-
JOAQUIN LOPEZ MU?Z
-
Peter Dimov