any interest in lightweight version of boost::format
I know there is a boost::format and it's great. However, I needed something
faster and with more "conventional" syntax. That's the coutf library. I've
been using it for a few months and it's great.
Just to be clear, I'm not suggesting a replacement of boost::format, which
has several features that coutf does not. However in many cases you don't
need those and that's why coutf is a fair bit faster. Also the syntax is
more conventional and several people have mentioned they prefer that. I know
Alexandrescu has also created something similar to coutf (I think he called
it Printf), but I think mine is lighter, I think most people are not too
concerned about not being able to printf 45 parameters, plus it has the
Fmt/FmtGuard stuff :) .
Anyways the docs and code are at http://noptrlib.sf.net/utils/coutf, just
did another update today. Coutf could be a good second alternative to
boost::format for some people. Here are some examples of use:
coutf("Program started at %s:%s:%s\n", hours, minutes, seconds);
cerrf("Error: file %s, line %5s invalid\n", filename, lineNum);
std::string msg = strf("Hex of %s is %04Xs", 123, 123);
int count = 10;
std::ofstream ff("someFile.txt");
// prints array in hex format
{
FmtGuard fmt(ff, "%0#4x");
for (int i=0;i
Looks neat! FmtGuard is especially useful-looking. I have a couple of questions, however: - Why did you choose strf() and scoutf()? Usually there aren't any abbreviations in std stuff, and strstream is deprecated now in favour of stringstring, so wouldn't stringf() make more sense? Also, scoutf seems odd, since it has nothing whatsoever to do with cout. Perhaps streamf() would be better? It parallels stringf() slightly better, imho. - How well does it handle references? Although that can presumably avoided with reference_wrapper - How much performance does not doing it boost.format-%-overload-style save? There is a certain elegance to doing it that way... Impressed, - Scott McMurray
"Jeff Garland"
On Sat, 22 Oct 2005 17:38:21 -0400, me22 wrote
Looks neat! FmtGuard is especially useful-looking.
I agree this looks interesting -- seems like more of a topic for the dev list though...
Yes. And you should be thinking of ways to make your stuff a subset of the full format library, so we can have one library where you don't pay for what you don't use. -- Dave Abrahams Boost Consulting www.boost-consulting.com
- Why did you choose strf() and scoutf()? Usually there aren't any abbreviations in std stuff, and strstream is deprecated now in favour of stringstring, so wouldn't stringf() make more sense? Also, scoutf seems odd, since it has nothing whatsoever to do with cout. Perhaps streamf() would be better? It parallels stringf() slightly better, imho.
I've been thinking lately that scoutf should be renamed. As to the rest, I agree. I haven't even chosen a namespace. Given how often those functions are used (in my code, especially in combination with boost log and boost test), I want the names to be short but expressive. If there is further interest in boostifying this I am open to suggestions such as the above.
- How well does it handle references? Although that can presumably avoided with reference_wrapper
Specific example? I'd like to try it out.
- How much performance does not doing it boost.format-%-overload-style save? There is a certain elegance to doing it that way...
Basically (as of boost 1.32), coutf is less than 10% slower than explicitely calling operator<< and manipulators, whereas boost.format is 70% slower. As with any benchmarking, it depends on how you use the stuff, I'm sure there are cases where the numbers are reversed, but the benchmarking I did is for what I perceive as "typical" use cases. See the web page. Oliver
On Sat, Oct 22, 2005 at 06:52:03PM -0400, Oliver Schoenborn wrote:
Basically (as of boost 1.32), coutf is less than 10% slower than explicitely calling operator<< and manipulators, whereas boost.format is 70% slower. As with any benchmarking, it depends on how you use the stuff, I'm sure there are cases where the numbers are reversed, but the benchmarking I did is for what I perceive as "typical" use cases. See the web page.
I'm most interested in the compile-time performance. coutf is ~ 1/3 as many lines as format (as informally counted with wc -l) and it clearly requires far fewer template instantiations. So it looks good... reason for the curiosity is I once changed all the printfs (which were used to format messages that were then forwarded to a logger) in a fairly large project to boost::format and the compile time for the project tripled (this was with an old gcc, boost 1.32). -t
participants (5)
-
David Abrahams -
Jeff Garland -
me22 -
Oliver Schoenborn -
troy d. straszheim