Your mail is off-topic on this list, it would be appropriate on the
gcc-help list, or in Bugzilla if you want to report a bug.
On Wed, 27 Jun 2018 at 11:27, Csaba Raduly wrote:
>
> #include <boost/range/sub_range.hpp>
> #include <string>
> #include <vector>
>
> using srange = boost::sub_range<std::string const>;
>
> void func(srange) // by value
> {}
>
> int main()
> {
> std::string kitty{"meow"};
> srange hello{kitty};
> srange const& helref = hello;
>
> func(hello);
> func(helref); // line 17
>
> return 0;
> }
>
> $ g++ -v
> gcc version 9.0.0 20180626 (experimental) (GCC)
>
> $ g++ -Wall -pedantic -Wextra -Werror -save-temps subra.cpp
> subra.cpp: In function ‘int main()’:
> subra.cpp:17:13: error: implicitly-declared ‘constexpr
> boost::sub_range<const std::__cxx11::basic_string<char>
> >::sub_range(const boost::sub_range<const
> std::__cxx11::basic_string<char> >&)’ is deprecated
> [-Werror=deprecated-copy]
> func(helref);
> ^
> In file included from subra.cpp:1:
> /usr/include/boost/range/sub_range.hpp:259:20: note: because
> ‘boost::sub_range<const std::__cxx11::basic_string<char> >’ has
> user-provided ‘boost::sub_range<ForwardRange>&
> boost::sub_range<ForwardRange>::operator=(const
> boost::sub_range<ForwardRange>&) [with ForwardRange = const
> std::__cxx11::basic_string<char>]’
> sub_range& operator=( const sub_range& r )
> ^~~~~~~~
> subra.cpp:7:6: note: initializing argument 1 of ‘void func(srange)’
> void func(srange) // by value
> ^~~~
>
>
> I have two questions:
>
> 1. Why is a warning emitted only for the const srange?
Because line 16 doesn't use the sub_range copy constructor, it calls
this instead:
template< class ForwardRange2 >
sub_range(
ForwardRange2& r,
BOOST_DEDUCED_TYPENAME ::boost::enable_if<
is_compatible_range<ForwardRange2>
>::type* = 0
)
: base(impl::adl_begin(r), impl::adl_end(r))
{
}
This might be a Boost bug, albeit a harmless one. IMHO the template
constructor should be constrained so it isn't used for copying
non-const lvalues.
> 2. Shouldn't boost be exempt from this warning, given that it's
> included from a system directory (/usr/include) ?
Yes, it probably should, but see below.
> Shouldn't the "implicitly declared copy constructor" error be located
> at the class definition (boost header), rather than where it's being
> called (the call which does pass-by-value) ?
The warning is only issued at the point where the implicit definition
is needed, to avoid issuing warnings when the object is never copied.
It's needed at the call site in your code, not in the system header
(well, it might also be needed in the boost headers, but those
warnings are probably suppressed).
But I agree that if the class is defined in a system header you can't
change the code, so the warning is not very helpful. Please report a
bug, https://gcc.gnu.org/bugs/
