... FastFormat?

For those long-suffering waitees for the long-promised revolution in string formatting that is FastFormat, I promise that the wait won't be much longer. I've got a few things on my plate over the next few days, and then FF is top of the list. All that's left to do is sort out a few distro issues, and tidy up the docs, and we're ready to rock and roll. (At least for an alpha version, anyway.)

CMake; Pantheios

I just received my recently-ordered copy of "Mastering CMake" (Martin & Hoffman), and plan to make good use of it next week, as I investigate options in reducing the management overhead of my various open-source libraries.

If anyone's got any useful experience, I'd be glad to hear it.

I'll let you know how it goes

Matt

btw, the latest release of Pantheios, 1.0.1 beta 152, contains the long-requested feature of a source-only distribution, cutting download size for people who prefer to get the docs online from ~4.8 MB to ~2.5.

Pantheios 1.0.1 (beta 150) released

Pantheios is an Open Source C/C++ Logging API library, offering an optimal combination of 100% type-safety, efficiency, genericity and extensibility. It is simple to use and extend, highly-portable (platform and compiler-independent) and, best of all, it upholds
the C tradition of you only pay for what you use.

Pantheios supports logging of message statements of arbitrary complexity, consisting of heterogeneous types.

Pantheios supports filtering of log messages based on severity level including (but not limited to) the eight levels defined by the SysLog protocol.

Pantheios supports back-end output, individually and in combination, to stderr/stdout, SysLog (including a custom implementation of the SysLog protocol for Windows), Windows debugger, Windows event log, COM Error Object, Speech, or any custom back-end extension you care to write. Importantly, Pantheios is readily extended to use the existing transport mechanisms of feature-rich logging libraries such as ACE, log4cpp, log4cplus, log4cxx.

Pantheios does not contain any compiler-specific or platform-specific constructs. It supports UNIX (including Linux and Mac OS-X), and Windows, and should work with any operating system. It is known to be compatible with Borland (5.5.1+), Comeau (4.3.3+), Digital Mars (8.45+), GCC (3.2+), Intel (6+), Metrowerks (8+), Microsoft Visual C++ (5.0+), and should work with any reasonably modern C++ compiler.

Pantheios is completely free and includes source released under a BSD-style license. Commercial customisations (of front-/back-ends are provided by Synesis Software Pty Ltd; http://synesis.com.au/contact.html)

Release 1.0.1 beta 150 incorporates:
* fixed defect in fe.N, whereby a negative catch-all severity ceiling would not be respected
* other minor adjustments/improvements to fe.N
* added unit-test for fe.N
* bundles xTests 0.8.5
* NOTE: Now requires STLSoft 1.9.48
* NOTE: These are breaking changes. Any code using the extant fe.N front-end library will need to be edited and re-compiled

Note: this release of Pantheios requires STLSoft 1.9.48, or later.

Download from: http://sourceforge.net/project/showfiles.php?group_id=141831&package_id=155759

Discuss at: http://sourceforge.net/forum/forum.php?forum_id=475313

VOLE 0.5.1 released

Version 0.5.1 of VOLE released.

Changes:

• renamed coercion level nonDestructiveTruncation to nonDestructiveCoercion
• added com_return_traits<float>
• added com_return_traits<double>
• changed behaviour for com_return_traits<bool>, com_return_traits<short>, com_return_traits<int>, com_return_traits<long>, com_return_traits<std::string> and com_return_traits<std::wstring>
• added test.unit.return_traits.builtins
• added test.unit.return_traits.std_types

xTests 0.8.5 released

Version 0.8.5 of xTests released.

Changes:

• added call to XTESTS_TEST_PASSED() when an expected exception is received
• added more integer specialisations of xtests_failure_reporter<>
• fixed a defect in the approximate comparison of negative floating-point numbers

1.9.48 released

Just released 1.9.48, which contains an essentail fix to stlsoft::trim_all(), and a number of additions to COMSTL.

The language that never ends ...

It has been said (alas, a reference escapes me at this time) that nobody can know all of C++.

Well, today I've just had another proof of it (not that I ever thought I knew all the language). Question: what's wrong with the following code?

  bool fn()
  {
    void* p = 0;

    return p;
  }

Answer: absolutely nothing. Yes, that's right, you can convert an "rvalue of arithmetic, enumeration, pointer, or pointer-to-member type" to an rvalue of type bool(C++ Standard: 4.12.)

Who'd a thought it?!

I found upon this because I'm changing the way some of the type conversions work in VOLE as part of the new functionality of version 0.5. As well as adding specialisations of vole::com_return_traits<> for float and double, I'm adding comprehensive (i.e. a cartesian product of from-type, to-type and coercion level) unit-tests for the builtins' specialisations. I thought that com_return_traits<bool> was too permissive, in allowing any of the basic integral types to be converted when the coercion level is naturalPromotion. Turns out I was wrong!

makefiles and build directories

Further to a recent blog post, about object library naming conventions, there's also some debate about the makefile naming and build directory structure. Historically, there have been three main forms of build-dir+makefile-naming with most STLSoft-dependent libraries:

1. solo: e.g. the bc584 directory (for Borland C/C++ 5.84) contained the single makefile makefile
2. multi-os, e.g. the gcc34 directory (for GCC 3.4) contained the makefiles makefile.unix (for UNIX) and makefile.win32 (for Windows)
3. multi-arch, e.g. the vc8_x64 directory (for Visual C++ 8 (x64)) contained the makefile makefile (for 64-bit Windows)

Obviously, there's a degree of inconsistency there. Furthermore, using the multi-os form was a pain because it meant having to explictly write 'make -f makefile.unix' (or equivalent), rather than just make.

This has all changed now, and all projects will eventually adopt the new form, which is:

1. solo: e.g. the bc584 directory contains the single makefile makefile
2. multi-os, e.g. the gcc34.unix directory contains the makefile makefile, and the gcc34.win32 contains the makefile makefile
3. multi-arch, e.g. the vc8.x64 directory contains the makefile makefile
   

Synesis Software Object Library Naming Conventions explained ... I think

I'm writing up some docs as part of the seemingly never-ending process of getting Pantheios ready for its 1.0 final release. Part of this is documenting the object library naming conventions.

For a given Synesis Software project (Pantheios, FastFormat, UNIXEm, shwild, etc.), the object libraries are named according to the following convention:

  [lib]<library-name>.<major-version>.<module-name>
  .<compiler-name>[.<os-arch-tag>]
  [.<threading-tag>][.<nox-tag>][.<debug-tag>].{a|lib}

Some examples might help.

For the Pantheios core library for VC++ 9 in DLL configuration and debug mode the library name would be:

  pantheios.1.core.vc9.dll.debug.lib

For the Pantheios core library for GCC 4.2 in multithreaded configuration on UNIX the library name would be:

  libpantheios.1.core.gcc42.mt.a

So far so good. Let's jazz it up a little. Consider the NoX - No eXception - builds, which are usually only provided for VC++ 6. Let's say we now want a NoX build of the single-threaded VC debug object library:

  pantheios.1.core.vc6.nox.debug.lib

And the multithreaded (non-DLL) version:

  pantheios.1.core.vc6.mt.nox.debug.lib

Where this starts to fall down is in two ways: when emulating UNIX builds on Windows, and when defining x64 builds of UNIX. For a first example, let's look at the UNIX-emulation, non-NoX variant of the last VC 6 one:

  pantheios.1.core.vc6.unix.mt.debug.lib

Even this has a certain consistency about it. But where it currently really starts to fall down is with the 64-bit Windows versions of things. Consider an x64 version of the VC 9 configuration. It is currently:

  pantheios.1.core.vc9_x64.mt.debug.lib

Ideally this should be changed to:

  pantheios.1.core.vc9.x64.mt.debug.lib

But then if we're emulating 64-bit UNIX on x64, how would we represent this? Would it be:

  pantheios.1.core.vc9.unix.x64.mt.debug.lib

or:

  pantheios.1.core.vc9.x64.unix.mt.debug.lib

or:

  pantheios.1.core.vc9.unix_x64.mt.debug.lib

I'm keen to get some external opinions on this, as the inconsistency can't stand, but making such changes now will be significant.

The other aspect of this issue is that all the changes to all Synesis libraries will have to be made pretty much at once. This is sticky stuff ...

2008's the year for STLSoft

And as part of that effort I'll be attempting to do daily blogs on the subject. This being the first (and least informative).

In the last couple of days I've transferred the unit-tests for stlsoft::auto_buffer and stlsoft::frequency_map to the new unit-testing framework (using xTests). I'm hoping to do move at least one component under test each day, until they're all done.

1.9.46 released

This takes into account fixes to defects in stlsoft::pod_vector, and a few other sundry issues.

The next release, due out tomorrow, will incorporate application of parentheses in contract enforcement statements that are currently confusing GCC 4.3.

I'm hoping that there'll be a change of packaging in 1.9.48, within the next week or so.

Back from holiday: Aug=>Dec 08 plans

My family and I were in Europe visiting friends and family from late June to late July, and I have been catching up with things, mostly commercial, since we got back, so there's not been a lot happening with STLSoft and the other libraries. (I have, of course, cranked out a few more beta releases of Pantheios ...)


Now we're back, I have work sketched out for the rest of the year on four fronts:

• commercial activities:
  
• I'm helping a client rescue and move forward a C++/COM codebase that's been going for 12+ years. This is a huge challenge, but I think we're going to have a lot of fun
• I'm also taking on a few more commercial customisations of Pantheios
• writing:
• books: "Breaking Up The Monolith" will be getting a big lot of time in Sept and onwards, with the intent to finish it before the end of the year; am also starting a couple of other, less demanding, books
  
• articles: I'm planning to get back to writing articles, hopefully for DDJ, ACCU, and others, this year
• libraries:
• Pantheios - get it out of beta, and on the 1.1, 1.2, 1.3 development track; nearly there, honest!
• FastFormat - release the first public alpha before the end of this month
• xContract and xCover - release first public alphas soon
• STLSoft - get 1.10 out, including better distributions (incl. new unit-testing facilities), and docs
• websites
• need to get the Synesis Software website redone - it's not exactly full of wow! at the moment. ;-)
• Pantheios site has been redesigned, and just needs replacing
• STLSoft website: intention here is to have docs, articles, blogs (not just for me), and other stuff

So, that's a list of my modest ambitions for the remainder of 2008. Wish me luck!