Tuesday, December 28, 2010

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

Monday, November 8, 2010

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

Tuesday, June 22, 2010

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!

Sunday, June 6, 2010

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:

Monday, March 8, 2010

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

Thursday, March 4, 2010

Monday, February 15, 2010

STLSoft 1.9.93: STLSOFT_CF_NAMESPACE_SUPPORT now only in C++ compilation units

As of version 1.9.93, the symbol STLSOFT_CF_NAMESPACE_SUPPORT is now defined only in C++ compilation units. Its (former) definition in C compilation units was meaningless, and put client code to more work, discrimination for STLSOFT_CF_NAMESPACE_SUPPORT and for __cplusplus. Now the former encapsulates both.

Thursday, February 11, 2010

STLSoft 1.9.92: inetstl::filesystem_traits::is_path_name_separator() added

As of version 1.9.92, inetstl::filesystem_traits now has an is_path_name_separator(), to ensure correct handle of paths that contain network ('/') and local ('\\') path name separators.

Tuesday, February 2, 2010

Thursday, January 21, 2010

STLSoft 1.9.90: unixstl::filesystem_traits::get_full_path_name() defect fixed

Prior to version 1.9.90, unixstl::filesystem_traits::get_full_path_name() contained a defect, causing it to fault if passed "." - indicating the local directory - and instead contain spurious information. This is now fixed.

Tuesday, January 12, 2010

STLSoft 1.9.88: fixed conversion between const_reverse_iterator and reverse_iterator

For a long while, I've been aware of the limitations of the reverse iterator abstraction components in the STLSoft libraries - specifically  and  - which prevent assigning an instance of a collection's reverse_iterator to an instance of its const_reverse_iterator. This has caused trouble for me on occasion, and also for some users.

As of version 1.9.88 this has been addressed, via addition of conversion constructor template and operator != templates.

STLSoft 1.9.88: throwOnAccessFailure search flag for winstl::basic_findfile_sequence

As anticipated, winstl::basic_findfile_sequence, which is described in detail in Extended STL, volume 1, now defines, and responds to, the member constant throwOnAccessFailure. In the case of an access failure an instance of winstl::access_exception is thrown.

This allows for better response in cases where access may be denied.

STLSoft 1.9.88: max_size() for file_path_buffer and path

As of version 1.9.88, winstl::basic_file_path_buffer now has a (static) max_size() method, and winstl::basic_path::max_size() is changed to be static.

STLSoft 1.9.88: all-integer handling for comstl::variant

The latest release (1.9.88) of STLSoft contains an updated comstl::variant class. The previous version had three constructors for integer types: short, int and long. The new version has six constructors for integer types: sint8_t, uint8_t, sint16_t, uint16_t, sint32_t, uint32_t. (It also has short, int and long constructors for those compilers that have distinct types against the 8/16/32-fixed integer types; see chapter 29 of Imperfect C++)

Monday, January 11, 2010