From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-09 22:23:44
"George M. Garner Jr." <gmgarner_at_[hidden]> wrote in message
> memmap.cpp makes assumptions about character width that will not be true in
> the specific case where UNICODE is defined. For example, the declaration
> assumes that strings will be narrow but
> CreateFile is called. CreateFile is a macro that translates into either
> CreateFileA or CreateFileW depending on the _UNICODE/UNICODE macro. If
> _UNICODE is define the code will not compile. You should explicity call
> Ansi versions of Windows api's where narrow character streams are intended.
Apparently I noticed and fixed this error after posting the final version for
review. The two changes I made were
CreateFile --> CreateFileA
Is that sufficient?
> A better solution for cases such as memmap.cpp would be to parameterize the
> character type and provide both Ansi and Unicode implementations.
I think I'll wait to see how Boost.Filesystem eventually deals with these issues
(which are actively being discussed), and attempt to adopt the same solution.
I image that eventually the mapped_file constructors will accept fs::path and
> calling readonly_mapped_file::open with a simplified chinese path, for
Thanks for checking all this stuff!