[boost] [Boost-bugs] [ boost-Bugs-1530999 ] permutation_iterator does not support conversions

From: SourceForge.net (noreply_at_[hidden])
Date: 2006-07-29 15:39:57

Bugs item #1530999, was opened at 2006-07-29 19:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1530999&group_id=7586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: iterator
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Krügler (daniel_kruegler)
Assigned to: David Abrahams (david_abrahams)
Summary: permutation_iterator does not support conversions

Initial Comment:
The current implementation of
boost::permutation_iterator does not support compatible
conversions. The below attached example demonstrates
the problem. The reason is due to the fact that the
converting c'tor

template<class OtherElementIterator, class
OtherIndexIterator>
permutation_iterator(
permutation_iterator<OtherElementIterator,
OtherIndexIterator> const& r
      , typename
enable_if_convertible<OtherElementIterator,
ElementIterator>::type* = 0
      , typename
enable_if_convertible<OtherIndexIterator,
IndexIterator>::type* = 0
      )
    : super_t(r.base()), m_elt_iter(r.m_elt_iter)
  {}

is provoked in the example and is generally defective:
There exists no public accessor for the private member
m_elt_iter and thus it's access is not allowed at the
point of its copy construction.

There exists two solutions to fix this issue. Since I'm
not sure, which is the best one, I propose both:

Solution (1): Add

template <typename, typename> friend class
permutation_iterator;
  
inside the permutation_iterator class template.

Advantage: Does not change the current interface of
permutation_iterator<>, disadvantage: It provides
friendship to every template
permutation_iterator<typename>, which could
theoretically be hijacked be programmers, which define
their own template specialization of the c'tor (See
http://www.gotw.ca/gotw/076.htm "The Language Lawyer"),
although that risk is low.

Solution (2): Provide a public accessor for member
m_elt_iter, e.g.

ElementIterator element_iterator() const { return
m_elt_iter; }

and call this member function in the conversion c'tor
instead of direct member access.

The advantage is that no friendship is needed (;-)),
the disadvantage is, that it adds a new public member.
I actual problem with that accessor for the internal
element iterator is: What expect users, which position
it corresponds to? Is it its current position or is it
its initial position (which is true, of course). The
last argument could be weakened by enforcing a more
descriptive name, e.g. primary_element_iterator().

I will provide cvs patches in the following minutes

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1530999&group_id=7586

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Boost-bugs mailing list
Boost-bugs_at_[hidden]
https://lists.sourceforge.net/lists/listinfo/boost-bugs