On Tue, 30 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > The API convenience of Parallel::broadcast(std::vector<std::string> &v) is > probably still worth it though, even if this is the implementation of choice.
In cases where we have to repack a container's contents for MPI anyway, there's really no reason to force the container type. How about Parallel::broadcast(Iter begin, Iter end)? Then the same code handles map<string>, set<string>, unordered_*<string>, etc. (but as a reminder: I'm in the middle of refactoring Parallel:: and would appreciate no big changes to parallel.h until afterwards) Speaking of those two topics: while I'm shuffling around APIs anyway, would it be reasonable for the new container-overloaded versions of e.g. Communicator::broadcast to only take iterator ranges, never containers? (the deprecated Parallel:: shims would still have unchanged function signatures) We'd still implement no-copy versions for the vector<T>::const_iterator cases, but having a generic iterator based version would put an end to the sporadic "oh, this would be useful with map, let's go back and add another overload" activity we've been doing before. The only downside I can see is that "broadcast(stuff)" is more terse than "broadcast(stuff.begin(), stuff.end())". --- Roy ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
