On Sat, 4 Feb 2012, Kirk, Benjamin (JSC-EG311) wrote: > I opted for a named function like this: > > foo->augment_send_list(send_list); > > because it seemed a lot more self-documenting in this case than > > foo(send_list); > > For this application a functor seemed like it would complicate the intention > of the function.
It's still conceptually a functor, just one that doesn't use operator(). And really, the only advantage of using operator() for functors is that you can then pass them to functor-specifics-unaware generic algorithms... which almost certainly doesn't apply here. Anyone want to do a for_each(send_lists.begin(), send_lists.end(), SendListAugmentor())? I've been thinking about this too lately due to the evaluate-a-single-vector-index version I'm adding to FunctionBase::operator(). I don't want to leave this version named operator(), because the default implementation won't always be overridden in subclasses and icpc gives us an annoying-but-reasonable warning message along the lines of "overloaded virtual function is only partialliy overridden" in that case. I also don't really want to make it a named function, because this one actually does make sense as a generic functor. I'm starting to lean towards making it a subclass with a constructor object that takes an index and acts as a closure... --- Roy ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
