On Sat, 4 Feb 2006 c99ang@... wrote:
> Quoting Allen Zhao <xlz@...>:
> > Hi, All,
> > I just find that if I give a non-empty utf-8 string as the path argument,
> > the little application will crash with this error:
> > Unhandled exception at 0x7c81eb33 in test.exe: Microsoft C++ exception:
> > boost::filesystem::filesystem_error @ 0x0012fb0c.
> > The code segment is:
> > m_strStoragePath = "C:\\some\\existing\\directory\\to\\store\\torrent";
> > boost::filesystem::path pathStorage((const char*)m_strStoragePath,
> > boost::filesystem::native);
> > torrent_handle h = ((session*)m_pSession)->add_torrent(t, pathStorage);
> > where the m_strStoragePath is just a UTF-8 string class of my own
> > implementation (Hey, I do not use std::string because I want UTF-8/UTF-16
> > fast conversion)
> > The simple_client in the v0.9.1 works fine, where the path is given as ""
> > empty string.
> Note that boost.filesystem (in boost-1.33) isn't designed for utf-8 strings, so
> native checking may still consider utf-8 strings as incorrect.
> If no_check still will cause the exception, maybe you could break when
> boost::filesystem::exception is thrown (you can do that in visual studio) and
> see why it throws.
> Note that session constructor (since 0.9.1 I think) sets the checking to
> So maybe that should be changed to no_check.
Actually, I kind of make it work, though not without hussle. This is what
1) do not call
/* namespace fs = boost::filesystem;
Any such calls, either no_check or native, will pop up that VC++
runtime error dialog.
2) comment out the no_check lines in
/* xlz: we have to disable this, following codes does not seem to work
// namespace fs = boost::filesystem;
if ( !checker( name ) )
"invalid name \"" + name + "\" in path: \"" + src + "\"" )
3) With above modification, my wrapper class works, at least on my English
XP. I am not sure about Asian OS yet. But I tested several torrent
download, it seems to handle the download correctly with Japanese torrent,
at least. I will have to wait and see what is going to happen when all
these move to a Chinese or Japanese XP. This is the codes:
entry e = bdecode(mapTorrent, mapTorrent + nLen);
boost::filesystem::path pathStorage((const char*)m_strStoragePath, boost::filesystem::native);
torrent_handle h = ((session*)m_pSession)->add_torrent(t, pathStorage);
Where mapTorrent is the map of torrent file, and m_strStoragePath
when casted with (const char*) returns UTF-8 string of the file path (and
it returns UTF-16 native path when casted with (const unsigned short*) if
UNICODE is defined. this is my own cross-platform string class mimic java
API, with native support of UTF-8/UTF-16 conversion).
If something will go wrong when the code is moved to Asian OS, I will
suspect the line
pathStorage((const char*)m_strStoragePath, boost::filesystem::native)
I am just not sure what it turns to when m_strStoragePath returns not an
ascii string, but some Asian high bytes stuff. To answer that, probably I
have to understand boost::filesystem better. Any suggestion?