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
Musings of an STL-extension library designer (who's renowned for producing high-quality software with low-quality documentation).
Tuesday, September 30, 2008
Sunday, September 28, 2008
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.
Saturday, September 27, 2008
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:
This has all changed now, and all projects will eventually adopt the new form, which is:
- solo: e.g. the bc584 directory (for Borland C/C++ 5.84) contained the single makefile makefile
- multi-os, e.g. the gcc34 directory (for GCC 3.4) contained the makefiles makefile.unix (for UNIX) and makefile.win32 (for Windows)
- multi-arch, e.g. the vc8_x64 directory (for Visual C++ 8 (x64)) contained the makefile makefile (for 64-bit Windows)
This has all changed now, and all projects will eventually adopt the new form, which is:
- solo: e.g. the bc584 directory contains the single makefile makefile
- multi-os, e.g. the gcc34.unix directory contains the makefile makefile, and the gcc34.win32 contains the makefile makefile
- multi-arch, e.g. the vc8.x64 directory contains the makefile makefile
Friday, September 26, 2008
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 - 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
Thursday, September 25, 2008
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.
Monday, September 22, 2008
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:
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.
It might take a day or so to make it through DNS, but after that it should be sweet.
Monday, September 15, 2008
Defect in STLSoft's Windows Registry Library on 64-bit
One of STLSoft's users is reporting weird behaviour in the Windows Registry Library, when used on 64-bit Windows (x64).
It looks like the call to winstl::dl_call is defective, since x64 does not support different calling conventions.
I must confess I'd overlooked this potential issue - in part because I've still not got around to fully implementing the STLSoft internal automated testing harness - but I would still assume that the code would work, because the calling convention information, if any, would simply be ignored.
We're still looking into it. I'll post more when I know more ...
It looks like the call to winstl::dl_call is defective, since x64 does not support different calling conventions.
I must confess I'd overlooked this potential issue - in part because I've still not got around to fully implementing the STLSoft internal automated testing harness - but I would still assume that the code would work, because the calling convention information, if any, would simply be ignored.
We're still looking into it. I'll post more when I know more ...
VOLE 0.6.1 broken by bad STLSoft 1.9.53 - 1.9.54 now released
A VOLE user reported problems with compiling VOLE 0.6.1, which are a result of (i) my having released an incomplete STLSoft 1.9.53, and (ii) when using GCC, which does not define UDATE, some of WinSTL's conversion shims - specifically to_FILETIME(DATE const&) and to_SYSTEMTIME(DATE const&) - were not available.
Both issues are now fixed, with the recently released STLSoft 1.9.54.
Both issues are now fixed, with the recently released STLSoft 1.9.54.
Friday, September 12, 2008
VOLE 0.6.1 released
Thursday, September 11, 2008
FastFormat 0.2.1 (alpha 3) released
FastFormat 0.2.1 (alpha 3) is released.
It contains a fix to a defect in the implicit link header, and also a lot of groundwork for widestring support in the near future. (Actually, all the widestring support is now in the core library - just the makefiles, examples and tests need to be correspondingly updated.)
It contains a fix to a defect in the implicit link header, and also a lot of groundwork for widestring support in the near future. (Actually, all the widestring support is now in the core library - just the makefiles, examples and tests need to be correspondingly updated.)
Pantheios 1.0.1 (beta 156) released
Pantheios 1.0.1 beta 156 of is released.
It contains a revised naming convention for makefiles, such that every makefile is now in its
It contains a revised naming convention for makefiles, such that every makefile is now in its
own directory, and is called 'makefile'. The following examples
illustrate:
build/vc9/makefile => build/vc9/makefile
build/vc9_x64/makefile => build/vc9.x64/makefile
build/gcc34/makefile.win32 => build/gcc34.win32/makefile
build/gcc34/makefile.unix => build/gcc34.unix/makefile
build/gcc41/makefile.unix => build/gcc41.unix/makefile
etc.
Wednesday, September 10, 2008
Pantheios release, and new CodeProject article
Pantheios 1.0.1 (beta 155) is released.
Also, a new article on Pantheios' Back-end Architecture is published on CodeProject.
Also, a new article on Pantheios' Back-end Architecture is published on CodeProject.
STLSoft 1.9.52 released
Just a defect-fix release, to fixup some compiler warnings encountered on Win-64 compilation.
FastFormat is FAST: It's official!
I just posted some performance stats on the FastFormat website. I'll just give you the summary here:
- The Format API is faster than IOStreams by between ~140-730%, faster than MFC's
CString::Format()
by between ~300-400%, and faster than Boost.Format by between ~470-1600%! The only formatting API that gives it a run for some architecture/compiler/configurations issprintf()
, which is not type-safe, at between ~40-380%. (FastFormat's Format API is 100% type-safe.) - The simpler Write API is faster than IOStreams by between ~270-1350%, faster than MFC's
CString::Format()
by around ~420%, and faster than Boost.Format by between ~630-1800%! Again, the only formatting API that gives it a run for some architecture/compiler/configurations issprintf()
, at between ~65-390%. (FastFormat's Write API is 100% type-safe.)
Saturday, September 6, 2008
STLSoft 1.9.51 released
This latest release contains only two changes, but they're interesting nonetheless.
The first is a workaround for a defect in VC6. This was found in stlsoft::conversion_error, and comes about as follows. stlsoft::conversion_error is defined along the lines of:
class conversion_error_base
: public std::runtime_error
{
. . .
public: // Construction
virtual ~conversion_error_base() = 0;
. . .
};
class conversion_error
: public conversion_error_base
{
. . .
};
The highlighted line is the problem for VC++ 6. The code it generates is defective such that when an instance of any derived class is thrown, the exception does not get thrown, merely hangs about in the current scope, and the program execution carries on as if no exception was thrown.
The second change is a correction for a defect in the string access shim functions for the SYSTEMTIME type, whereby conversion of an invalid time resulted in a fault, because the calculation for the total length of the resultant string did not take account the fact that the Windows Time API functions returns 0 if the time instance is invalid. The consequence of fixing this defect has resulted in some nice refactoring, so there's some silver lining.
Coming soon: releases of VOLE, flecxx, Pantheios, and FastFormat.
The first is a workaround for a defect in VC6. This was found in stlsoft::conversion_error, and comes about as follows. stlsoft::conversion_error is defined along the lines of:
class conversion_error_base
: public std::runtime_error
{
. . .
public: // Construction
virtual ~conversion_error_base() = 0;
. . .
};
class conversion_error
: public conversion_error_base
{
. . .
};
The highlighted line is the problem for VC++ 6. The code it generates is defective such that when an instance of any derived class is thrown, the exception does not get thrown, merely hangs about in the current scope, and the program execution carries on as if no exception was thrown.
The second change is a correction for a defect in the string access shim functions for the SYSTEMTIME type, whereby conversion of an invalid time resulted in a fault, because the calculation for the total length of the resultant string did not take account the fact that the Windows Time API functions returns 0 if the time instance is invalid. The consequence of fixing this defect has resulted in some nice refactoring, so there's some silver lining.
Coming soon: releases of VOLE, flecxx, Pantheios, and FastFormat.
Wednesday, September 3, 2008
FastFormat is unleashed: v0.2.1 (alpha 1) released
FastFormat is an Open Source C/C++ Output/Formatting library, whose design parameters are 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.
FastFormat supports output/formatting of statements of arbitrary complexity, consisting of heterogeneous types.
FastFormat writes to output "sinks", which can be of arbitrary type. It implicitly supports any type that is structurally conformant with the standard library's string, and the library includes adaptors to allow writing to std::ostream, FILE*, speech (currently Windows-only), STLSoft's auto_buffer, C-style string buffers, and character buffers. Adaptation to a new type merely requires the definition of a single function.
FastFormat is fast. The processing of each statement involves at most one memory allocation to hold the entire statement, and each statement element is measured and copied exactly once. As a consequence, the library is on a par with (the type-unsafe) C's Streams (printf()-family) of functions, faster than C++'s IOStreams, and considerably faster than Boost.Format. Comprehensive performance analyses are underway; initial results of a realistic scenario on Windows (32-bit) with Visual C++ 9 shows FastFormat is approximately 3 x faster than C's Streams, 6 x faster than C++'s IOStreams, and 17 x faster than Boost.Format.
FastFormat supports I18N/L10N by using numbered arguments, enabling reordering of arguments by exchanging format strings. The library comes with a number of resource bundles, classes whose instances can load sets of localised resource strings for use as format strings.
FastFormat 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 Comeau (4.3.3+), GCC (3.4+), Intel (8+), Metrowerks (8+), Microsoft Visual C++ (6.0+), and should work with any reasonably modern C++ compiler.
FastFormat is completely free and includes source released under a BSD-style license. Commercial customisations and related consultancy are provided by Synesis Software Pty Ltd; http://synesis.com.au/contact.html)
Release 0.2.1 alpha 1 is the first public release.
Note: this release of FastFormat requires STLSoft 1.9.50, or later. Download from http://stlsoft.org/
Download from: http://sourceforge.net/project/showfiles.php?group_id=177382&package_id=204396
Discuss at: http://sourceforge.net/forum/forum.php?forum_id=612781
FastFormat website: http://fastformat.org/
FastFormat supports output/formatting of statements of arbitrary complexity, consisting of heterogeneous types.
FastFormat writes to output "sinks", which can be of arbitrary type. It implicitly supports any type that is structurally conformant with the standard library's string, and the library includes adaptors to allow writing to std::ostream, FILE*, speech (currently Windows-only), STLSoft's auto_buffer, C-style string buffers, and character buffers. Adaptation to a new type merely requires the definition of a single function.
FastFormat is fast. The processing of each statement involves at most one memory allocation to hold the entire statement, and each statement element is measured and copied exactly once. As a consequence, the library is on a par with (the type-unsafe) C's Streams (printf()-family) of functions, faster than C++'s IOStreams, and considerably faster than Boost.Format. Comprehensive performance analyses are underway; initial results of a realistic scenario on Windows (32-bit) with Visual C++ 9 shows FastFormat is approximately 3 x faster than C's Streams, 6 x faster than C++'s IOStreams, and 17 x faster than Boost.Format.
FastFormat supports I18N/L10N by using numbered arguments, enabling reordering of arguments by exchanging format strings. The library comes with a number of resource bundles, classes whose instances can load sets of localised resource strings for use as format strings.
FastFormat 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 Comeau (4.3.3+), GCC (3.4+), Intel (8+), Metrowerks (8+), Microsoft Visual C++ (6.0+), and should work with any reasonably modern C++ compiler.
FastFormat is completely free and includes source released under a BSD-style license. Commercial customisations and related consultancy are provided by Synesis Software Pty Ltd; http://synesis.com.au/contact.html)
Release 0.2.1 alpha 1 is the first public release.
Note: this release of FastFormat requires STLSoft 1.9.50, or later. Download from http://stlsoft.org/
Download from: http://sourceforge.net/project/showfiles.php?group_id=177382&package_id=204396
Discuss at: http://sourceforge.net/forum/forum.php?forum_id=612781
FastFormat website: http://fastformat.org/
Tuesday, September 2, 2008
When good compilers go BAD! A sorry tale of unhelpfulness from GCC
I've just added a new inserter class, w2m, to the world's fastest logging API library, Pantheios, in leiu of the widestring support that'll come in version 1.1+.
The initial implementation of the class uses STLSoft's auto_buffer, to be especially efficient in the case where the length of the string to be converted falls below a threshold - 64 in this case.
As with all other inserter classes, it does not provide copy semantics, neither copy constructor nor copy assignment operator.
All is well until I try to compile with GCC, which "helpfully" informs me that it can't generate a copy-constructor. (auto_buffer does not define a copy-constructor by design; you can read about why in section 16.2.3 of Extended STL, volume 1. Somewhat surprising that, given that I'd expressly told it not to try, by declaring, but not defining said copy constructor.
So, I've now got to spend a couple of hours implementing some custom memory management code to ensure portability. Great!
The initial implementation of the class uses STLSoft's auto_buffer, to be especially efficient in the case where the length of the string to be converted falls below a threshold - 64 in this case.
As with all other inserter classes, it does not provide copy semantics, neither copy constructor nor copy assignment operator.
All is well until I try to compile with GCC, which "helpfully" informs me that it can't generate a copy-constructor. (auto_buffer does not define a copy-constructor by design; you can read about why in section 16.2.3 of Extended STL, volume 1. Somewhat surprising that, given that I'd expressly told it not to try, by declaring, but not defining said copy constructor.
So, I've now got to spend a couple of hours implementing some custom memory management code to ensure portability. Great!
Monday, September 1, 2008
FastFormat about to drop ... and it's FAST!
I'm now less than two days away from releasing FastFormat. All that's left to do is:
std::string arg0 = "abc";
const char arg1[] = "def";
stlsoft::simple_string arg2 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
fastformat::fmt(s, "The first param '{0}', and the second '{1}', and the first again '{0}'. Finally the third '{2}'", arg0, arg1, arg2);
Note: this is for one compiler (VC++ 9), and one scenario (described above), so we can't draw any way-out conclusions as yet. But the first results are pretty encouraging to say the least:
IOStreams: 679561us
Boost.Format: 1901109us
sprintf(): 346776us
FastFormat: 112016us
IOStreams:FastFormat: 6.067
Boost.Format:FastFormat: 16.97
sprintf:FastFormat(): 3.096
These numbers mean that, for that scenario with that compiler, FastFormat is 3x faster than sprintf, 6x faster than the IOStreams, and 17x than Boost.Format.
Given that it's 100% type-safe, infinitely extensible, and supports I18N/L10N, I hope that it's going to be well received.
- verify on 64-bit Linux
- do the docs (a basic first cut; nothing mega good)
- try and find out why DMC++ does not like it (as usual, it's the odd-man-out with templates)
- do a decently comprehensive lot of performance tests
std::string arg0 = "abc";
const char arg1[] = "def";
stlsoft::simple_string arg2 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
fastformat::fmt(s, "The first param '{0}', and the second '{1}', and the first again '{0}'. Finally the third '{2}'", arg0, arg1, arg2);
Note: this is for one compiler (VC++ 9), and one scenario (described above), so we can't draw any way-out conclusions as yet. But the first results are pretty encouraging to say the least:
IOStreams: 679561us
Boost.Format: 1901109us
sprintf(): 346776us
FastFormat: 112016us
IOStreams:FastFormat: 6.067
Boost.Format:FastFormat: 16.97
sprintf:FastFormat(): 3.096
These numbers mean that, for that scenario with that compiler, FastFormat is 3x faster than sprintf, 6x faster than the IOStreams, and 17x than Boost.Format.
Given that it's 100% type-safe, infinitely extensible, and supports I18N/L10N, I hope that it's going to be well received.
Subscribe to:
Posts (Atom)