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*

{0}"
                    , arg0, arg1);

    // 3. via cout

                    , 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");

{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");




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




prod me

 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