Re: [Boost-bugs] [Boost C++ Libraries] #5463: default constructor of filter_iterator does not initialize members

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5463: default constructor of filter_iterator does not initialize members
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-13 14:06:01


#5463: default constructor of filter_iterator does not initialize members
---------------------------------------------+------------------------------
  Reporter: aleksander.sulkowski@… | Owner: dave
      Type: Bugs | Status: closed
 Milestone: To Be Determined | Component: iterator
   Version: Boost 1.47.0 | Severity: Problem
Resolution: invalid | Keywords: filter_iterator default constructor
---------------------------------------------+------------------------------

Comment (by dave):

 Replying to [comment:4 anonymous]:
> There is one more additional use of singular iterators - like in case of
 istream_iterator. They can be compared with an other iterator to check
 agains end condition.

 No, please consult the standard. Singular iterators can't be compared.
   For that particular iterator type, default-construction does not produce
 a singular iterator.

> It may be far more useful then calling "end" method from the iterator
 class.

 â€œ"end" method?”

> Please read my example below.
>
> I do not agree with the efficiency argument, as only if the iterator
 encapsulated by filter_iterator is a class, it's constructor is called
 anyway. I do not think simple types initialization cost justifies leaving
 it uninitialized.

 Probably it doesn't in your application and in many others, but libraries
 have broad constituencies.

> It would help in my particular case. I have an iterator encapsulating a
 filter_iterator on top of a predicate and an array. I relay on the fact
 the instances of my iterator default constructed are equal. I pass to
 boost::minmax 2 arguments:
>
> * a non-default constructed instance of my iterator, initialized with
 the filter iterator initialized with an array.
> * a default constructed iterator, what encapsulates default constructed
 filter iterator which indicates the end (like in istream_iterator)
>
> I check result of minmax, that returns a pair of iterators having my
 type. In order to check if they are end iterators, I compare each with
 default constructed iterator. ''I do not have access to "internal",
 filter_iterator anymore,

 The {{{.base()}}} member function doesn't work for this purpose?

> but I can construct a new "end iterator" and compare.''
>
> It will work, only if encapsulated filter iterators, default
 initialized, will be equal to the "end" iterator I passed to
 boost::minmax. In order to achieve that filter iterators have to be equal,
 so the iterator they encapsulate have to be initialized (to be equal). And
 they are for any other than simple type case.

 I'm sorry, I can't understand what you're describing well enough. Perhaps
 if you attached some code...

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5463#comment:5>
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:06 UTC