BOOST_CODECVT_DO_LENGTH_CONST is incorrectly defined

[gromer@…]

Here's a simple way to see the problem:

$ gcc -c -I . libs/filesystem/src/utf8_codecvt_facet.cpp -Woverloaded-virtual
In file included from ./boost/detail/utf8_codecvt_facet.ipp:13,
                 from libs/filesystem/src/utf8_codecvt_facet.cpp:23:
/usr/include/c++/4.4/bits/codecvt.h:438: warning: ‘virtual int std::codecvt<wchar_t, char, __mbstate_t>::do_length(mbstate_t&, const char*, const char*, size_t) const’ was hidden
./boost/detail/utf8_codecvt_facet.hpp:171: warning:   by ‘virtual int boost::filesystem::detail::utf8_codecvt_facet::do_length(const mbstate_t&, const char*, const char*, size_t) const’

The problem is that the first parameter of do_length has been const-qualified in the derived class, whereas it is not in the base class. Apparently standard libraries vary in whether do_length's first parameter is const-qualified, because there's already a BOOST_CODECVT_DO_LENGTH_CONST macro controlling whether the const is applied. So a shallow fix would be to add libstdc++ to the list of libraries for which the const is disabled.

However, the deeper problem is that the macro is defined backwards: it applies the const unless it detects one of a list of excluded standard libraries. However, the C++ standard is quite clear (in both '03 and '11) that this parameter should not be const-qualified. It seems far more practical for the macro definition to enumerate the libraries which are known to deviate from the standard (by const-qualifying that parameter), not the ones which are known to comply with it.

See also ​https://svn.boost.org/trac/boost/changeset/26758, which patches the same 'problem' with libc++; I note with surprise that this changeset is 21 months old, but is still not live in a released version of Boost.

I've filed this in the filesystem component because boost/detail doesn't seem to have its own component; it could equally well be filed against program_options.

[gromer@…]

Sorry, that link should have been to ​https://svn.boost.org/trac/boost/changeset/68859.

[Dean Michael Berris]

Beman, should this macro be reversed instead -- only apply const if the standard library is known to be non-compliant?

[Dean Michael Berris]

Updating version to 1.53.0 as this still applies to the current release.

[Dean Michael Berris]

We still see this in 1.54.0. Can we get a resolution or a comment as to whether this is something worth fixing?

[anonymous]

Note: I've been working on this. The basic problems are:

a) is that the base class implementation varies among platforms b) which have been changing with different versions

I believe it's fixed in the release branch - but didn't make it into the 1.55 release.

Robert Ramey

[benpope81@…]

Doesn't look to be fixed in develop or master (on my test runner, anyway)

[anonymous]

It looks like this may have been resolved by ​https://github.com/boostorg/detail/commit/1fef8494fec86d23e557007343036c3d8a5b0ace

[Beman Dawes]

I just verified that this was resolved by ​https://github.com/boostorg/detail/commit/1fef8494fec86d23e557007343036c3d8a5b0ace

If there are further problems, please open a ticket against Boost.Serialization. Robert Ramey, the maintainer of Serialization, is maintaining the UTF-8 code in detail and filesystem is just an innocent bystander.

Thanks,

--Beman