Filesystem V3 should not require wstring support

[Steve Soule <sts11dbxr@…>]

V2 of the filesystem library did not require wstring support; V3 does require wstring. There are systems in widespread use (such as those that use uclibc instead of glibc) that do not have wchar_t, and will probably never have wchar_t. So long as filesystem V2 still exists, this is not a problem, but V2 is officially deprecated, so might not be around much longer.

You need to either:

1. Keep filesystem V2 around forever.

or

2. Modify filesystem V3 so that it does not require wstring/wchar_t. (This would be my preference.)

[anonymous]

AFAIK, SourceForge is committed to keep the distribution files for old versions of Boost available for the foreseeable future. So in that sense, V2 will be around for a long, long, time. But I've got my hands full getting V3 off the ground, so want to stop supporting V2 as quickly as possible.

I have no interest in modifying V3 to support systems without wstring/wchar_t. I'm afraid it would take too much time and complicate the source code. It isn't just the core library itself; the test code is a serious concern too, as is down the road support.

If someone wants to create a patch, I'll take a look. But unless it can be done in a way that doesn't degrade the maintainability of the source code, include tests, I'm not likely to be interested.

--Beman

[wim@…]

I'd also appreciate if this gets fixed. Reasons:

1. even though it's a pragmatic approach that works in many cases, std::wstring is not a nicely portable solution for internationalized strings anyway (2 bytes per char on windows, 4 bytes per char on unix, and uses in general still an unspecified encoding). It's use should not be encouraged. You seem to realise this too, since you provide separate unicode methods (u16string, u32string).
2. many embedded systems don't support wstring. For example: Android, uclibc, ...

I'd be much more interested in a method that is actually generally usable, such as a u8string() method that returns UTF8 path info.

[anonymous]

Same here ... I'm using boost on android and since version 1.50 only V3 is included I'm stuck with version 1.49 and won't benefit from further updates ....

[Beman Dawes]

Hum... Interesting about Android...

It would not be too difficult to eliminate the wchar_t and std::wstring requirement for POSIX API systems as long as it is retained for Windows.

The issue then becomes testing. It is pretty hard to support a platform that is not covered by regular regression tests.

Is it even possible to run the regular boost regression tests on an Android development platform?

--Beman

[suky0001@…]

Filesystem 1.52 unit testing on Android

[suky0001@…]

@Beman: Yes, you can run the regular boost tests on Android, but this is not as trivial as running them on the host machine. Procedure:

• As for normal tests, go to libs/SOMELIB/test and run b2. The command line for b2 may have options specific to Android.
• Test will compile, but will obviously fail running since you're on the host machine.
• Copy bin.v2/libs/SOMELIB/test directory on your device or emulator (using ADB), and manually run them.
  • Depending on your API (Android version), you may use a specific directory (say /data/local/tmp), because you may not have run permissions elsewhere. The other solution is to root your device.
  • Also copy the boost libs the tests depends on.
• Run a terminal or an "adb shell"
• Write "export LD_LIBRARY_PATH=directory-you-put-boost-libs-in" (ex: "export LD_LIBRARY_PATH=/data/local/tmp")
• Run each test manually.

Actually some tests fail on Android with boost 1.52:

• operations_test / operations_test_static
• operations_unit_test (no errors, but outputs some wchar garbage)
• path_unit_test / path_unit_test_static

Attached to the ticket is the full output​, where unreadable characters have been replaced by "*** n UNREADABLE CHARS ***".

About the issue, I guess it would be possible to add dummy functions and types, so that wchar_t==char. That way, wchar would work as expected. Don't you think?

[Sukender <suk0001@…>]

Forgot to mention: the wchar issues seem to prevent iostream "filtering_stream_test" from running properly (See ​what I posted on boost mailing list).