Monday, November 8, 2010
Wide String Shims for std::exception
The new release of STLSoft supports seamless use of exceptions with FastFormat (and Pantheios) in wide-string builds; described on this post on the STLSoft project blog.
Labels:
exceptions,
FastFormat,
Pantheios,
STLSoft,
widestring
Thursday, October 14, 2010
fmt::flush
As discussed in the latest instalment of Quality Matters, having flushing output streams and verifying their status is a pre-requisite of writing a robust program. Doing this with the IOStreams is a somewhat onerous task; see the column for details. Using the new flush() function, introduced in version 0.6.2, makes doing so with FastFormat a breeze, as in:
#include <fastformat/ff.hpp>
#include <fastformat/sinks/ostream.hpp>
#include <iostream>
int main()
{
ff::flush(ff::writeln(std::cout, "Hello, world!"));
return 0;
}
#include <fastformat/ff.hpp>
#include <fastformat/sinks/ostream.hpp>
#include <iostream>
int main()
{
ff::flush(ff::writeln(std::cout, "Hello, world!"));
return 0;
}
FastFormat 0.6.2 released
I've just released version 0.6.2 of FastFormat, containing a number of improvements and several new features, which will be detailed in a series of forthcoming posts on this blog. The new features include the flush() function, whose purpose and behaviour is described in the latest instalment of my Quality Matters column in October's instalment of ACCU's Overload.
Labels:
0.6,
ACCU,
FastFormat,
flush,
Overload,
Quality Matters
Wednesday, June 23, 2010
FastFormat 0.6.1 (alpha 1) released
I'm currently releasing version 0.6.1 (alpha 1) of FastFormat. Although 0.6 will contain a number of new additions, the first alpha release contains no functional changes. It's entirely about releasing some performance improvements that I've had in the bag for a long time, but keep overlooking.
The reason I'm doing so now is, in part, that there's been a thread on the FastFormat Help Forum concerning one potential user's assertion that FastFormat (and some of the STLSoft components upon which it relies) is not as quick as my previous claims have indicated. Thankfully, it was easy to perform some simple tests and ascertain that, so far, nothing's overtaken it in terms of performance. In one of the tests I added FastFormat (both write() and fmt()) and STLSoft's integer_to_string to an integer-to-string conversion test that included, amongst other things, Boost.Spirit.Karma. I'm pleased to report - with Visual C++ 9, at least (haven't had time to use other compilers yet) - that FastFormat holds its own, and with the new optimisations in 0.6 it is the fastest of the possible format components, including ~10% faster than Karma.
The only thing faster is the low-level stlsoft::integer_to_string() function that FastFormat uses internally, which is a good 30-40% faster than the rest. (Not that I'd advocate using it in application code, of course, since it's not so expressive, and requires pointer and buffer-length parameters.)
I owe thanks to the OP for causing me to look again and confirm FastFormat's performance advantages, and to release the long-awaited optimisations.
The reason I'm doing so now is, in part, that there's been a thread on the FastFormat Help Forum concerning one potential user's assertion that FastFormat (and some of the STLSoft components upon which it relies) is not as quick as my previous claims have indicated. Thankfully, it was easy to perform some simple tests and ascertain that, so far, nothing's overtaken it in terms of performance. In one of the tests I added FastFormat (both write() and fmt()) and STLSoft's integer_to_string to an integer-to-string conversion test that included, amongst other things, Boost.Spirit.Karma. I'm pleased to report - with Visual C++ 9, at least (haven't had time to use other compilers yet) - that FastFormat holds its own, and with the new optimisations in 0.6 it is the fastest of the possible format components, including ~10% faster than Karma.
The only thing faster is the low-level stlsoft::integer_to_string() function that FastFormat uses internally, which is a good 30-40% faster than the rest. (Not that I'd advocate using it in application code, of course, since it's not so expressive, and requires pointer and buffer-length parameters.)
I owe thanks to the OP for causing me to look again and confirm FastFormat's performance advantages, and to release the long-awaited optimisations.
Sunday, June 6, 2010
FastFormat 0.5.8 released
FastFormat 0.5.8 is released, containing a fix to ensure that a replacement parameter with a maximum width of 0 truncates (completely) the resulting field. For example:
string_t sink;
ff::fmt(sink, "{0,,0}", "abc");
assert("" == sink);
string_t sink;
ff::fmt(sink, "{0,,0}", "abc");
assert("" == sink);
Wednesday, June 2, 2010
format_iterator on Dr Dobb's
Dr. Dobb's have just published a new article, "C++ and format_iterator", describing the design and implementation of the FastFormat library's format_iterator component.
The article describes how FastFormat's flexiblity, expressiveness and type-safety has been combined with the output iterator concept to produce the fastformat::format_iterator component. Applying STL-extension techniques described in Extended STL, volume 1, the format_iterator() component is able to create an output iterator that can receive arbitrate types, apply a format string or arbitrary complexity, and write to an arbitrary sink, as in:
#include <fastformat/ff.hpp>
#include <fastformat/iterators/format_iterator.hpp>
#include <fastformat/sinks/ostream.hpp>
int numbers[] = { -2, -1, 0, 1, 2 };
char const* strings[] = { "abc", "def", "ghi" };
std::string prefix = "\t";
char const* suffix = "\n";
std::copy(
numbers, numbers + 5
, ff::format_iterator(std::cout, "[{0}]"));
// outputs "[-2][-1][0][1][2]"
std::copy(
strings, strings + 3
, ff::format_iterator(std::cout, "{1}'{0}'{2}", prefix, suffix));
// outputs:
// 'abc'
// 'def'
// 'ghi'
This is the fourth article on the FastFormat library, following on from the introductory series of three published in ACCU's Overload magazine:
The article describes how FastFormat's flexiblity, expressiveness and type-safety has been combined with the output iterator concept to produce the fastformat::format_iterator component. Applying STL-extension techniques described in Extended STL, volume 1, the format_iterator() component is able to create an output iterator that can receive arbitrate types, apply a format string or arbitrary complexity, and write to an arbitrary sink, as in:
#include <fastformat/ff.hpp>
#include <fastformat/iterators/format_iterator.hpp>
#include <fastformat/sinks/ostream.hpp>
int numbers[] = { -2, -1, 0, 1, 2 };
char const* strings[] = { "abc", "def", "ghi" };
std::string prefix = "\t";
char const* suffix = "\n";
std::copy(
numbers, numbers + 5
, ff::format_iterator(std::cout, "[{0}]"));
// outputs "[-2][-1][0][1][2]"
std::copy(
strings, strings + 3
, ff::format_iterator(std::cout, "{1}'{0}'{2}", prefix, suffix));
// outputs:
// 'abc'
// 'def'
// 'ghi'
This is the fourth article on the FastFormat library, following on from the introductory series of three published in ACCU's Overload magazine:
Labels:
ACCU,
article,
DDJ,
Dr. Dobb's,
FastFormat,
format_iterator,
Overload
Wednesday, May 12, 2010
Beware of the \r\n gotcha on Windows
If (as I have just done) you decide to FastFormat to prepare intermediate text for output, and your program runs on Windows, beware of the writeln() and fmtln() API functions. Consider the following code
This occurs because the underlying C standard library expands each standard end-of-line (EOL) character \n to the Windows-specific EOL sequence \r\n.
Instead, use the *ln() functions on the output, as in:
std::string s;
ff::writeln(s, "hello"); // s => "hello\r\n"
ff::write(std::cout, s); // writes "hello\r\r\n"
This occurs because the underlying C standard library expands each standard end-of-line (EOL) character \n to the Windows-specific EOL sequence \r\n.
Instead, use the *ln() functions on the output, as in:
ff::write(s, "hello"); // s => "hello"
ff::writeln(std::cout, s); // writes "hello\r\n"
Subscribe to:
Posts (Atom)