Scoping MSVCRT memory tracking flags with scoped_handle

Am just working on some diagnostic extras to be provided as a side-project for Pantheios, with a particular focus on main(). In applying them to some of my system tool programs, I'm finding some false positive memory leaks being reported for FastFormat: this is because FastFormat caches parsed format strings, and they're not released until the library is uninitialised.

I want to "hide" these memory allocations from Visual C++'s CRT memory tracing functionality, and have found a neat little trick for doing so, using STLSoft's scoped_handle, as follows:


#if defined(_DEBUG) && \
    defined(STLSOFT_COMPILER_IS_MSVC)
    int prev = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
    _CrtSetDbgFlag(prev & ~_CRTDBG_ALLOC_MEM_DF);
    stlsoft::scoped_handle scoper(prev, _CrtSetDbgFlag);
#endif

    . . . // allocate memory that wont' be recorded as leaks

  } // MSVCRT settings reset here

Wide String Shims for std::exception

The latest release of STLSoft (1.9.102) includes wide string additions to the string access shims for std::exception (and derived types). The most obvious and immediate benefit is that code using FastFormat and/or Pantheios in wide string builds can now work seamlessly with exceptions, just as has always been the case in multibyte string builds:

#include <fastformat/ff.hpp>

. . .

#include <pantheios/pan.hpp>

. . . 

int main()

{

. . .

  catch(std::exception& x)

  {

    pan::log_CRITICAL(L"exception: ", x);

    ff::fmtln(std::wcerr, L"program: {0}", x);

  }

. . . 

VC++ 10 support imminent

Just added VC++ 10 support to STLSoft, and am proving it with builds of various dependent libraries, including FastFormat, Pantheios and recls. Should be available very soon (1-2 days).

LP64 and -Wshorten-64-to-32

Along with new Mac OS-X 64-bit makefiles for FastFormat and Pantheios, I'm also playing around with the -Wshorten-64-to-32 warning flag.

In compiling FF with this I encountered a lot of similars, amounting to the following:

enum { x = sizeof(Y) };

Obviously an enum, being int in size, is too small to hold size_t (the result of sizeof operator). The ugly but effective solution to this is:

enum { x = int(sizeof(Y)) };

which you'll now see more of in the STLSoft libs.

recls 1.9 alpha process begun

I've finally got around to enhancing the old stalwart, recls, which (if you don't know) is a platform-independent file-system recursive-search library.

So, far, I've finished a source-file renaming process that I started over a year ago, and now I'm having a go at the tracing functionality. This was formerly implemented in terms of syslog() on UNIX and OutputDebugString() on Windows. Now, as may be obvious if you follow STLSoft-related library news, I'm thinking it'll be implemented in terms of Pantheios.

The issue here, though, is that there should be no unnecessary coupling between libraries, and I think it would be wrong to couple recls to Pantheios just to provide good logging facilities. So the challenge will be to work out a way to allow the two to work together if required, and to not do so if not. Preprocessor options, function pointers, callbacks, and all manner of other ideas are under consideration.

I'll let you know how it goes. (And you'll be able to see it, as I'm planning to release recls 1.9 alpha 1 as soon as the logging is done.)

Radio silence ...

Having had a protracted break from STLSoft-related blogging, I'm back.

I've been busy with clients, and with various coding and writing projects, of which more in the coming posts.

I'll be attempting to post daily for the next few weeks, as I make my way through the following tasks:

• STLSoft 1.10 alpha releases
• recls 1.9 alpha release
• FastFormat 0.2 beta releases
• Pantheios 1.0 non-beta release
• xCover first release
• ... and other things I've currently forgotten
  

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.)

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).

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

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

   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.

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.

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!

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