Moving from Loki::Functor to Boost
I have an application that depends pretty heavily on Loki::Functor, including some extensions/fixes I've made. That works great. But I want to use smart pointers more extensively (in particular I have a need for weak references), and so before I go further with advanced template use, I'd like to switch to Boost, since it's being actively developed. Can anybody point me to a reference comparing Loki's Functor's to Boost's function wrappers? I'm ready to dive into "Beyond the C++ Standard Library", but first I'd like to know if there's anything like a guide for moving my current code. (I only use other parts of Loki very lightly, BTW.) In addition to figuring out the straight substitution of one library for the other, I have to cope with the modifications I've made to Functor: - they can be "null" in the sense of not being bound to a function call and throwing an exception if called (so that they can be embedded in a class and assigned a value later) - there are initialization forms, and corresponding macros, that record the file & line where a functor is created, and log invocations - they can wrap method calls to Objective-C objects Heh, the last one reveals a bit about the platform I'm developing for ;-) -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice
Hello,
Can anybody point me to a reference comparing Loki's Functor's to Boost's function wrappers?
Well, last version of Loki (0.1.6) includes 'Function' that 'Allows a boost/TR1 like usage of Functor'. It's pretty close to what you may expect from boost.function.
In addition to figuring out the straight substitution of one library for the other, I have to cope with the modifications I've made to Functor:
It's already in Loki. You just have to define LOKI_ENABLE_FUNCTION. This adds bool empty() and void clear() to a Functor and bad_function_call exception. Is there a reason to not use boost types with Loki Functors? -- Constantin Bryzgalin http://www.oneclicktools.com
Well, hey! Looks like I gave up and decided the Loki project had died off just before you guys started issuing updates. (I think I'm using a patched-up 0.0.3.)
It's already in Loki. You just have to define LOKI_ENABLE_FUNCTION. This adds bool empty() and void clear() to a Functor and bad_function_call exception.
I'll have to check out the new stuff, ASAP.
Is there a reason to not use boost types with Loki Functors?
I'm a little leery of, for example, mixing storage and locking policies. Do I really want 2 sets of smart pointer & lock templates in my code? And, although I see now that Loki is once again moving forward with regular updates (and has been for almost 2 years), I might still prefer Boost, because it provides a much broader set of libraries. Some of the recent updates to Loki (weak smart ptrs) may well fill my need for the immediate next step I want to take, but I'm also trying to look farther ahead... I've got 0.1.6 and will read through all the release notes. -- Scott Ribe scott_ribe@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice
Hello,
Is there a reason to not use boost types with Loki Functors?
I'm a little leery of, for example, mixing storage and locking policies. Do I really want 2 sets of smart pointer & lock templates in my code?
Your code will contain only those you instantiate. :) In my code I have 4 of them (from MS ATL, Loki, boost and POCO) but that doesn't mean I use them all at the same time. boost::shared_ptr and std::auto_ptr most of the time actually. Despite differencies all of them serve their purpose quite well so you'd better use one you're used to (if there's no 'special' requirements). And of course rewriting a lot of code just because you're replacing some miscelaneous class is not a very good idea. :) -- Constantin Bryzgalin http://www.oneclicktools.com
On May 24, 2007, at 5:34 PM, Scott Ribe wrote:
boost::function does this already. The exception is called bad_function_call.
We don't have the latter two in boost::function. I expect you'll find that Loki::Functor and boost::function are very, very similar, given that we were both basing our interfaces on the same trivial principle: function objects. - Doug
participants (4)
-
Constantin Bryzgalin -
Douglas Gregor -
Jeff Garland -
Scott Ribe