$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [function] Using boost::function when rtti isnot available
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-27 03:49:41
"David Genest" <david.genest_at_[hidden]> wrote in message
news:E7F3301F6AF1F341AB107794F4F80A6F197FC350_at_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_typetraits/reference/is_stateless.html
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