"George M. Garner Jr." <gmgarner@erols.com> wrote in message news:chr4oq$38p$1@sea.gmane.org...
Jonathan,
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 CreateFileMappingA--> CreateFileMappingA 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 fs::wpath arguments.
Try calling readonly_mapped_file::open with a simplified chinese path, for example.
Thanks for checking all this stuff!
Regards,
George.
Jonathan