STLSoft 1.10.1 (beta 10) released

The latest beta of STLSoft 1.10.1 is available, at https://github.com/synesissoftware/STLSoft-1.10/tree/beta-10.

Getting the beta

As usual, there are two ways to obtain the latest beta:

1. Select one of the release archives (.zip, .tar.gz) at https://github.com/synesissoftware/STLSoft-1.10/releases/tag/1.10.1-beta10; or
2. Clone the repo https://github.com/synesissoftware/STLSoft-1.10 and checkout the beta-10 branch (as in "$ git checkout -b beta-10 origin/beta-10").

Changes

The substantive changes are:

• winstl::process_mutex() now provides two additional ctor overloads that take an additional HANDLE parameter to pass an event that will be signalled in case of an ABANDONED wait, which should (almost) always be treated as a terminal condition. This means that crucial mutex instances may now be connected to a shutdown event;
• Special String Instances - those types generated by specialisations of stlsoft::special_string_instance_0 and stlsoft::special_string_instance_1 - are now automatically provided (in)equality operators: operator ==() and operator !=(). There are a bunch of such types, including (along with all their _a and _w variants):
• unixstl::current_directory;
• unixstl::home_directory;
• winstl::absolute_path;
• winstl::current_directory;
• winstl::home_directory;
• winstl::host_name;
• winstl::module_directory;
• winstl::module_filename;
• winstl::system_directory;
• winstl::temporary_directory;
• winstl::temporary_file_name;
• winstl::user_name; and
• winstl::windows_directory.

These will be explained below with a few short examples.

Examples

Process Mutex abandonment

The Old New Thing's "Understanding the consequences of WAIT_ABANDONED" explains the situation well, so I won't repeat here. I'll just include code from a component test for the new functionality in winstl::process_mutex():

    SECTION("waiting on an abandoned mutex with an event") {

        winstl::event         ev(true, false);

        winstl::process_mutex mx(L"my-mx", false, nullptr, ev.handle());

        CHECK(!mx.abandoned());

        std::thread thread([&] {

            mx.lock(); // acquire but don't release, then quit (=> abandon)

        });

        thread.join();

        CHECK(mx.try_lock()); // acquire, which notes the abandonment

        DWORD const r = ::WaitForSingleObject(ev.handle(), 0);

        CHECK(WAIT_OBJECT_0 == r);

        CHECK(mx.abandoned());

    }

FYI: we're changing over to using the Catch Unit-testing library for STLSoft 1.10. (Still currently using Catch v1, tho ...)

Special String Instance(s)

Simply, where (in)equality-comparison would previously have been manual tasks, as in:

  unixstl::current_directory cwd;

  if (0 == ::strcmp("/Users/matt/dev/STLSoft/Releases/1.10", cwd.c_str())

  {}

and

  winstl::current_directory cwd;

  if (0 != ::stricmp("C:\\Users\\matt\\dev\\STLSoft\\Releases\\1.10", cwd.c_str())

  {}

they are now provided with a natural syntax (due to internal use of String Access Shims):

  unixstl::current_directory cwd;

  if ("/Users/matt/dev/STLSoft/Releases/1.10" == cwd)

  {}

and

  winstl::current_directory cwd;

  if (cwd != "C:\\Users\\matt\\dev\\STLSoft\\Releases\\1.10")

  {}

Note that the case-sensitivity is handled automatically. Hence winstl::current_directory's specialising policy template now includes the member constant caseSensitive, which is now required by the special string instance class templates:

  template <typename C>

  struct cwd_policy

  {

    typedef C                         char_type;

    typedef processheap_allocator<C>  allocator_type;

    typedef size_t                    size_type;

    typedef size_type               (*pfn_type)(char_type *, size_type);

    enum { internalBufferSize       =   128 };

    enum { allowImplicitConversion  =   1   };

    enum { caseSensitive            =   0   };

    enum { sharedState              =   0   };

    static pfn_type get_fn()

    {

      return winstl::filesystem_traits::get_current_directory;

    }

  };

There's a further benefit in that the comparisons are all length-aware, so that (tiny) bit more efficient. Which is nice.

GitHub access

STLSoft GitHub access now at:

• STLSoft 1.9 - STLSoft 1.9 branch, now very old - venerable - and soon to be end-of-life;
• STLSoft 1.10 (delta) - the deltas-only 1.10 branch, which contains nuggets of what will become 1.12 in the coming months. Being an deltas-only, you need to install in conjunction with STLSoft 1.9, either with interpositioning or overlay.

Fork away!

STLSoft 1.9.121 released

Download from https://sourceforge.net/projects/stlsoft/files/

============================================================================


Changes for 1.9.121 (26th September 2015)


STLSoft:
========

~ stlsoft/conversion/char_conversions.hpp:
~ stlsoft/conversion/truncation_test.hpp:
+ stlsoft/internal/cccap/clang.h:
~ stlsoft/util/integral_printf_traits.hpp:
~ stlsoft/util/limit_traits.h:
~ stlsoft/util/std/iterator_helper.hpp:

+ Clang-compatibility


WinSTL:
=======

~ winstl/util/struct_initialisers.hpp:

~ VC++ 11/12/14 compatibility


============================================================================

Extended Radio Silence - ending in Q3 2012

To anyone who's still following any of my public works - FastFormat, Pantheios, STLSoft, Breaking Up The Monolith, Quality Matters, VOLE, etc. - and wondering whether these activities are permanently moribund, I want to let you know that I'll soon be free of a very intense and overwhelmingly consuming commercial engagement over the last 2.5 years, and the second half of this year should see much activity in open-source, commercial, and writing activities.

Cheers

Matt

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

  }

. . . 

Dealing with "deprecated" std::copy()

Although the issue of Microsoft having chosen, by the agency of its so-called "safe string" library, to deprecate large parts of the standard library in general, and std::copy() in particular, is hardly new, there's still some confusion in the community about what to do about it, and how to work around it if that's what you choose to do.

If, as I do on occasion, you choose not to suppress the warnings (by ignoring 4996, or by defining _SCL_SECURE_NO_WARNINGS) but instead want to ignore specifically for std::copy(), you can do it as follows:

#include <stlsoft/algorithms/std/alt.hpp>

#include <stlsoft/internal/safestr.h>

#if defined(STLSOFT_USING_SAFE_STR_FUNCTIONS) && \
    defined(STLSOFT_COMPILER_IS_MSVC)
namespace std
{
  using ::stlsoft::std_copy;
# define copy    std_copy
}
#endif // compiler

By all means it's breaking the rules and introducing names into the std namespace. Nonetheless, we can sleep easy, since, hey, we didn't start the undermining of the standard!

The other problem is that, currently, stlsoft::std_copy() has no specialisations. It always uses long-hand iteration; no memcpy()-based block copying for random access iterators to POD types.

I hope you know me well enough by now for this to not need to be said. But it's important enough for me to have to say it explicitly, just in case: do not use this technique in library headers!

STLSoft 1.9.98 changes to stlsoft::split()

As of STLSoft 1.9.98, stlsoft::split() has been enhanced to be able to split into between two and six fragments. Previously you would have use intermediates to split into more fields, as in:

std::string line = "abc|def|ghi|jkl";

stlsoft::string_view dummy1;

stlsoft::string_view dummy2;

stlsoft::string_view field0;

stlsoft::string_view field1;

stlsoft::string_view field2;

stlsoft::string_view field3;

if(stlsoft::split(line, '|', field0, dummy1) &&
   stlsoft::split(dummy1, '|', field1, dummy2) &&
   stlsoft::split(dummy2, '|', field2, field3))
{
  . . . // use fields
} 

Although there's no additional memory allocation here - because we're using string views as the intermediate and final fragment types - it's still hard to follow, and doing three separate split operations.

You can now split directly into up to six fields, as in:

std::string line = "abc|def|ghi|jkl";

stlsoft::string_view field0;

stlsoft::string_view field1;

stlsoft::string_view field2;

stlsoft::string_view field3;

if(stlsoft::split(line, '|', field0, field1, field2, field3))
{
  . . . // use fields
} 

It's marginally more efficient when using string views, and substantially more efficient when using string value types (such as std::string and stlsoft::simple_string). In either cases, it's considerably more transparent.

STLSoft 1.9.98 changes to stlsoft::read_line()

As of STLSoft 1.9.98, stlsoft::read_line() can now read from an iterator range of arbitrary type. Where formerly it would only work with a C Stream (i.e. FILE*), as in:

std::string line;

while(stlsoft::read_line(stdin, line

     , stlsoft::read_line_flags::recogniseAll))

{

  . . . // process line

}

Now it will also work with an iterator range of arbitrary type, as in:

platformstl::memory_mapped_file f("file.txt");

char const* const begin = static_cast(f.memory());

char const* const end = begin + f.size();

std::string line;

while(stlsoft::read_line(begin, end, line

     , stlsoft::read_line_flags::recogniseAll))

{

  . . . // process line

}

STLSoft 1.9.98 released

STLSoft 1.9.98 is released, containing a bunch of enhancements for 64-bit compatibility, and in anticipation of STLSoft 1.10. The two particular additions of interest are:

• stlsoft::split() can now split into more than two string fragments
• stlsoft::read_line() can now work with an iterator range of arbitrary type

STLSoft 1.9.96: Visual C++ support

The latest STLSoft now supports Visual C++ 10.

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

STLSoft 1.9.94: defective definition of swap() overloads for unixstl/winstl::memory_mapped_file corrected

As of version 1.9.94, the swap() free function overloads for unixstl::memory_mapped_file and winstl::memory_mapped_file are now declared inline, correcting a link-time error when linking multiple compilation units that use the component(s).