Using STLSoft 1.10 alpha (delta) releases

Just a quick remark on the strategy for STLSoft 1.10. Essentially, the alpha releases will be forthcoming over the next few months, as components are moved over (and given the treatment) from the 1.9 branch, and new components are added. Each of these alpha releases is in the form of a delta-only distribution, meaning that you will have to first install STLSoft 1.9, and then either:

• Install the STLSoft 1.10 distribution over the top of the 1.9 installation, or
• Install STLSoft 1.10 to a separate area and then use include paths to cause your compiler(s) to see the 1.10 alpha files first

We do the latter, by:

1. Defining an STLSOFT environment variable pointing to the 1.9 distro root directory
2. Defining an STLSOFT_1_10 environment variable pointing to the 1.10 distro
3. Specifying the latter before the former to the compiler, as in "g++ -I$STLSOFT_1_10/include -I$STLSOFT/include my_file.cpp"

STLSoft 1.10 new additions: string_to_integer

Having not posted for over a month, there's a lot to catch up on.

I'm going to start with a series of short missives on the latest additions to STLSoft 1.10. (See this for how to install/use 1.10 alpha (delta) releases.) While I'm catching up with the releases, it's probably not going to go in order, so you'll have to be bear with me.

I'll start today with the new stlsoft::string_to_integer() functions, defined in the new include file stlsoft/conversion/string_to_integer.hpp. These are low-level string->number parsing functions. Their raison d'etre is performance - they'll be used in the forthcoming FastFormat 0.3 version, for high-speed parsing of replacement parameters - and for this they sacrifice some functionality, as discussed below.

They look like the following:

namespace stlsoft
{
int string_to_integer(char const* s, char const** endptr);
int string_to_integer(wchar_t const* s, wchar_t const** endptr);
int string_to_integer(char const* s, size_t len, char const** endptr);
int string_to_integer(wchar_t const* s, size_t len, wchar_t const** endptr);
} // namespace stlsoft

The functions in the first pair take a (non-NULL) pointer to a (nul-terminated) C-style string, along with an optional (may be NULL) pointer to pointer to C-style string, which will receive the pointer to the character terminating the parsing. In this aspect, these functions ape the functionality of the standard strtol() function. However, where they differ is that they do not accept a radix parameter: currently all conversion is decimal.

The second pair do not require nul-terminated strings, and instead use a length parameter. This is useful when parsing numbers out of string types that may not be null-terminated. (Again, this is found in FastFormat, which is the main driver for the release of these functions.)

These functions are very new, and will evolve further before STLSoft 1.10 beta. Three changes that are candidates to be introduced are:

• Supporting different radixes (although for radixes not in [8, 10, 16] it may be that they'd defer to strtol()).
• Support for different integer types. In fact, the four concrete functions are implemented in terms of two function templates whose integral type is a template parameter, so the groundwork is all there
• Support for truncation testing.

I'd like to hear from anyone on these, or other, features.

I'll do some specific performance tests on the functions at a later time. They've had some exposure as part of a larger performance test of the forthcoming FastFormat 0.3's new functionality, and have shown to confer a benefit over strtol() and its siblings.

Pantheios 1.0 countdown ... what do you want to see?

I'm on the home straight with the Pantheios 1.0 final (non-beta) release. I've started a discussion thread on the Pantheios Open Discussion forum to garner opinion from current (and future!) users as to what features should make it into 1.0 (and what will have to wait until future versions).

I'm very happy to hear contributions, so please give me your opinions.

Thanks

Release early, release often; FastFormat 0.2.1 (alpha 4)

The value of the open-source adage to "release early, release often" has shown itself once again, this time with respect to the FastFormat library. There are a large number of things to go into this library on its progress from 0.2 onwards, but it's been stuck for a month waiting for me to get my act together. Part of the delay is due to the fact that I let too many changes creep in, which complicates the testing and the formulation of the distribution (incl. just listing the changes).

So, I've just released 0.2.1 (alpha 4), which is a sound base for the future releases. It incorporates various minor fixes and adjustments, and a wholesale refactoring of the contract enforcement API. (An analogous refactoring has also been done for Pantheios, and is available in its latest release.)

STLSoft 1.10 coming: Contracts, Coverage, TR1, new components

It's been two years in the making, but the STLSoft 1.10 branch is finally about to begin showing its face to the world. There are a number of important new features to be introduced to the libraries, and we've reached the point where the 1.9 branch won't take more new features being stuffed into it.

Initially, the new branch will be presented as a series of "alpha delta" releases, each of which will rely on the 1.9 branch being visible in the include path (after 1.10, of course, to allow source interpositioning). That's largely because the task of bringing over all the 1.9 components at once is just too daunting.

So what's going to be new in 1.10? Well, that's a hard question to answer, largely because 1.10 is not likely to come out of alpha until 2009. However, there are some aspects that are already certain to go in:

• Improved contract enforcement support, separating out the different aspects of Contract Programming. Users will have the option to use xContract, the current assert()-based enforcement approach, or any other contract enforcement library they choose. (That xContract is itself implemented in terms of STLSoft confers a little complexity, but this will be handled by the separate compilation of the two libaries: in the compilation of xTests, STLSoft's contracts will be the old assert()-based ones.)
  
• Code coverage. This is in its infancy because the library it will use, xCover, is as yet unreleased
  
• Properties File library. This will provide full support for the Java Properties file format, with the usual high-performance tweaks (incl. memory mapping and string views)
• Reworking of all the per-compiler feature discrimination. Some early hints of how this will work are to be found in msvc.h and gcc.h
• TR1 components, to facilitate migration to these new components
  
• and lots more ... including user-requested functionality, so please get your requests in now.

If anyone wants to offer help in this marathon effort, you'll be spectacularly welcome.

Busy times; Pantheios.COM release

Things are really busy at the moment, what with my current commercial client and doing a fair chunk of the writing commitments that I've been dodging for much of this year.

I'm committed to writing 8 articles over the next year, about things to do with Monolith (FastFormat, Pantheios, Type-tunneling, Shims, and so on).

But in the meantime things are progressing on the libraries. Today I've released a new version of Pantheios.COM, which fixes incompatibility with early-binding automation clients (such as Visual Basic and Delphi).

STLSoft site moved to SourceForge

As part of the movement of STLSoft over to SourceForge, I've just put in the DNS changes. Expect a few hiccups in the next few hours, as the DNS record updates are rolled out, after which the new site should be available.

Please visit the site, http://stlsoft.org/, and provide feedback on the services/content provided there.

Also, please feel free to make use of the forums and the trackers. These will be preferred over this newsgroup, or direct emails, from this point onwards for keeping track of bugs, feature requests, tutorial questions, and so forth.

Matt

New library: xContract 0.3.3 released

xContract is a contract enforcement library for C and C++, written in C. Its notable features are:

• Phase Separation. It supports the separation of the three phases of contract enforcement: detection, reporting and response. Detection is achieved by simple boolean condition evaluation. Reporting is achieved via a callback function, either the stock xContract_violationReport() function, or one supplied by the user. Response is to terminate the process.
• The Principle of Irrecoverability. If the reporting receiver does not cause the process to terminate, then the library will always do so.
• The Principle of Removability. Enforcements may be enabled/disabled either at compile-time or at runtime according to the choices of the programmer
• Portability. It relies on no platform-specific or compiler-specific constructs. The only library it relies on is the 100% header-only, open-source STLSoft library. It works with a large number of C/C++ compilers.

xContract is the second of a triumvirate of C/C++ software quality assurance libraries provided by Synesis Software. The first library, xTests, is an automated testing library. The third, as yet unreleased, library, xCover, is an automated code coverage library.

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
   

New Libraries coming ...

Commercial and publishing reasons are forcing me to do what I should have done a *long* time ago, and release several pending libraries in the coming days:
* xContract - a contract programming enforcement library; initially for C/C++
* xCover - a code coverage library for C and C++
* FastFormat - already available as an alpha, this will hit the non-alpha/non-beta status in the coming days; as the name implies, it's faster than all the competition put together ;-)
* Pantheios - in beta (and very popular) for two years, the world's fastest and most robust logging API library has waited long enough for a final 1.0 release.

Also, STLSoft is going to be moving to SourceForge in the next week or so, and it too will receive a face lift and an update to docs, tests, and so on.

If anyone wants to volunteer any help for any of these activities, you'd be extraordinarily welcome.

Cheers

Matt

xContract released

xContract is a contract enforcement library for C and C++, written in C. Its notable features are:

• Phase Separation. It supports the separation of the three phases of contract enforcement: detection, reporting and response. Detection is achieved by simple boolean condition evaluation. Reporting is achieved via a callback function, either the stock xContract_violationReport() function, or one supplied by the user. Response is to terminate the process.
• The Principle of Irrecoverability. If the reporting receiver does not cause the process to terminate, then the library will always do so.
• The Principle of Removability. Enforcements may be enabled/disabled either at compile-time or at runtime according to the choices of the programmer
• Portability. It relies on no platform-specific or compiler-specific constructs. The only library it relies on is the 100% header-only, open-source STLSoft library. It works with a large number of C/C++ compilers.

xContract is the second of a triumvirate of C/C++ software quality assurance libraries provided by Synesis Software. The first library, xTests, is an automated testing library. The third, as yet unreleased, library, xCover, is an automated code coverage library.

STLSoft moving to SourceForge

I've finally got myself together, and am moving STLSoft from the Synesis Software site to SourceForge.

Over the coming months you can expect to see the following changes:

• The distributions available solely from SF
  
• The stlsoft.org domain will be hosted on SF
• A wiki will be configured and built up
• Subversion repository (but not before 1.10 is released, and a whole lot of TODOs are TODONE)
• Blogs will be added
• Forums will be added

Moving blog to its own domain

Exactly what's said on the tin: I'm moving the blog to http://stlsoft-musings.net/

It might take a day or so to make it through DNS, but after that it should be sweet.