Oleg Zabluda wrote in message <6cdppl$c02@marianna.psu.edu>...

>It is hard for me to imagine how Microsoft and Plauger managed to
>inadvertingly cause this behaviour for set. For vector, it wouldn't
>surprize me. Either way (inadvertingly or on purpose), this is yet
>another example of the braindead Microsoft and Plauger's coding. Keep
>them coming.

Wouldn't it make sense if MS/Plauger used pointers?  I think they would be
conforming to standard, and would also exhibit this behavior right?



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

Tom McKearney <no@spam.com> wrote:
: Oleg Zabluda wrote in message <6cdppl$c02@marianna.psu.edu>...

: >It is hard for me to imagine how Microsoft and Plauger managed to
: >inadvertingly cause this behaviour for set. For vector, it wouldn't
: >surprize me. Either way (inadvertingly or on purpose), this is yet
: >another example of the braindead Microsoft and Plauger's coding. Keep
: >them coming.

: Wouldn't it make sense if MS/Plauger used pointers?  I think they would be
: conforming to standard, and would also exhibit this behavior right?

Right. That's why it wouldn't surprize me for vector, where
iterators can be just a typedef for a pointer (but shouldn't
be). For set, however, it does surprize me, since iterator
is a pointer to a tree node, therefore it must be a real class.

Just to see how bad it is, I overcame my natural disgust to MS
products and wrote the following piece of code:

#include <set>
#include <iostream>

int main()
{
        std::set<int> si;
        si.insert(2);
        std::set<double>::iterator li = si.begin();
        std::cout << *li << std::endl;
        return 0;
}

This compiles and links with MSVC 5.0 without a single warning
(except a bunch of regular BD (BrainDead) "identifier truncated"
warnings). The output of this program is:
-7.84591e+298.

I didn't dare to try ``*li = 0''. You try it if you are brave enough.

Jeez. It's worse then I thought. The original poster complained that
there was an impliit conversion from set<derived>::iterator to
set<base>::iterator. The truth of the matter is that there is an
implicit conversion for any two, possibly totally inrelated, types.

Sure enough, it's perfectly compliant as well.

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              ]

Erik Badger <erikba@attachmate.com> wrote:
: I have an iterator of a container of a base class that I wish to use to
: iteratate through a container of a derived class.  I am using
: MSVC5(sp3).  If I use the default version of STL provided with VC this
: works fine, however if I use SGI STL(3.0)  I get an error that the =
: operator cannot convert from the derived class's iterator type to the
: parent's iterator type.

: class foo
: {
: };
: class foobar : public foo
: {
: };

: typedef std::set<foo> SetFoo;
: typedef std::set<foobar> SetFooBar;

: {
:     SetFoo::iterator i;
:     SetFooBar FooBar;

:     i=FooBar.begin();    // error with SGI STL 3.0, but not with VC STL
: }

: Can anyone tell me which behavior is conformant to the standard?

Both are conformant. The standard doesn't say that
Container<Derived>::iterator should be convertible to
Container<Base   >::iterator, but it does not say that
it must not be convertible either. I think it should be
explicitly banned. It is desrcribed in great detail in
Cline and Lomov's C++ FAQ why.

It is hard for me to imagine how Microsoft and Plauger managed to
inadvertingly cause this behaviour for set. For vector, it wouldn't
surprize me. Either way (inadvertingly or on purpose), this is yet
another example of the braindead Microsoft and Plauger's coding. Keep
them coming.

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              ]

I have an iterator of a container of a base class that I wish to use to
iteratate through a container of a derived class.  I am using
MSVC5(sp3).  If I use the default version of STL provided with VC this
works fine, however if I use SGI STL(3.0)  I get an error that the =
operator cannot convert from the derived class's iterator type to the
parent's iterator type.

class foo
{
};
class foobar : public foo
{
};

typedef std::set<foo> SetFoo;
typedef std::set<foobar> SetFooBar;

{
    SetFoo::iterator i;
    SetFooBar FooBar;

    i=FooBar.begin();    // error with SGI STL 3.0, but not with VC STL
}

Can anyone tell me which behavior is conformant to the standard?

Thanks
    -Erik



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