www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - FastFormat

reply Bart van der Velden <bartvelden gmail.com> writes:
Hi Matthew,

First: thank you very much for a great deal of code to explore.

Since reading here I can see that you are a very busy chap. My main
reason for coming here is to find out about your schedule for
FastFormat. I saw the projected date change from November 2006 to mid
December 2006, but somehow - call me psychic - I don't think you will
make it by that date. Can you give any indication on when a first
version will arrive? Until then, I'll keep myself happily busy with
Pantheios and STLSoft.

Cheers,
Bart
Feb 01 2007
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Hi Bart

 First: thank you very much for a great deal of code to explore.

Very nice of you to say so. I hope you'll be buying all my books that describe it. ;-) LOL!
 Since reading here I can see that you are a very busy chap. My main
 reason for coming here is to find out about your schedule for
 FastFormat. I saw the projected date change from November 2006 to mid
 December 2006, but somehow - call me psychic - I don't think you will
 make it by that date. Can you give any indication on when a first
 version will arrive? Until then, I'll keep myself happily busy with
 Pantheios and STLSoft.

 Cheers,
 Bart

What a timely request! Only two days ago I did some more work on it, and I've just been bending the ear of one or two C++ big-wigs about it. The only major obstacles are that I'm finalising XSTLv1 over the next few days, and then next week I've a short peice of work to do for a client. The minor obstacle is that I was wanting to work through the process of translating FastFormat from "concept proved" (its current state) to "highly usable library" (what I'd like to release as 0.1) while I write the chapter about it for my next (third) book (http://BreakingUpTheMonolith.com). However, as you have observed, that process has had a few delays. Given that, I may content myself with just getting it out there, and writing the chapter (later) from my memory and my source control database. ;-) The other minor obstacle is that I wanted to "launch" it concurrently with an article, probably in TCS. Maybe that, too, should be shelved. Anyway, here's an excerpt from a recent email to one of my elders and betters, which describes its main benefits: -------------------------- A quick taster: // arg0, arg1 ... are of any type for which string access shims are defined and available // 1. "stringstream / sprintf" std::string s; fastformat::fmt(s, "The first param '{0}', and the third '{2}', and the first again '{0}'. Finally the second '{1}'" , arg0, arg1, arg2); // 2. via FILE* fastformat::fmt(stdout, "Param #1: {0}; param #2: {1}; param #1 again: {0}" , arg0, arg1); // 3. via cout fastformat::fmt(std::cout, "Param #1: {0}; param #2: {1}" , arg0, arg1); // 4. via writev() int fh = ::open("abcdefg", O_WRONLY | O_CREAT | O_TRUNC, S_IWRITE); stlsoft::scoped_handle<int> fh_(fh, ::close, -1); fastformat::writev_sink sink(fh, "\n"); fastformat::fmt(sink, "Param #1: {0}; param #2: {1}; param #1 again: {0}", "abc", "def"); // 5. any other "sink" type for which you care to write an overload of the fastformat::fmt_slices() control shim namespace fastformat { mystuff::my_sink& fmt_slices(mystuff::my_sink& sink, size_t cchTotal, ff_string_slice_t* slices, size_t numSlices); } There are reasons it's called FastFormat: - The format string is converted (without allocation/copying) to a set of string slices (len + ptr), which are later interleaved with the "sliced" forms of the fmt() arguments - If caching is enabled, each unique format string is only converted once, and then cached (string and sliced form) for the duration of the program/library (since the fmt=>slices relationship does not change) - Each argument is only processed once, regardless of how many times it is used in the format string, into a string slice. - There is only one "strlen" operation for each argument. (For things that know their own length, e.g. std::string, it's just a call to size()) - There is only one "movement" (e.g. memcpy() / strcpy()) of string contents from client code argument to its inclusion in final formatted output - For the vast majority of cases, there are 0 memory allocations in processing a given statement. Obviously some "sinks", such as std::string, will do an allocation, but others, such as a raw file handle+writev(), may not (at least not in user mode). In the few cursory tests I've done so far, it's usually ~50% faster than (s)printf(), and ~200+% faster than the IOStreams. Naturally, I expect it to be considerably faster than Boost.Format (whose documentation concedes that it is several times slower than (s)printf()). It's 100% type-safe, which neither printf() nor IOStreams are. It's compatible with just about every C++ compiler still in use today (i.e. works perfectly w VC++6). Extending the range of compatible argument types simply involves overloading the string access shims stlsoft::c_str_len() and stlsoft::c_str_data(). Extending the range of compatible "sinks" simply involves overloading the control shim fastformat::fmt_slices(). Furthermore, it supports internationalisation, which neither IOStreams nor printf do. (I'd need to check this, but I think Boost.Format doesn't do this either, or at least not well.) This can be done for any language by using a different format literal, or by using format string resource "bundles", e,g: fastformat::properties_bundle fmts("bundle1.properties"); fastformat::fmt(std::cout, fmts["msg#1"], name, age); fastformat::fmt(std::cout, fmts["msg#2"], arg0, arg1); Like Pantheios, FastFormat upholds the characteristics Bjarne Stroustrup espoused in a recent interview about good C++ libraries: robust, flexible and *highly* efficient. The only disadvantage, should one wish to characterise it as such, that each has is that they depend on the STLSoft libraries for the Shim concept and the various shim function overloads. -------------------------- Basically, FF continues the application of the Type Tunnel pattern (also seen to good effect in Pantheios; and its used in the VOLE library, albeit that's still in its infancy) which facilitates complete type-safety, high flexibility and knockout performance (because there is no wasted effort in the tunneling from the client code to the underlying API). Sadly, the full skinny on the Type Tunnel pattern is to be found only in the second chapter of my third book, which is not even past the proposal stage. (What can I do? I've only got 10 fingers and 24hrs in a day; well, about 10 actually, as I've a wife and two boys and a company to run and a bike to ride! <g>) Anyhew, enough pontificating, I think. If you don't hear any news on it by the end of next week, feel free to prod me about it then, and I'll get my finger out. Cheers Matthew P.S. Feel free to join the Pantheios and/or FF mailing lists, and to prod me about either of them there as well.
Feb 01 2007
parent reply Bart van der Velden <bartvelden gmail.com> writes:
Matthew Wilson wrote:
 Hi Bart
 
 First: thank you very much for a great deal of code to explore.

Very nice of you to say so. I hope you'll be buying all my books that describe it. ;-) LOL!

Well, right now I only have a single copy of Imperfect C++. Don't you think it would be a bit unfair to other programmers if I were to buy *all* your books? <snip description of a lot of features I want *now*>
 
 Anyhew, enough pontificating, I think. If you don't hear any news on it by
 the end of next week, feel free to prod me about it then, and I'll get my
 finger out.
 
 Cheers
 
 Matthew
 
 P.S. Feel free to join the Pantheios and/or FF mailing lists, and to prod me
 about either of them there as well.
 
 
 

Thank you for the reply. I will wait patiently with some occasional prodding. I will also join the mailing lists you mentioned. Cheers, Bart
Feb 02 2007
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
 I hope you'll be buying all my books that describe it. ;-) LOL!

Well, right now I only have a single copy of Imperfect C++. Don't you think it would be a bit unfair to other programmers if I were to buy *all* your books?

Ah, I suppose you're right. ;-/
 <snip description of a lot of features I want *now*>

Hmm. Guilt. Not a bad strategy. I'll be able to ignore it for a while, but it'll get me in the end.
 P.S. Feel free to join the Pantheios and/or FF mailing lists, and to


 about either of them there as well.

Thank you for the reply. I will wait patiently with some occasional prodding.

Do that. TTFN The Dr
Feb 02 2007