In article <6no4c6$4s5@marianna.psu.edu>,
  zabluda@math.psu.edu (Oleg Zabluda) wrote:
>
> Only if you did the same for vector, which I doubt. I bet you still
> allow an implicit conversion from vector<Derived>::iterator to
> vector<Base>::iterator.

Most implementations allow this, since most implementations define
vector<T>::iterator with a typedef to T*.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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              ]

Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6nsk7i$ek2@marianna.psu.edu>...
> ==>: > : So the latest definitions of the container iterators have
> ==>: > : neither iterator based on the other. Instead, member class
> ==>: > : iterator includes a conversion
> ==>: > : from member class const_iterator.
> ==>: >
> ==>: > : Hope this satisfies your inquiring mind.
> : >
> : > Only if you did the same for vector, which I doubt.
>
> : Why do you doubt it? I make occasional mistakes, like any mortal, but I'm
> : not exactly stupid.
>
> Here `did the same'' didn't mean `didn't allow const-unsafe implicit
> conversions''. It meant `did the same as in the paragraph, marked with
> "==>:", from your post I was replying to''. In other words `did
> the same'' meant that you defined vector<T>::iterator as a real
> class rather then just typedeffing it to T*,

Yes, I understood what you meant. And that's what I did.

>                                             which causes the
> following problem:
>
> : >                                                I bet you still
> : > allow an implicit conversion from vector<Derived>::iterator to
> : > vector<Base>::iterator.
>
> : Unless the subtleties of template specialization are lost on me (and they
> : sometimes are), you'd lose that bet. You're being gratuitously insulting.
>
> No I am not. You simply misunderstood me. I am pretty sure
> I'd win that bet. In fact, I'd be willing to bet 10:1.

I simply did not misunderstand you. You misunderstood me, and you
underestimated me.

Out of kindness to you, however, I will not goad you into a sucker bet.
With the latest Dinkum C++ or Abridged libraries, the following code
causes diagnostics in the two iterator assignments, as most of us
would want:

struct B {
 char ch; };
struct D : public B
 {};

typedef vector<B> VB;
typedef vector<D> VD;

void f() {
 VB vb;
 VD vd;
 VB::iterator vbi = vd.begin();
 VD::iterator vdi = vb.begin();
 }

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6nqu1d$6v1$1@news.interlog.com>,
  "Daniel Parker" <danielp@nospam.com> wrote:
>
> P.J. Plauger wrote in message <01bda8ce$f7671820$8a1ec2d0@porky>...
> >Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6no3n5
> >
> >For the record, I admit to permitting const_iterator to iterator conversions
> >because of a design error. And I've fixed them. You have proclaimed that
> >there are all sorts of conversions between iterators for different
containers.
> >The examples you give are evidently for some other implementation that
> >you have confused with VC++.
>
> Actually, no.  I've been able to compile and link the examples Oleg posted
> with VC 5.0 (SP3), with no reported errors.

For the exact example he gave, so have I.  But I think this is probably
due to an error in the compiler, and not in the library -- the two
iterator types are different in the library, and in other contexts,
the two are treated differently.  (Two variables of the iterator
types in question, and then trying to assign them, resulted in a
compiler error, for example.)

Notice that 1) both the STLport and Plauger's library use a similar
strategy in the implementation, and 2) while I don't see how the exact
example could work, the standard very definitely allows set< int >::iterator
and map< int , int >::iterator to be the same type.  (Both Plauger's and
the STLport implementations distinguish, however.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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              ]

P.J. Plauger <pjp@dinkumware.com> wrote:
: Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6nsk7i$ek2@marianna.psu.edu>...
: > ==>: > : So the latest definitions of the container iterators have
: > ==>: > : neither iterator based on the other. Instead, member class
: > ==>: > : iterator includes a conversion
: > ==>: > : from member class const_iterator.
: > ==>: >
: > ==>: > : Hope this satisfies your inquiring mind.
: > : >
: > : > Only if you did the same for vector, which I doubt.
: >
: > : Why do you doubt it? I make occasional mistakes, like any mortal, but I'm
: > : not exactly stupid.
: >
: > Here `did the same'' didn't mean `didn't allow const-unsafe implicit
: > conversions''. It meant `did the same as in the paragraph, marked with
: > "==>:", from your post I was replying to''. In other words `did
: > the same'' meant that you defined vector<T>::iterator as a real
: > class rather then just typedeffing it to T*,

: Yes, I understood what you meant. And that's what I did.

: >                                             which causes the
: > following problem:
: >
: > : >                                                I bet you still
: > : > allow an implicit conversion from vector<Derived>::iterator to
: > : > vector<Base>::iterator.
: >
: > : Unless the subtleties of template specialization are lost on me (and they
: > : sometimes are), you'd lose that bet. You're being gratuitously insulting.
: >
: > No I am not. You simply misunderstood me. I am pretty sure
: > I'd win that bet. In fact, I'd be willing to bet 10:1.

: I simply did not misunderstand you. You misunderstood me, and you
: underestimated me.

: Out of kindness to you, however, I will not goad you into a sucker bet.

[....]

Ok, sorry for underestimating you.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ 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              ]

P.J. Plauger <pjp@dinkumware.com> wrote:
: Daniel Parker <danielp@nospam.com> wrote in article <6nqu1d$6v1$1@news.interlog.com>...
: > P.J. Plauger wrote in message <01bda8ce$f7671820$8a1ec2d0@porky>...
: > >Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6no3n5
: > >
: > >For the record, I admit to permitting const_iterator to iterator conversions
: > >because of a design error. And I've fixed them. You have proclaimed that
: > >there are all sorts of conversions between iterators for different containers.
: > >The examples you give are evidently for some other implementation that
: > >you have confused with VC++.
: >
: > Actually, no.  I've been able to compile and link the examples Oleg posted
: > with VC 5.0 (SP3), with no reported errors.

: Yup. Just tried it myself with the same result. It's an obvious compiler bug,
: since at least one other compiler gripes about the type mismatch that lies
: at the heart of the original example. What I was railing about above, however,
: was Zabluda's earlier assertion:

: > They should be, but they were not. You typedeffed them all to
: > rb_tree<void*>* or something like that.

: This is indeed the kind of *library* code that can cause bad type punning,
: *but it ain't my code*.

: I understand that compiler and library generally look like a black box to
: programmers. I intend to work with Microsoft to ensure that this problem
: disappears, whoever is to blame. I make the distinction here between
: language and library only because of the strong implication that lax
: design of the library was the one and only culprit.

Ok, sorry then. I was wrong. For the purposes of this discussion,
it's not your fault, as far as I am concerned.

Oleg.--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

On 07 Jul 98 20:00:05 GMT, jkanze@otelo.ibmmail.com wrote:

>the standard very definitely allows set< int >::iterator
>and map< int , int >::iterator to be the same type.

According to FDIS:

set<int>::iterator must be an "iterator type pointing to" int
map< int , int >::iterator is an "iterator type pointing to"
pair<const int, int>

While the standard doesn't precisely define what "iterator type
pointing to X" means, I think the only reasonable interpretation is
that the expression *p (where p is an object of the iterator type) has
type X.

I don't see any way to make that compatible with your assertion.
---
[ 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              ]

Daniel Parker <danielp@nospam.com> wrote in article <6nj5vk$q8b$1@news.interlog.com>...
> But on a related matter, can anyone suggest why P.J. Plauger would implement
> a list iterator in his STL library that makes const_iterator derive from
> iterator?

Sure, I can explain it. I got it backwards. Fixed in our current baseline.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

P.J. Plauger <pjp@dinkumware.com> wrote:
: Daniel Parker <danielp@nospam.com> wrote in article <6nj5vk$q8b$1@news.interlog.com>...
: > But on a related matter, can anyone suggest why P.J. Plauger would implement
: > a list iterator in his STL library that makes const_iterator derive from
: > iterator?

: Sure, I can explain it. I got it backwards. Fixed in our current baseline.

What do you mean backwards? Now you derive iterator from
const_iterator or something? Inquiring minds want to know.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

P.J. Plauger wrote in message <01bda77d$b4cb12c0$8a1ec2d0@porky>...
>Oleg Zabluda <zabluda@math.psu.edu> wrote in article
<6nk1ug$2b0@marianna.psu.edu>...
>> However, the unimaginable horrors go well beyound that.
>
>voif aside, I have trouble imagining such horrors myself, unless you're
>seeing a compiler limitation.

Just for the record, I compiled and linked the following, with no reported
errors, with VC++ 5.0 (SP 3):

using namespace std;
#define voif void

voif f( set<int>& s )
{
   map<char, double>::iterator i = s.begin();
   i -> second = 0.0;
}
int main()
{
 set<int> s;

 f( s );
}

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

P.J. Plauger wrote in message <01bda77d$b4cb12c0$8a1ec2d0@porky>...
>
>I have trouble imagining such horrors myself, unless you're
>seeing a compiler limitation. ..map and set iterators should be distinct
types.

VC 5.0 (SP3) is also happy to compile and link

void f( const set<int>& s )
{
 const std::map<char, double>::iterator i = s.begin();
   i -> second = 0.0;
}
int main()
{
 const std::set<int> s;
 f( s );
}

If I were to run this, would that qualify as "undefined behaviour"?

I would be greatful if you could indicate whether the fixes you referred to
will be in the Visual C++ 6.0 release.

Regards,
Daniel Parker




[ 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              ]

P.J. Plauger <pjp@dinkumware.com> wrote:
: Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6nk1ug$2b0@marianna.psu.edu>...
: > However, the unimaginable horrors go well beyound that.
: > For example, last time I checked, the following would
: > compile just fine, with MSVC++ + Plauger's libs:
: >
: > voif f(set<int>& s)
: > {
: >   map<char, double>::iterator i = s.begin();
: >   i -> second = 0.0;
: > }
: >
: > I was also able to add ``const'' to this almost enywhere,
: > with no visible effect on compilation.

: voif aside, I have trouble imagining such horrors myself, unless you're
: seeing a compiler limitation. In the VC++ V5.0 code, maps and sets
: share the same problem that you report for lists -- you can implicitly
: convert a const_iterator to an iterator as a derived-to-base conversion --
: but map and set iterators should be distinct types.

They should be, but they were not. You typedeffed them all to
rb_tree<void*>* or something like that.

: In any event, the latest version of the Dinkum C++ Library has unique
: iterators for all of [multi] [hash_] {map set}. And iterators support only
: const-safe conversions.

I'd have to see that for myself before I believe it's all nice and
clean now.

I am glad that all those poor souls who are stuck with MSVC++
will not experience horrible [const]crosscasts between set and
map as soon as they will shell more bucks for your upgraded
library plus some more for a new version of VC++. Shouldn't you
make these defect fixes available for free?

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

P.J. Plauger <pjp@dinkumware.com> wrote:
: Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6njukl$1kc@marianna.psu.edu>...
: > : > But on a related matter, can anyone suggest why P.J. Plauger would implement
: > : > a list iterator in his STL library that makes const_iterator derive from
: > : > iterator?
: >
: > : Sure, I can explain it. I got it backwards. Fixed in our current baseline.
: >
: > What do you mean backwards? Now you derive iterator from
: > const_iterator or something? Inquiring minds want to know.

: If you derive either from the other, you of course want to permit conversion
: from iterator to const_iterator but not the other way around. I got it backwards
: by deriving const_iterator from iterator, thereby allowing an undesirable
: conversion, as you observed.

: Later changes to the draft C++ Standard (since VC++ V5.0 was frozen)
: now require each iterator to derive from template class iterator in incompatible
: ways.

I am not aware of any requirement that any iterator be derived from
anything. I don't have an access to FDIS though, but I doubt very
much that any such requirement was introduced there. Care to explain?

: So the latest definitions of the container iterators have neither iterator
: based on the other. Instead, member class iterator includes a conversion
: from member class const_iterator.

: Hope this satisfies your inquiring mind.

Only if you did the same for vector, which I doubt. I bet you still
allow an implicit conversion from vector<Derived>::iterator to
vector<Base>::iterator.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

Oleg Zabluda wrote in message <6no3n5$4r9@marianna.psu.edu>...
>P.J. Plauger <pjp@dinkumware.com> wrote:
>: Oleg Zabluda <zabluda@math.psu.edu> wrote in article
<6nk1ug$2b0@marianna.psu.edu>...


>I am glad that all those poor souls who are stuck with MSVC++
>will not experience horrible [const]crosscasts between set and
>map as soon as they will shell more bucks for your upgraded
>library plus some more for a new version of VC++. Shouldn't you
>make these defect fixes available for free?


I don't think Dinkumware's version of STL is the one and only version of STL
to have teething troubles; more serious problems have been reported with
Rogue Wave's, for example.  I don't think I've ever made the mistakes that
would give rise to the problems discussed here, so I'm not particularly
worried about them.  And we're going to be shelling out a lot more bucks for
our commercial UNIX compiler upgrades than for our PC ones.  Since
Dinkumware has been known to make defect fixes available for free in the
recent past, you might have worded that a little more courteously.

The one question I have though, is what is the state of the STL libraries
that will be shipping with Version 6 of the Visual C++ compiler?

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6no4c6$4s5@marianna.psu.edu>...
> : Later changes to the draft C++ Standard (since VC++ V5.0 was frozen)
> : now require each iterator to derive from template class iterator in incompatible
> : ways.
>
> I am not aware of any requirement that any iterator be derived from
> anything. I don't have an access to FDIS though, but I doubt very
> much that any such requirement was introduced there. Care to explain?

Well, you don't *have* to derive each iterator from template class iterator, but
you have to make each iterator class look as if you did. Specifically, anything
other than a pointer had better define the member types:

iterator_category
value_type
difference_type
pointer
reference

Basing your iterator class on template class iterator provides a convenient
notation for specifying these types.

My original point is that the types pointer and reference (but *not* value_type)
must differ between an iterator and a const_iterator. You can still base one
type on the other, and mask the types that must change, but it gets less and
less convenient. I eventually concluded that the notational convenience of
basing one iterator on another was more than offset by the extra cruft required,
so I changed my approach.

> : So the latest definitions of the container iterators have neither iterator
> : based on the other. Instead, member class iterator includes a conversion
> : from member class const_iterator.
>
> : Hope this satisfies your inquiring mind.
>
> Only if you did the same for vector, which I doubt.

Why do you doubt it? I make occasional mistakes, like any mortal, but I'm
not exactly stupid.

>                                                I bet you still
> allow an implicit conversion from vector<Derived>::iterator to
> vector<Base>::iterator.

Unless the subtleties of template specialization are lost on me (and they
sometimes are), you'd lose that bet. You're being gratuitously insulting.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6no3n5$4r9@marianna.psu.edu>...
> : voif aside, I have trouble imagining such horrors myself, unless you're
> : seeing a compiler limitation. In the VC++ V5.0 code, maps and sets
> : share the same problem that you report for lists -- you can implicitly
> : convert a const_iterator to an iterator as a derived-to-base conversion --
> : but map and set iterators should be distinct types.
>
> They should be, but they were not. You typedeffed them all to
> rb_tree<void*>* or something like that.

If you're going to cast aspersions as freely as you do, get your goddam
facts straight. I have *never* written the identifier rb_tree in a piece of
code in my life. You're obviously mistaking me for someone else you
enjoy feeling superior to.

> : In any event, the latest version of the Dinkum C++ Library has unique
> : iterators for all of [multi] [hash_] {map set}. And iterators support only
> : const-safe conversions.
>
> I'd have to see that for myself before I believe it's all nice and
> clean now.

I'm sure.

> I am glad that all those poor souls who are stuck with MSVC++

(and who somehow produce a lot of working code while writhing in agony)

> will not experience horrible [const]crosscasts between set and
> map as soon as they will shell more bucks for your upgraded
> library plus some more for a new version of VC++.

For the record, I admit to permitting const_iterator to iterator conversions
because of a design error. And I've fixed them. You have proclaimed that
there are all sorts of conversions between iterators for different containers.
The examples you give are evidently for some other implementation that
you have confused with VC++.

>                                                                          Shouldn't you
> make these defect fixes available for free?

Well, I have in fact made a number of fixes for VC++ freely available.
See http://www.dinkumware.com/vc_fixes.html. I am under no obligation
to do so -- that's Microsoft's responsibility. I did so anyway, with the
unofficial blessing of the folks at Microsoft, because we all agree that's
the best way to serve Microsoft's customers.

Bugs happen. They cost money to fix. People buy software knowing it
contains a certain number of bugs, however well tested. People buy
upgrades to help pay for the continued maintenance of products that
are worth maintaining.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

P.J. Plauger wrote in message <01bda8ce$f7671820$8a1ec2d0@porky>...
>Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6no3n5
>
>For the record, I admit to permitting const_iterator to iterator conversions
>because of a design error. And I've fixed them. You have proclaimed that
>there are all sorts of conversions between iterators for different containers.
>The examples you give are evidently for some other implementation that
>you have confused with VC++.

Actually, no.  I've been able to compile and link the examples Oleg posted
with VC 5.0 (SP3), with no reported errors.

Regards,
Daniel Parker
---
[ 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              ]

Daniel Parker <danielp@nospam.com> wrote in article <6nqh1b$j27$1@news.interlog.com>...
> I don't think Dinkumware's version of STL is the one and only version of STL
> to have teething troubles; more serious problems have been reported with
> Rogue Wave's, for example.  I don't think I've ever made the mistakes that
> would give rise to the problems discussed here, so I'm not particularly
> worried about them.

Thanks for the perspective.

>                                And we're going to be shelling out a lot more bucks for
> our commercial UNIX compiler upgrades than for our PC ones.  Since
> Dinkumware has been known to make defect fixes available for free in the
> recent past, you might have worded that a little more courteously.

I made the same point, rather more rudely, in a separate posting.

> The one question I have though, is what is the state of the STL libraries
> that will be shipping with Version 6 of the Visual C++ compiler?

I'm not at liberty to give details, but I'm afraid the progress will prove
disappointing to many. (This is one of the reasons we've decided to make
our interim patches so freely available.) Thanks to some litigation that was
ugly, protracted, and essentially pointless, Microsoft was unable to profit
during a critical period of time from all the assistance we were prepared to
supply. We are now doing what we can to ameliorate the situation.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Daniel Parker <danielp@nospam.com> wrote in article <6nqu1d$6v1$1@news.interlog.com>...
> P.J. Plauger wrote in message <01bda8ce$f7671820$8a1ec2d0@porky>...
> >Oleg Zabluda <zabluda@math.psu.edu> wrote in article <6no3n5
> >
> >For the record, I admit to permitting const_iterator to iterator conversions
> >because of a design error. And I've fixed them. You have proclaimed that
> >there are all sorts of conversions between iterators for different containers.
> >The examples you give are evidently for some other implementation that
> >you have confused with VC++.
>
> Actually, no.  I've been able to compile and link the examples Oleg posted
> with VC 5.0 (SP3), with no reported errors.

Yup. Just tried it myself with the same result. It's an obvious compiler bug,
since at least one other compiler gripes about the type mismatch that lies
at the heart of the original example. What I was railing about above, however,
was Zabluda's earlier assertion:

> They should be, but they were not. You typedeffed them all to
> rb_tree<void*>* or something like that.

This is indeed the kind of *library* code that can cause bad type punning,
*but it ain't my code*.

I understand that compiler and library generally look like a black box to
programmers. I intend to work with Microsoft to ensure that this problem
disappears, whoever is to blame. I make the distinction here between
language and library only because of the strong implication that lax
design of the library was the one and only culprit.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Daniel Parker <danielp@nospam.com> wrote:
: Oleg Zabluda wrote in message <6no3n5$4r9@marianna.psu.edu>...
: >P.J. Plauger <pjp@dinkumware.com> wrote:
: >: Oleg Zabluda <zabluda@math.psu.edu> wrote in article
: <6nk1ug$2b0@marianna.psu.edu>...

: >I am glad that all those poor souls who are stuck with MSVC++
: >will not experience horrible [const]crosscasts between set and
: >map as soon as they will shell more bucks for your upgraded
: >library plus some more for a new version of VC++. Shouldn't you
: >make these defect fixes available for free?

: I don't think Dinkumware's version of STL is the one and only version of STL
: to have teething troubles; more serious problems have been reported with
: Rogue Wave's, for example.  I don't think I've ever made the mistakes that
: would give rise to the problems discussed here, so I'm not particularly
: worried about them.

Actually, I am not particularly worried about them either.
For one, I don't use VC++ and with any luck never will.
Second of all, I've seen worse problems, even in VC++ libs,
like GPF's on innocent deque operations. It's just that
these [const]crosscasts are simply bizarre that's all.
Plauger still can't believe it's for real. That's
understandable, because that was my first reaction as well.
You can hardly get anybody's attention with a simple segmentation
fault these days. Plus the EC++ heat is spilling over here
as well.

: And we're going to be shelling out a lot more bucks for
: our commercial UNIX compiler upgrades than for our PC ones.  Since
: Dinkumware has been known to make defect fixes available for free in the
: recent past, you might have worded that a little more courteously.

You think this was not courteous? That's because you've never
heard me commenting on Unix vendors who did everything humanly
possible to kill Unix by their software and hardware pricing
practices. Had it not been for Linux, they would have succedded
by about now.

: The one question I have though, is what is the state of the STL libraries
: that will be shipping with Version 6 of the Visual C++ compiler?

Since Microsoft products have no bugs (see Nathan Myers' homepage),
I don't think the quaestion is very meanigful :-).

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ 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              ]

P.J. Plauger <pjp@dinkumware.com> wrote:
: Oleg Zabluda <zabluda@math.psu.edu> wrote in article
<6no4c6$4s5@marianna.psu.edu>...
: > : Later changes to the draft C++ Standard (since VC++ V5.0 was frozen)
: > : now require each iterator to derive from template class iterator in
: > : incompatible
: > : ways.
: >
: > I am not aware of any requirement that any iterator be derived from
: > anything. I don't have an access to FDIS though, but I doubt very
: > much that any such requirement was introduced there. Care to explain?

: Well, you don't *have* to derive each iterator from template class
: iterator, but
: you have to make each iterator class look as if you did. Specifically,
: anything
: other than a pointer had better define the member types:

: iterator_category
: value_type
: difference_type
: pointer
: reference

: Basing your iterator class on template class iterator provides a
: convenient
: notation for specifying these types.

: My original point is that the types pointer and reference (but *not*
: value_type) must differ between an iterator and a const_iterator.

This is an interesting point. I could not find anything in CD2
which says that valie_type _must_ differ between an iterator
and const_iterator, while it is definitely allowed. I have
hard time reading the committee's mind from over here, but it
makes me wonder if it was unintentional (I hope so) and if it
amounts to a defect or not.

: You can still base one
: type on the other, and mask the types that must change, but it gets less
: and
: less convenient. I eventually concluded that the notational convenience of
: basing one iterator on another was more than offset by the extra cruft
: required,
: so I changed my approach.

==>: > : So the latest definitions of the container iterators have
==>: > : neither iterator based on the other. Instead, member class
==>: > : iterator includes a conversion
==>: > : from member class const_iterator.
==>: >
==>: > : Hope this satisfies your inquiring mind.

: >
: > Only if you did the same for vector, which I doubt.

: Why do you doubt it? I make occasional mistakes, like any mortal, but I'm
: not exactly stupid.

Here `did the same'' didn't mean `didn't allow const-unsafe implicit
conversions''. It meant `did the same as in the paragraph, marked with
"==>:", from your post I was replying to''. In other words `did
the same'' meant that you defined vector<T>::iterator as a real
class rather then just typedeffing it to T*, which causes the
following problem:


: >                                                I bet you still
: > allow an implicit conversion from vector<Derived>::iterator to
: > vector<Base>::iterator.

: Unless the subtleties of template specialization are lost on me (and they
: sometimes are), you'd lose that bet. You're being gratuitously insulting.

No I am not. You simply misunderstood me. I am pretty sure
I'd win that bet. In fact, I'd be willing to bet 10:1.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

In STL iterators, operator*() and operator->(), which return lvalues, are
declared const.  I have to confess that I don't fully understand this;
couldn't the data over which an iterator iterates be regarded as part of the
state of the iterator?

More generally, if A is an object which contains a pointer p to another
object, is there anything general that can be said about whether an accessor
that returns a p should be regarded as const, apart from considerations that
are specific to the problem at hand?  Is const, in this context, merely a
state of mind?

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The keyword 'const', when applied to a member function, means that the state of
the object will not be changed by that function. Since the member functions use
specify will not change the state of the iterator, the functions are declared as
'const'.

Daniel Parker wrote:

> In STL iterators, operator*() and operator->(), which return lvalues, are
> declared const.  I have to confess that I don't fully understand this;
> couldn't the data over which an iterator iterates be regarded as part of the
> state of the iterator?
>
> More generally, if A is an object which contains a pointer p to another
> object, is there anything general that can be said about whether an accessor
> that returns a p should be regarded as const, apart from considerations that
> are specific to the problem at hand?  Is const, in this context, merely a
> state of mind?


[ 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              ]

Daniel Parker wrote:
>
> In STL iterators, operator*() and operator->(), which return lvalues, are
> declared const.  I have to confess that I don't fully understand this;
> couldn't the data over which an iterator iterates be regarded as part of the
> state of the iterator?

No - the iterator contains the information that locates the information,
and not the information itself. The prototypical iterator is a standard
C pointer, which does not contain the information it points to (unless
it's a void ** that points to itself!)

> More generally, if A is an object which contains a pointer p to another
> object, is there anything general that can be said about whether an accessor
> that returns a p should be regarded as const, apart from considerations that
> are specific to the problem at hand?  Is const, in this context, merely a
> state of mind?

I don't understand the question. Can you describe what you mean in terms
a an interator that happens to be a standard C pointer?


[ 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              ]

Daniel Parker <danielp@nospam.com> wrote:
: In STL iterators, operator*() and operator->(), which return lvalues, are
: declared const.  I have to confess that I don't fully understand this;
: couldn't the data over which an iterator iterates be regarded as part of the
: state of the iterator?

: More generally, if A is an object which contains a pointer p to another
: object, is there anything general that can be said about whether an accessor
: that returns a p should be regarded as const, apart from considerations that
: are specific to the problem at hand?  Is const, in this context, merely a
: state of mind?

That's pretty analogous to the difference between a const
pointer and a pointer to const.

int a[2];                 vector<int> a(2);
int* const cpi = a[0];    vector<int>::iterator const cpi = a.begin();
int const* pci = a[0];    vector<int>::const_iterator pci = a.begin();
*cpi = 3; // value of     *cpi = 3; // ditto. In fact, if operator *()
          // ic doesn't             // wasn't const, this would have been
          // change                 // illegal, because ic is const.

*pci = 0; // illegal      *pci = 0; // ditto

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

Daniel Parker wrote:
>
> In STL iterators, operator*() and operator->(), which return lvalues, are
> declared const.  I have to confess that I don't fully understand this;
> couldn't the data over which an iterator iterates be regarded as part of the
> state of the iterator?

Since the data is already owned by the container, I wouldn't add it
to the state of the iterator as well. The iterator tells you where the
data is, and allows you to access it. However, it doesn't contain it.
Similary, the data is not destroyed when the iterator is destroyed,
and it is not copied when the iterator is copied.

>
> More generally, if A is an object which contains a pointer p to another
> object, is there anything general that can be said about whether an accessor
> that returns a p should be regarded as const, apart from considerations that
> are specific to the problem at hand?  Is const, in this context, merely a
> state of mind?

IMHO the general rule would be:

- If the pointed-to object is conceptionally part of the object pointing
  to it, the const should be promoted

- If the pointed-to object is conceptionally independant of the object
  pointing to it, the constness of the access depends on the semantics
  of the object - that may include promoting constness, however in
  general it's either always const, or never.


[ 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              ]

In article <6ngfi1$5k$1@news.interlog.com>,
  "Daniel Parker" <danielp@nospam.com> wrote:
>
> In STL iterators, operator*() and operator->(), which return lvalues, are
> declared const.  I have to confess that I don't fully understand this;
> couldn't the data over which an iterator iterates be regarded as part of the
> state of the iterator?

Certainly not in this case.  The abstraction in question is very close
to that of a C++ pointer; even if a pointer is const (T* const, not T const*),
you can modify what it is pointing to.

> More generally, if A is an object which contains a pointer p to another
> object, is there anything general that can be said about whether an accessor
> that returns a p should be regarded as const, apart from considerations that
> are specific to the problem at hand?  Is const, in this context, merely a
> state of mind?

I don't think so.  If what is pointed to is logically part of the object
which contains the pointer, fine.  Otherwise, no.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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              ]

Daniel Parker wrote:

> In STL iterators, operator*() and operator->(), which return lvalues, are
> declared const.

A const_iterator is an iterator to a constant value. An iterator which
is
const is an iterator which doesn't move.

> More generally, if A is an object which contains a pointer p to another
> object, is there anything general that can be said about whether an accessor
> that returns a p should be regarded as const, apart from considerations that
> are specific to the problem at hand?  Is const, in this context, merely a
> state of mind?

It depends on the semantics of the object. If you read french, see:
  http://pages.pratique.fr/~bonnardv/guide_cpp.html#class.pointeur
for some comments about that.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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              ]

jkanze@otelo.ibmmail.com wrote in message
<6nj0g0$hqv$1@nnrp1.dejanews.com>...
>In article <6ngfi1$5k$1@news.interlog.com>,
>  "Daniel Parker" <danielp@nospam.com> wrote:
>>
>> In STL iterators, operator*() and operator->(), which return lvalues, are
>> declared const.  I have to confess that I don't fully understand this;

Thanks for the responses; it goes to show that after all these years I still
mix up pointer to const and const pointer.  I particularly liked Valentin
Bonnard's observation that you can't do much iterating with an iterator that
is const.

But on a related matter, can anyone suggest why P.J. Plauger would implement
a list iterator in his STL library that makes const_iterator derive from
iterator?  That allows

std::list<Node> list;

std::list<Node>::const_iterator p;
std::list<Node>::iterator q;

q = p;

Surely that isn't right?  I believe Robert Murray suggested the opposite
once, in C++ Strategies and Tactics (1993), of deriving iterator from
const_iterator, but I don't see how that would work either (without
casting); he has a const List& as an argument in the const_iterator
constructor, but stores it as a List*.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]