"David Genest" <david.genest@ubisoft.com> wrote in message news:E7F3301F6AF1F341AB107794F4F80A6F19746B05@MDC-MAIL-CMS01.ubisoft.org...

Domagoj Saric Wrote:

...

it has various other space and time optimizations besides no-typeid support as well as cofigurability through policies (although it seemes to have sparked little interest)...

I read most of the thread and I'm surprised to see that you are right regarding interest. I'm surely interested which means there must be others. I'm impressed by the depth of your analysis/optimisations. Will this effort be brought in a new version of boost soon ?

sorry...i cannot know that ;) there seem to be several more 'higher-level' discussion threads active at the moment...perhaps 'resurrecting' the topic at a more peaceful time would be a good idea...

...

hope it helps...:

It will!

glad to hear that ;)

...

http://thread.gmane.org/gmane.comp.lib.boost.devel/194514/focus=195351 ;)

I didn't find any attachments in gmane, but found the vault version ( http://www.boostpro.com/vault/index.php?action=downloadfile&filename=new_function_implementation_proposal.tgz&directory=Function%20Objects& ) . Is this the latest version ?

pretty much...i paused the work on bf until there is atleast some discussion on the work so far (what's 'good' and what's 'bad') and any 'semi-official' hints that the changes/ideas might eventually be accepted...

Can I just apply the new files over the current function directory?

yes...it should be a drop in replacement... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

"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

On Fri, Nov 27, 2009 at 1:25 PM, Domagoj Saric <dsaritz@gmail.com> wrote:

/* snip */

For note, there is interest. Many times I would love to have a Boost.Function that will not throw, or even do a test if !null. In my design I make sure I never call null function pointers, so having that internal test done (along with not having code that throws an exception), which will 'slightly' improve the call speed and reduce the number of assembly instructions by a large factor. If I could set a policy that disables the null-check (which also removed the need for exception handling and such as well), I would be exceedingly happy.

"David Genest" <david.genest@ubisoft.com> wrote in message news:E7F3301F6AF1F341AB107794F4F80A6F19A0E48E@MDC-MAIL-CMS01.ubisoft.org...

Sorry for the late response...

no problem, i'm 'late' too ;) ...i was quite busy so i put this on pause as peter seems to have provided what you wanted...however if you still wish to work/try/help with my changes we can perhaps still try a few things... ;)

I got the latest version and there are still problems. Is there a chance that STATIC_ASSERT does not behave well with the xbox 360 version of the compiler ? How would I check this ?

i doubt the problem is with BOOST_STATIC_ASSERT as it is used in other places in boost.function as well as other libraries... the problem is probably with the is_stateless<> trait... ...it would seem odd that the same compiler supports a particular trait on one platform but not on the other so you should first do the two things previously mentioned: - verify that the MSVC++ 8.0 compiler that you use for the xbox has service pack 1 and all the latest patches installed - if the above does not fix the problem (or the compiler is fully patched) try replacing the is_stateless<> check with the equivalent more primitive type traits (as outlined in one of my previous posts) i've also uploaded a new version that, along other less important changes, fixes an issue with assignement/construction from boost::function<> instantiations with different signatures that in the process also removed some sfinae usage...so it perhaps might also fix some of the other errors you've been encountering... tomorrow i'll move my modifications to the boost sandbox svn to ease this process a bit... as for the SN System compiler i'm afraid i cannot help there (i've actually never heard of that compiler before)... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

sp_typeinfo.hpp wasn't quite up to the task, but I fixed it, and changed function_base.hpp to use it. The relevant patches are:

Thanks. I was on the right track then, but I now see what was needed to make it work - simple and elegant.

https://svn.boost.org/trac/boost/changeset/58127 https://svn.boost.org/trac/boost/changeset/58128

Patches applied, and working ! Thank you. I can now use boost::function in an rtti-less environment! Should I mark the bug as closed or something ? D.

"Peter Dimov" <pdimov@pdimov.com> wrote in message news:1A337E6AB7744D2D85BA1310B8188681@pdimov2...

sp_typeinfo.hpp wasn't quite up to the task, but I fixed it, and changed function_base.hpp to use it. The relevant patches are:

https://svn.boost.org/trac/boost/changeset/58127 https://svn.boost.org/trac/boost/changeset/58128

if i'm not mistaken these changes/patches provide a 'proper'/'good enough' typeid/type_info implementation to make the full (boost/tr1)::function interface (including target<>()) available even for platforms/compilers that do not provide RTTI/when BOOST_NO_TYPEID is defined? this is great on its own but it seems that perhaps we need another related macro...something like BOOST_EMULATED_TYPEID and BOOST_NO_TYPEID where the latter would not try to emulate but completely disable RTTI related functionality (where possible) ... ...boost::function is a perfect example to show the need/usefulness for this: my real life project i used to test boost::function with has grown further (with more functors that get assigned to boost::functions) and i recently refactored it to no longer need boost::function at all but i could use plain function pointers so i could better test the impact that the usage of boost::function has on a/my binary... here are the results (in bytes and in ascending order, aligned for fixed width font): ( bf = boost::function 1.40, abf = my altered boost::function 1.40 ) plain_function_pointers 514.048 abf + BOOST_NO_TYPEID + assert_on_empty 537.600 abf + BOOST_NO_TYPEID 546.304 abf + assert_on_empty 635.904 abf 644.096 bf 660.992 it is obvious that RTTI/type information has the biggest role in bloating a binary (atleast in use cases like mine with lots of template generated function objects, that therefor have very long type names) (i hadn't yet had time to upgrade to 1.41 with your patches to test that also) (as argued/explained before the option to turn on/off the rtti features of boost::function should be a local/on a case by case basis switch/a matter of policy rather than a global switch/macro) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley