Matthew Wilson 
Posted in reply to Bart van der Velden
| 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.
|
Permalink
Reply
