Biju Thomas wrote:
>
> James Kuyper wrote:
> >
> > Bill Wade wrote:
> > >
> > > iterator must be convertible to const_iterator (table 65 in 23.1), so the
> > > comparison should succeed.
> >
> > The standard doesn't say that iterator must be implicitly convertible to
> > const_iterator, and the example given doesn't explicitly convert one to
> > the other.
> >
>
> I am little confused about this. The fourth row in the table that Bill
> Wade quoted says that iterator must be 'convertible' to const_iterator.
> Where does it say that it is 'explicitly convertible' that is really
> meant here?

It doesn't. It only says "convertible", a requirement that can be met
without meeting the requirements of "implicitly convertible". Every
implicit conversion can be made explicit, so "explicitly convertible"
has the exact same meaning as "convertible". Lots of explicit
conversions are not available implicitly. Therefore, while "explicitly
convertible" is redundant, "implicitly convertible" is not.

> It seems that the standard uses 'convertilble' without any qualification
> in many places, and, in all of the places that I checked, it is implicit
> conversion that is implied.

Could you provide an example of how you derived that implication?

The standard uses the term "convertible" in surprisingly small number of
locations, and never modifies it with either "implicitly" nor
"explicitly". It also says nothing in any of those locations that I
recognised as implying that "convertible" should be taken as short for
"implicitly convertible".
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Bill Wade wrote:
> >
> > iterator must be convertible to const_iterator (table 65 in 23.1), so the
> > comparison should succeed.
>
> The standard doesn't say that iterator must be implicitly convertible to
> const_iterator, and the example given doesn't explicitly convert one to
> the other.
>

I am little confused about this. The fourth row in the table that Bill
Wade quoted says that iterator must be 'convertible' to const_iterator.
Where does it say that it is 'explicitly convertible' that is really
meant here?

It seems that the standard uses 'convertilble' without any qualification
in many places, and, in all of the places that I checked, it is implicit
conversion that is implied.

Best regards,
Biju Thomas
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

kwilkins1@my-dejanews.com wrote in message
<7edbs7$4dq$1@nnrp1.dejanews.com>...
>
>Is the following legal C++?
> [deleted]


iterator must be convertible to const_iterator (table 65 in 23.1), so the
comparison should succeed.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:
>
> kwilkins1@my-dejanews.com wrote in message
> <7edbs7$4dq$1@nnrp1.dejanews.com>...
> >
> >Is the following legal C++?
> > [deleted]
>
> iterator must be convertible to const_iterator (table 65 in 23.1), so the
> comparison should succeed.

The standard doesn't say that iterator must be implicitly convertible to
const_iterator, and the example given doesn't explicitly convert one to
the other.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Is the following legal C++?

#include <set>
#include <string>

void f (const std::set<std::string> & a)
{
 if (a.find("a") != a.end())
 {
             // Some code
 }
}

Sun WorkShop 5.0 rejects this, as 'a.find("a")' returns iterator (for const or
non-const a) whereas 'a.end()' returns const_iterator (for const a).

The Sun WorkShop function declarations do appear to agree with the
declarations given in the standard:

iterator               begin();
const_iterator         begin() const;
iterator  find(const key_type& x) const;

and the standard does not appear to guarantee that set::iterator is the same
type as set::const_iterator. (In SGI STL they are the same type, so there is
no problem.)  On the other hand, the 'Associative container requirements'
table states that 'find' should return const_iterator for const a, so there
appears to be an inconsistency in the standard - unless const_iterator is
guaranteed to be equivalent to iterator for sets.

If Sun WorkShop is correct, then how is someone supposed to check the contents
of a const set (without resorting to const casts)?

Apologies if this has been asked before - I couldn't find anything in a
DejaNews search.

Thanks,

Karl.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

kwilkins1@my-dejanews.com wrote:
>
> Is the following legal C++?
>
> #include <set>
> #include <string>
>
> void f (const std::set<std::string> & a)
> {
>         if (a.find("a") != a.end())
>         {
>              // Some code
>         }
> }
>
> Sun WorkShop 5.0 rejects this, as 'a.find("a")' returns iterator (for const or
> non-const a) whereas 'a.end()' returns const_iterator (for const a).
>
> The Sun WorkShop function declarations do appear to agree with the
> declarations given in the standard:
>
> iterator               begin();
> const_iterator         begin() const;
> iterator  find(const key_type& x) const;
>

Section 23.3.3. p2 says that set<> "satisfies all of the requirements
.... of an associative container (23.1.2)." One of those requirements in
Table 69 is that a.find() returns "const_iterator for constant a". Only
the non-const version of set<>::find() is mentioned explicitly in
section 23.3.3 p2, but like all the other containers, it says
"Descriptions are provided here only for operations on set that are not
described in one of these tables and for operations where there is
additonal semantic information".

Therefore, both a.find() and a.end() should return const_iterators, so
there shouldn't be a problem.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]