Pantheios 1.0.1 beta 198 released: new i and xi inserters

The latest release of Pantheios includes two new inserters, pantheios::i and pantheios::xi. The former is a typedef for the pantheios::integer inserter class, and may be used interchangeably with it:

  #include <pantheios/inserters/i.hpp>

  #include <pantheios/pan.hpp>

  int n = 10;

  pan::log_DEBUG("i=", pan::i(n));

  pan::log_DEBUG("i=", pan::i(n, -10));

  pan::log_DEBUG("i=", pan::i(n, -10, pan::fmt::hex));

produces the same output (and effectively the same binary) as:

  #include <pantheios/inserters/integer.hpp>

  #include <pantheios/pan.hpp>

  int n = 10;

  pan::log_DEBUG("i=", pan::integer(n));

  pan::log_DEBUG("i=", pan::integer(n, -10));

  pan::log_DEBUG("i=", pan::integer(n, -10, pan::fmt::hex));

The latter is actually a new class, and is used specifically for inserting integers in hexadecimal form, optionally specifying minimum width:

  #include <pantheios/inserters/xi.hpp>

  #include <pantheios/pan.hpp>

  int n = 16;

  pan::log_DEBUG("i=", pan::xi(n));

  pan::log_DEBUG("i=", pan::xi(n, -10));

The (hopefully obvious) advantage to both these new inserter types is that they're more succinct. There are more to come ...

Pantheios 1.0.1 beta 197 released: pantheios::integer inserter now more disciplined in width behaviour when hex formatting

The latest release of Pantheios provides substantial reworking of the pantheios::integer inserter class, including how it handles minimum-width specifiers when formatting in hex. Previously, as a statement such as

  #include <pantheios/inserters/integer.hpp>

  #include <pantheios/pan.hpp>

  int n = 0x13;
  pan::log_DEBUG("n=", pan::integer(n, 4, pan::fmt::hex));

would have resulted in the output of a line such as:

[old_int_hex.4312, 19/10/2010 7:38:53.062 AM; Debug]: n=  13

With the (surprisingly involved!) changes in 1.0.1 beta 197, the line produces output such as:

[old_int_hex.488, 19/10/2010 7:45:24.625 AM; Debug]: n=0x13

Note the absence of the two spaces - between n= and 13 - that were previously associated with expanding 13 to a minimum width of four. (Anyone who's used printf() can guess how that came about.)

Since these are only minimum widths, this change is unlikely to upset any log processing, but it's possible, so be advised.

Pantheios 1.0.1 beta 195 released: enhanced pantheios::w2m inserter

The latest release of Pantheios provides enhanced flexibility for the pantheios::w2m inserter class. As well as passing wide C-strings, as in:

  void f(wchar_t const* s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s), ")");

    . . .

  }

the new facilities allow passing wide string class instances, as in:

  void f(std::string const& s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s), ")");

    . . .

  }

and

  void f(stlsoft::simple_wstring const& s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s), ")");

    . . .

  }

Previously, the log statement would have to explicitly elicit the C-string pointer and the length, as in:

  void f(stlsoft::simple_wstring const& s)

  {

    pan::log_DEBUG("f(s=", pan::w2m(s.data(), s.length()), ")");

    . . .

  }

Obviously, this is far less expressive than the new facilities.

Pantheios 1.0.1 beta 194 released: new pantheios::slice inserter

The first update of Pantheios in six months, 1.0.1 (beta 194), has just been released. It contains various mods and fixes, but the main changes are:

• addition of the new pantheios::slice inserter
• widestring compatibility (of source, not yet of makefile build targets)

The slice inserter is for situations such as the following:

void fn(char const* str, size_t len)

{

  . . . 

In such a case, you cannot just pass str to a log statement, because that assumes it will be nul-terminated, and the semantics of fn() are clearly that it's not. In most circumstances you will get a benign overrun. But that is not guaranteed, and it's possible to get an access violation by overrunning into an invalid area of address space. (Imperfect C++ discusses ways in which this can happen.)

So, instead, use the new pantheios::slice inserter:

// assumes inclusion of pantheios/pan.hpp

// assumes inclusion of pantheios/inserter/slice.hpp

 

void fn(char const* str, size_t len)

{

  pan::log_DEBUG("fn(", pan::slice(str, len), ")");

  . . . 

Now only the requisite slice will be included.


But there's more to it than just that. I often use the convention of naming parameters when logging function entry, as in:

void fn2(std::string const& path1, std::string const& path2)

{

  pan::log_DEBUG(path1=", path1, ", path2=", path2, ")");

  . . . 

Obviously this is done explicitly, with names contained in the literal strings that are used to separate the function parameters in such cases. The question with pantheios::slice, then, is how we would achieve the same?


To accomodate this, pantheios::slice has several overloads that facilitate naming. Assuming str is "abcdefghijklm" and len is 5, consider the following examples:

void fn(char const* str, size_t len)

{

  // gives "fn(abcde)"

  pan::log_DEBUG("fn(", pan::slice(str, len), ")");

  // gives "fn(str=abcde, len=5)"

  pan::log_DEBUG("fn(", pan::slice(str, len, "str", "len"), ")");

  // gives "fn(s;abcde;l:5)"

  pan::log_DEBUG("fn(", pan::slice(str, len, "s", "l", ":", ";"), ")");

  . . .