Re: [boost] loglite - A logging library (JD)

Subject: Re: [boost] loglite - A logging library (JD)
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-01 02:28:25

On Thu, Oct 29, 2009 at 11:28 AM, Emil Dotchevski
<emildotchevski_at_[hidden]>wrote:

> On Wed, Oct 28, 2009 at 11:44 PM, Tan, Tom (Shanghai) <TTan_at_[hidden]>
> wrote:
> >>  Please have a look and let me know what you think could be improved.
> > The first thing I notice is that it does not support std::wstring
> > directly. It's a big problem in my case I use wide-character in all my
> > applications, which simplifies dealing with UTF-16 adopted by Modern
> > Windows platforms.
> >
> > If I need to any string info from my program, I'll have to convert from
> > UTF16(represented as std::wstring) to UTF8 so that it could be working
> > well with LOGLITE. That's inconvenient.
>
> OTOH, if you are targeting any other platform in addition to Windows,
> it probably makes more sense to adopt UTF-8 throughout your program
> and convert to UTF-16 before calling Windows functions.
>
> > Offtopic, I am expecting boost::filesystem V3 for this very same reason.
>
> Way offtopic, I also find path/wpath problematic. In my mind, their
> invariant doesn't differ enough from that of string/wstring to justify
> coupling my interfaces with boost::filesystem. So I use UTF-8
> string/char const * in my code on all platforms, and use
> boost::filesystem as an implementation detail, through wrappers that
> take UTF-8 strings.
>

I've always found it was easiest to do something like:

namespace boost { namespace filesystem {
#if defined(_WIN32) || defined(WIN64)
    typedef wpath npath;
#else
    typedef path npath;
#endif
} }

and then use boost::filesystem::npath everywhere.  Performance isn't
generally the bottleneck when dealing with the filesystem, but why even
bother with so many behind-the-scenes conversions when you can just as
easily store everything in the type the O/S is expecting in the first place
with a simple typedef?  If there's a network layer involved where one
platform might have to deal with paths that originated from another
platform, then use UTF-8 as the network format, and write a template that
converts to npath that is specialized to a nop on non-windows platforms.