Further to my Defect Report 484 on the standard library, I'm beginning
to wonder if I've just misunderstood the purpose of
iterator_traits::value_type.

I constructed an input iterator where *i returns an int, but I set
iterator_traits::value_type to bool. I then tried the following:

Have an input iterator iterate through the array {2,3,5}, and use
std::find to find a "true". On all the compilers I have access to this
failed, as the compilers simply compared the ints in the array to
boolean true, which returns false.

Reading the standard, I can't decide if this is correct behaviour or
not.. on one hand it looks like this is exactly what std::find claims to
do (find the first element where *a==true). On the other hand it seems
reasonable that an implementation can assume it can copy dereferenced
iterators in a variable of type iterator_traits::value_type, and if it
did so the returned answer would be different.

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

chris wrote:
> Further to my Defect Report 484 on the standard library, I'm beginning
> to wonder if I've just misunderstood the purpose of
> iterator_traits::value_type.
>
> I constructed an input iterator where *i returns an int, but I set
> iterator_traits::value_type to bool. I then tried the following:
>
> Have an input iterator iterate through the array {2,3,5}, and use
> std::find to find a "true". On all the compilers I have access to this
> failed, as the compilers simply compared the ints in the array to
> boolean true, which returns false.
>
> Reading the standard, I can't decide if this is correct behaviour or
> not.. on one hand it looks like this is exactly what std::find claims to
> do (find the first element where *a==true).

It is correct behavior.

> On the other hand it seems
> reasonable that an implementation can assume it can copy dereferenced
> iterators in a variable of type iterator_traits::value_type, and if it
> did so the returned answer would be different.

It's an interesting question, but you're looking at the wrong algorithm.
 What you need to look at (if you want to find a hole in the standard)
is the specification of some algorithm that actually needs to use
iterator_traits<X>::value_type for some input iterator type X.  I
suggest looking into std::unique_copy or std::merge.  An input iterator
is allowed to return anything convertible to its value_type.  Does that
break these algorithms?

If not, the standard is fine in this respect.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
> chris wrote:
>
>>Further to my Defect Report 484 on the standard library, I'm beginning
>>to wonder if I've just misunderstood the purpose of
>>iterator_traits::value_type.
>>
>>I constructed an input iterator where *i returns an int, but I set
>>iterator_traits::value_type to bool. I then tried the following:
>>
>>Have an input iterator iterate through the array {2,3,5}, and use
>>std::find to find a "true". On all the compilers I have access to this
>>failed, as the compilers simply compared the ints in the array to
>>boolean true, which returns false.
>>
>>Reading the standard, I can't decide if this is correct behaviour or
>>not.. on one hand it looks like this is exactly what std::find claims to
>>do (find the first element where *a==true).
>
>
> It is correct behavior.
>
>
>>On the other hand it seems
>>reasonable that an implementation can assume it can copy dereferenced
>>iterators in a variable of type iterator_traits::value_type, and if it
>>did so the returned answer would be different.
>
>
> It's an interesting question, but you're looking at the wrong algorithm.
>  What you need to look at (if you want to find a hole in the standard)
> is the specification of some algorithm that actually needs to use
> iterator_traits<X>::value_type for some input iterator type X.  I
> suggest looking into std::unique_copy or std::merge.  An input iterator
> is allowed to return anything convertible to its value_type.  Does that
> break these algorithms?
>
Actually, merge does bring up one interesting problem, which once again
may be a bug or may just be feeking strange.

If I merge {0,1} with {-1}, I might expect that I'd get
"false,true,true". Instead I get "true,false,true".

Also, here writing an algorithm which decides to copy the value of the
derefenced iterator isn't unreasonable (although doesn't seem to be done
anyway) as derefencing input iterators can be expensive in some cases.

I think a slightly more worrying characteristic might be that various
implementations branch to specialisations based on the value of
iterator_traits::value_type. I'm not sure they are allowed to do this,
unless of course those specialisations are valid code no matter what the
type...

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]