Re: loglite - A logging library (JD)

[Tan, Tom (Shanghai)]

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

Offtopic, I am expecting boost::filesystem V3 for this very same reason.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Emil Dotchevski-3]

On Wed, Oct 28, 2009 at 11:44 PM, Tan, Tom (Shanghai) <TTan@...> 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.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Zachary Turner-2]

On Thu, Oct 29, 2009 at 11:28 AM, Emil Dotchevski
<emildotchevski@...>wrote:

> On Wed, Oct 28, 2009 at 11:44 PM, Tan, Tom (Shanghai) <TTan@...>
> 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost