b 196 imminent: full wide-string support

Title pretty much says it all. Am swamped - what's new - with commercial activities, but am hoping to get this out over the coming weekend.

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", ":", ";"), ")");

  . . .

LoadLibrary() and ERROR_NOACCESS

Further to my last post, if you muck up the initialisation and there's an access violation in your DLL, you'll likely see ERROR_NOACCESS from GetLastError() when LoadLibrary() fails.

Don't forget to initialise the library!

I'm doing some work for an overseas client at the moment, on a Windows DLL that provides access to their business logic to Excel. We're working on tightening up the implementation, ready for product release.

Most of the work so far has been porting between C/C++ compilers, but one of the other things I'm doing is adding diagnostic logging, via Pantheios of course.

As it's been several months since I've plugged Pantheios into a DLL I've forgotten the significant issues:

1. (By default) the Pantheios core is not initialised explicitly, meaning that DllMain() must call the functions pantheios_init() (if C) or pantheios::init() (if C++) to initialise the library (or handle the error and fail DllMain(), if it fails), and call pantheios_uninit() (if C) or pantheios::uninit() (if C++) to uninitialise (but only if the initialisation failed). (See instructions below for implicit initialisation in a DLL.)
2. Global object constructors must not invoke logging facilities

The first one's pretty straightforward. However, it's not always clear what the dependencies between types are, so the second may be impossible to achieve with certainty. If in doubt, I'd advise that you implicitly initialise Pantheios in the DLL:

• specify the pre-processor flag PANTHEIOS_FORCE_AUTO_INIT in your DLL's compilation
• have at least one C++ source file the DLL project includes pantheios/pantheios.hpp

Now accepting donations

Pantheios is production-quality software. If you find Pantheios useful, you are asked to make a modest donation, to ensure that the project continues to be supported and enhanced.

Radio Silence

Just a quick note to let all the diagnostic logging folks out there that the Pantheios project is alive and string, merely slumbering in the background while:

• the C++ library is finalised for release
• the C#/.NET library undergoes exhaustive testing in several serious commercial projects, before being released to the .NET world

I should have news on both fronts within the next few weeks, after which activity on this blog will ramp up significantly

Matt