[Boost-bugs] [Boost C++ Libraries] #7660: BOOST_CODECVT_DO_LENGTH_CONST is incorrectly defined

Subject: [Boost-bugs] [Boost C++ Libraries] #7660: BOOST_CODECVT_DO_LENGTH_CONST is incorrectly defined
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-11-07 17:55:24

#7660: BOOST_CODECVT_DO_LENGTH_CONST is incorrectly defined
 Reporter: gromer@… | Owner: bemandawes
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: filesystem
  Version: Boost 1.52.0 | Severity: Problem
 Keywords: |
 Here's a simple way to see the problem:

 $ gcc -c -I . libs/filesystem/src/utf8_codecvt_facet.cpp -Woverloaded-
 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

Ticket URL: <https://svn.boost.org/trac/boost/ticket/7660>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:11 UTC