On Thu, 11 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > what do you think about replacing the *libMesh::out construct with a > libMesh::out() ? > > perhaps a *little* less awkward...
I thought of five ways to do this, one of which I disliked for technical reasons and the other four of which seemed awkward in one way or another. So it's a matter of opinion, and I'll defer to yours. But let me list all the other options I considered, first: A. Making libMesh::out an ostream*. B. Making libMesh::out an actual ostream. The trouble here is that depending on how standards conforming your compiler is, copying an ostream is either frowned upon or outright forbidden. And I want to make it easy for users to do iostreams magic even if they don't know how to build their own streambuf and futz with rdbuf. C. Making libMesh::out a function that returns ostream&. We can't make it an actual reference-to-ostream, because then C++ wouldn't let us reseat it, but we can return one. I just preferred the pointer because I figured "*" was less typing than "()", but I'll happily change my mind of others prefer this. D. Making libMesh::out a subclass of ostream. This gets tricky to do right, and means that we have to either anticipate users' future uses or require users to be equally tricky. E. Making libMesh::out a class which internally stores an ostream*, and which has a "reset(ostream&)" function to change it, a templated operator<< method to pass output to it, and an implicit conversion-to-ostream& operator to return it. This is the prettiest thing to do for user code, since then "libMesh::out << whatever" works and users can mostly treat it as they would a std::ostream, but I was wary that I might be forgetting about exceptions (in the metaphorical sense, but maybe also in the literal?). Anybody want to register opinions or suggest a plan F? If I'm not the only one to immediately notice the awkwardness of my plan A, perhaps plan E is the way to go? A dozen extra lines in a header might be worth getting rid of a hundred redundant symbols in the code? --- Roy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
