id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
7660	BOOST_CODECVT_DO_LENGTH_CONST is incorrectly defined	gromer@…	Beman Dawes	"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."	Bugs	closed	To Be Determined	filesystem	Boost 1.53.0	Problem	fixed		gromer@…