Boost C++ Libraries: Ticket #7376: join_iterator.hpp compiler warning

component changed; owner set

viboes — Tue, 18 Sep 2012 16:56:19 GMT

owner set to Neil Groves
component None → range

Nathan Ridge — Sat, 08 Jun 2013 19:46:48 GMT

Could you please give an example of Iterator1 and Iterator2 types for which this problem arises?

anonymous — Mon, 10 Jun 2013 20:22:33 GMT

here is a sample code that produces compiler error:

#include "boost/range/join.hpp"
struct A {};
struct B: public A {} ;
struct C: public A {};
int main()
{
  B b[10];
  C c[10];
  typedef ::boost::range_detail::join_iterator< const C*, const B* , const A&, const A& > join_iterator;
  join_iterator it(::boost::make_iterator_range(c),
                   ::boost::make_iterator_range(b),
                   ::boost::range_detail::join_iterator_begin_tag());
  *it;
}

error:

boost/range/detail/join_iterator.hpp:74: error: no match for ternary 'operator?:' in '(selected != 0u) ? *(const B*)((const boost::range_detail::join_iterator_union<const C*, const B*, const A&>*)this)->boost::range_detail::join_iterator_union<const C*, const B*, const A&>::m_it2 : *(const C*)((const boost::range_detail::join_iterator_union<const C*, const B*, const A&>*)this)->boost::range_detail::join_iterator_union<const C*, const B*, const A&>::m_it1

with patch suggested earlier this sample compiles without errors.

Nathan Ridge — Tue, 11 Jun 2013 00:42:17 GMT

Replying to anonymous:

here is a sample code that produces compiler error:
#include "boost/range/join.hpp"
struct A {};
struct B: public A {} ;
struct C: public A {};
int main()
{
  B b[10];
  C c[10];
  typedef ::boost::range_detail::join_iterator< const C*, const B* , const A&, const A& > join_iterator;
  join_iterator it(::boost::make_iterator_range(c),
                   ::boost::make_iterator_range(b),
                   ::boost::range_detail::join_iterator_begin_tag());
  *it;
}
error:

boost/range/detail/join_iterator.hpp:74: error: no match for ternary 'operator?:' in '(selected != 0u) ? *(const B*)((const boost::range_detail::join_iterator_union<const C*, const B*, const A&>*)this)->boost::range_detail::join_iterator_union<const C*, const B*, const A&>::m_it2 : *(const C*)((const boost::range_detail::join_iterator_union<const C*, const B*, const A&>*)this)->boost::range_detail::join_iterator_union<const C*, const B*, const A&>::m_it1

with patch suggested earlier this sample compiles without errors.

join_iterator is not part of the public interface of Boost.Range, it's just an implementation detail of boost::range::join().

boost::range::join() currently requires that the value type of the second range be convertible to the value type of the first range. Perhaps this requirement could be relaxed, to allow cases where the two value types are convertible to a common type but not to each other, but then we need to either:

get join_iterator to figure out what that common type is (which is possible in some cases like this one, but not in the general case); or
provide a public interface for the user to specify this common type (right now you are specifying it by instantiating join_iterator with a custom Reference template parameter, which is not public interface)

(or both).

Your patch will probably be part of either solution, but I am inclined to wait until we have a complete solution before applying it.

status changed

Neil Groves — Mon, 03 Mar 2014 15:13:56 GMT

status new → assigned

I think that specifying the Reference type of the join_iterator is already a way to manage the "common type" problem. I don't think that there is a general solution to the "common type" problem when we consider the potential interaction with user-defined types. It is possible that the desired return type isn't a reference in any of the input types. Manual specification is already possible, is simple and works.

I'm going to apply the small change as requested.

Neil Groves — Mon, 03 Mar 2014 15:17:23 GMT

Additionally aschoedl provided some extra code to do better automatic deduction of common-types.

status changed; resolution set

Neil Groves — Mon, 03 Mar 2014 15:43:29 GMT

status assigned → closed
resolution → fixed