"David Genest" <david.genest@ubisoft.com> wrote in message news:E7F3301F6AF1F341AB107794F4F80A6F197FC350@MDC-MAIL-CMS01.ubisoft.org...
Hi Domagoj,
I am on xbox 360 with visual 2005, PS3 with SNSystems SNC compiler and gcc compiler v 4.1.1.
I have tried your implementation and compilation fails at a STATIC_ASSERT: BOOST_STATIC_ASSERT( is_stateless<base_empty_handler>::value );
A simple declaration of boost::function<void ()> f; will create this error.
A similar assert happens with SN systems compiler for the PS3.
hmm...according to http://www.boost.org/doc/libs/1_40_0/libs/type_traits/doc/html/boost_typetra... the is_stateless<> trait should work properly on msvc++ 8... can you try replacing is_stateless<> with has_trivial_constructor<base_empty_handler>::value && has_trivial_destructor<base_empty_handler>::value && is_empty<base_empty_handler>::value ?
When I use gcc, there are a slew of errors mostly pertaining to declaration order in function_template.hpp. I am not very familiar with this issue, but have tried to move code around, and defining functions out of class scope. Some errors go away, but there are a lot of compiler problems at least on my machine.
i was afraid of that...i relied on lazy template instantiation in several places and used forward declarations of member types (with out-of-body definitions) to improve readability...this worked properly on msvc++ (as it is pretty lazy with template instantiations) but gcc is obviously much less 'liberal'/permissive about that (i don't know what the standard has to say about it?)...
Here is the error on xbox 360: ... 1> myFile.cpp(64) : see reference to class template instantiation 'boost::function<Signature>' being compiled 1> with 1> [ 1> Signature=void (void) 1> ]
this part looks 'wrong'...as if myFile.cpp still used "some part of the old headers"...because in the new implementation the main bf template has the following 'signature' boost::funciton<Signature, PolicyList>...perhaps you should do a clean rebuild...(you must also rebuild boost if you use any non-header-only libraries that internaly use boost::function)...
There were also some trouble when compiling templates that end in ">>" which AFAIK is not fixed on my version of gcc.
Do you know if your changes made boost.function less robust to older compilers ?
well...obviously/most probably they did unfortunately...besides avoiding sfinae in a few places i did not spend too much effort on old compiler compatibility issues... i tested only on msvc++ 9.0 sp1 and 10.0b1...there it compiled without warnings and worked correctly...but yes, this is just a prototype, draft version on which only a limited number of, my own, tests were run (i did not run the official boost tests...because i have yet never run those tests and do not know how they work and because allocator support is still/currently disabled)... without ignoring the old-compilers-backward compatibility issue...considering that the two compilers, msvc++ and gcc, you are using are ('semi') free i would truly recommend an upgrade...yes i know you would probably have to fight some 'semi-irrational'/paranoid corporate rules and 'stiff chains of command' but, atleast when msvc++ is concerned, it will be worth the effort as it might actually save you time...not just on issues like these but because the msvc++ 9.0 compiler is about twice as fast as the 8.0 one plus it has a working multicore mode (the /mp switch) so on a dual core machine you get a ~4 times faster compilation (and for almost 0 cost...the upgrade is just a reinstall... nothing much was changed...its not like the 7.1 -> 8.0 upgrade with all the secure crt and secure stl mess ;) i do actually have a dusty msvc++ 8.0 sp1 installation (do you have all the patches installed on your installation) on a different computer...so if i get the time i'll test my code on it today and see what i can do... (i'll start using gcc on mac osx in the following year but i doubt that is of much use right now :) ps. thanks for testing and reporting the errors with your tool chain ;) ...and glad to see the 'major' gaming industry is using boost ;-) pps. found a bug: the line function_base.hpp : manager_trivial_heap::clone() { ... std::memcpy( functor_ptr( out_buffer ), functor_ptr( in_buffer ), storage_array_size ); } should be: ... std::memcpy( functor_ptr( out_buffer ), functor_ptr( in_buffer ), storage_array_size * sizeof( storage_atom ) ); ... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley