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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs