flecxx, FastFormat and other stuff ...

Well, the time has finally arrived, and I've got my shit together, and I am going to release either/both flecxx and FastFormat this weekend, or die in the effort.

The first thing will be to release STLSoft 1.9.43, as there're a few changes (mostly to do with reducing the clash with the "Safe String Library" with VC++ 8+) that're required for the current versions of the two libraries.

Then I'll be attempting to get the unit- and component-tests completed for them, putting together the distributions, and then letting them loose on the world.

For those who've not yet been exposed to the pitifully inadequate propaganda regarding these libraries, they can be summarised as follows:

flecxx is a very simple, lightweight (no runtime costs, and 100% header-only) library that removes abstraction dissonance. The classic example of abstraction dissonance in the C++ standard library is the pitiful requirement to invoke c_str() in order to allow std::string arguments to be passed to the constructors of std::[if]stream. This and many other vexing syntactic intrusions of leaking abstractions are handled by flecxx.

FastFormat is a much bigger chicken. It uses the Shims-based Type Tunneling also used by Pantheios (and which allows it to be at once 100% type-safe and orders of magnitude more efficient than any other logging libraries), and provides output/formatting to all types of things, including formatting strings, writing to stdout/cout, speech synthesis, logging, etc. etc. As well as very high speed, 100% type-safety (something that is not available with either the C standard library's printf() family or the C++ standard library's IOStreams!), extensibility, expressiveness and portability, FastFormat also offers support for I18N/L15N.

Consider the following examples:

std::cout& sink1 = std::cout;
std::string sink2;
stlsoft::simple_string sink3;

char const* arg0 = "cat";
std::string arg1("sat");
stlsoft::simple_string arg2("mat");

fastformat::fmt(sink1, "the {0} {1} on the {2}", arg0, arg1, arg2);
fastformat::fmt(sink2, "the {0} {1} on the {2}", arg0, arg1, arg2);
fastformat::fmt(sink3, "the {0} {1} on the {2}", arg0, arg1, arg2);

The example illustrates the use of three different sink types (std::cout, std::string, stlsoft::simple_string), and three different argument types (std::string, stlsoft::simple_string, C-style string), used in combination with each other.

The format strings in this example are all C-style strings. They can equally be any other string type, e.g.

std::string fmt1("the {0} {1} on the {2}");
stlsoft::simple_string fmt2("the {0} {1} on the {2}");

fastformat::fmt(sink3, fmt1, arg0, arg1, arg2);
fastformat::fmt(sink3, fmt2, arg0, arg1, arg2);

Because the format arguments are numbered, it is straightforward to support languages whose grammer require different ordering. Should we require the same logical string to render the arguments in a different order, we can do this easily:

fastformat::fmt(sink1, "on the {2} {1} the {0}", arg0, arg1, arg2);

This can be taken further, and in fact is taken further by the provision of resource bundles. The stock resource bundles provided by the library include Windows INI format, Properties File, and Record-JAR. Thus, I18N/L15N is easily supported by loading a locale-dependent resource bundle file, and looking up the formats by name, as in:

fastformat::properties_bundle bundle("GermanFormats.txt");

fastformat::fmt(sink1, bundle["cat-sat-fmt"], arg0, arg1, arg2);

In another post - hopefully after FastFormat has been released this coming w/e - I'll talk further about how to use it, and why it is so efficient.

1.9.38 - Win64 on its way

Ok, so we're still currently defining _CRT_SECURE_NO_DEPRECATE in the Pantheios VC8+ makefiles, but other than that, we're on for Win64-bit in several of the STLSoft-dependent libraries. So far, I've verified xTests, shwild and Pantheios on Win64. (Neither xTests nor shwild need to use _CRT_SECURE_NO_DEPRECATE in order to build correctly with VC8+.)

As for STLSoft itself, it's still pretty far from complete for Win64, but as each dependent library is moved across, more of STLSoft itself will be readied. As time goes by, I'm gradually reworking and improving the unit-/component-tests used on the library, and will be making sure that each test is compatible with Win64 building. Eventually, we'll get the whole thing across. ;-)