Re: [boost] more problem with functional + projection_iterator

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2001-10-04 13:44:24

yes. ok it's a stupid example, but I don't want to make it more compilcated.
suppose I have a function which smooth an iterator range than change the
copy to smooth, that my iterator has to return a reference not a value:
--------------------------
smooth(
  boost::make_const_projection_iterator(a.begin(),
    boost::compose1(VectorAccess<std::vector<double> >(0),
                    MemberAccess<A, std::vector<double> >(&A::y))),
  boost::make_const_projection_iterator(a.end(),
    boost::compose1(VectorAccess<std::vector<double> >(0),
                    MemberAccess<A, std::vector<double> >(&A::y))),
  boost::make_const_projection_iterator(a.begin(),
    boost::compose1(VectorAccess<std::vector<double> >(0),
                    MemberAccess<A, std::vector<double> >(&A::y))));
--------------------------

David Abrahams wrote:
> 
> Are you sure you don't want a transform_iterator_adaptor instead?
> 
> -Dave
> 
> ===================================================
>   David Abrahams, C++ library designer for hire
>  resume: http://users.rcn.com/abrahams/resume.html
> 
>         C++ Booster (http://www.boost.org)
>           email: david.abrahams_at_[hidden]
> ===================================================
> 
> ----- Original Message -----
> From: "Levente Farkas" <lfarkas_at_[hidden]>
> To: "boost" <boost_at_[hidden]>
> Sent: Thursday, October 04, 2001 12:25 PM
> Subject: [boost] more problem with functional + projection_iterator
> 
> > hi,
> > I try to compile the attached example and faild both with MSVC 6sp5 and
> > gcc-2.96 on linux. the problem is in unary_compose (from compose1). even
> if I
> > switch from std::compose1 to boost::compose1 the problem exists. the
> reason
> > is a bit complicated. every function object (subclass of
> std::unary_function)
> > return with result_type which is usualy not a reference! what's more it
> > can't be a reference since everybody suppose these functions are return
> > with T& and result_type defined as T. that's the reason why
> projection_iterator
> > suppose it and put & the place where it's required. IMHO this whole
> > thing is a huge design mistake. result_type should have to be defined
> > as the real result type of operator(). anyway this would be a better
> > choise for argument_type too. solutions (if we don't would like to
> > change the whole stl paradigm to right way result_type have to be the
> > real result type,...) to change all functionals definition to
> > typename call_traits<typename
> unary_traits<Operation1>::result_type>::param_type
> > in this case all functor can be used as an argumnet for another functor.
> > without this this's unsolvable.
> > or anybody has any better idea?
> >
> >  -- Levente                               "Si vis pacem para bellum!"
> > Info: http://www.boost.org  Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- 
 -- Levente                               "Si vis pacem para bellum!"