https://svn.boost.org/trac10/ticket/7660 <p> Here's a simple way to see the problem: </p> <pre class="wiki">$ 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&lt;wchar_t, char, __mbstate_t&gt;::do_length(mbstate_t&amp;, 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&amp;, const char*, const char*, size_t) const’ </pre><p> 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. </p> <p> 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 <em>not</em> be const-qualified. It seems far more practical for the macro definition to enumerate the libraries which are known to <em>deviate</em> from the standard (by const-qualifying that parameter), not the ones which are known to <em>comply</em> with it. </p> <p> See also <a class="ext-link" href="https://svn.boost.org/trac/boost/changeset/26758"><span class="icon">​</span>https://svn.boost.org/trac/boost/changeset/26758</a>, 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. </p> <p> 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. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/7660 Trac 1.4.3 gromer@… Wed, 07 Nov 2012 18:01:11 GMT https://svn.boost.org/trac10/ticket/7660#comment:1 https://svn.boost.org/trac10/ticket/7660#comment:1 <ul> <li><strong>cc</strong> <span class="trac-author">gromer@…</span> added </li> </ul> <p> Sorry, that link should have been to <a class="ext-link" href="https://svn.boost.org/trac/boost/changeset/68859"><span class="icon">​</span>https://svn.boost.org/trac/boost/changeset/68859</a>. </p> Ticket Dean Michael Berris Wed, 20 Mar 2013 04:46:15 GMT https://svn.boost.org/trac10/ticket/7660#comment:3 https://svn.boost.org/trac10/ticket/7660#comment:3 <ul> <li><strong>version</strong> <span class="trac-field-old">Boost 1.52.0</span> → <span class="trac-field-new">Boost 1.53.0</span> </li> </ul> <p> Updating version to 1.53.0 as this still applies to the current release. </p> Ticket Dean Michael Berris Thu, 15 Aug 2013 01:11:38 GMT https://svn.boost.org/trac10/ticket/7660#comment:8 https://svn.boost.org/trac10/ticket/7660#comment:8 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> I just verified that this was resolved by <a class="ext-link" href="https://github.com/boostorg/detail/commit/1fef8494fec86d23e557007343036c3d8a5b0ace"><span class="icon">​</span>https://github.com/boostorg/detail/commit/1fef8494fec86d23e557007343036c3d8a5b0ace</a> </p> <p> 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. </p> <p> Thanks, </p> <p> --Beman </p> Ticket