brenneis@rbdc.rbdc.com wrote:

> template <class T1, class T2>>
> inline bool operator!=(const T1& x, const T2& y) {{
>     return !(x == y);
> }

This isn't a bad thing, though it will obfuscate some error messages
(all of a sudden your 'illegal structure operation' moves into some
header file ).  But it brings up something that's annoied me from the
start of this template business.  Here it is:

template<class T>
T &max ( const T&lhs, const T&rhs )
 {return (lhs>rhs)?lhs:rhs;};

int i = 7000;
long l = 70000L;

cout << max ( l, i ) << endl; // error ... cannot find a match

You can solve it like this:
template<class T, class U>
T &max ( const T&lhs, const U&rhs )
 {return (lhs>rhs)?lhs:rhs;};

but then you have this:

short i = 7000;
long l = 70000L;

cout << max ( l, i ) << endl; // displays 70000, as expected
cout << max ( i, l ) << endl; // unexpected? 4462 (MSVC4)

This is one of the reasons we need such a thing as
CTTI ( new buzword, jot it down, use it in your resume ).  That's
compile time type information.  Perhaps only for use in templates?

What do you think?

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  No man's life, liberty, or property
C++, OOD, OOA, OOP,      |  are safe, when the legislature is in
OOPs, I forgot one ...   |  session.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steven W. Brenneis (brenneis@rbdc.rbdc.com) wrote:
>
> Here is an interesting problem.  Consider the following (using the STL):

[snip]

> Microsoft Visual C++ version 4.0 rejects this syntax, stating that
> there is no conversion from list<string>::const_iterator to
> list<string>::iterator.  Specifically, it is selecting the overload
> of list<class T>::end() which returns iterator and not that which
> returns const_iterator.

I've been using VC++ 4.0, xlC on AIX and g++. I've found that on many
occasion, VC++ is more picky or even wrong on conversions and its
handling of constness. I would advise to try it on another compiler
before blaming STL.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

jason@cygnus.com (Jason Merrill) wrote:

[snip]

>But there *is* a conversion from list::iterator to list::const_iterator;
>that should do the trick.  At least there is in the HP implementation...

We are using HP's implementation of STL in both the DEC and Microsoft
cases.  Therefore, there is no difference between the libraries.
Also, there is a constructor available to create a const_iterator from
an iterator, but Bruce Visscher has hit the dilemma right on.  The !=
operator is looking for same types.  Use of the constructor for this
conversion would require the compiler to make both the template
substitution and to create a temporary object for the comparison all
in one operation.  Given the generally conservative nature of the
standard, this seems unlikely.  I am becoming more convinced that the
Visual C++ compiler is right and that the STL should implement its
relational operators with independent classes, e.g.

template <class T1, class T2>>
inline bool operator!=(const T1& x, const T2& y) {{
    return !(x == y);
}
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> Steven W Brenneis <brenneis@rbdc.rbdc.com> writes:

> Here is an interesting problem.  Consider the following (using the STL):
> class string;

> typedef list<string> StringList;

> class AClass {
>         .
>         .
>         .
> public:
>     void PrintList();
>     void TextOut(const string&);
>         .
>         .
>         .
> protected:
>     StringList MyList;
> };

> void AClass::PrintList() {
>     StringList::const_iterator ci;
>     for (ci = MyList.begin();
>            ci != MyList.end();
>            ++ci)
>         TextOut((string&)(*ci));
> }

> Microsoft Visual C++ version 4.0 rejects this syntax, stating that
> there is no conversion from list<string>::const_iterator to
> list<string>::iterator.  Specifically, it is selecting the overload
> of list<class T>::end() which returns iterator and not that which
> returns const_iterator.  There is no typecast or conversion in the
> STL between these iterator types.

But there *is* a conversion from list::iterator to list::const_iterator;
that should do the trick.  At least there is in the HP implementation...

Jason


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> Microsoft Visual C++ version 4.0 rejects this syntax, stating that
> there is no conversion from list<string>::const_iterator to
> list<string>::iterator.  Specifically, it is selecting the overload
> of list<class T>::end() which returns iterator and not that which
> returns const_iterator.  There is no typecast or conversion in the
> STL between these iterator types.  If PrintList()

---

> The question for you standards experts is:  Which compiler is
> correct?  If Microsoft is correct (which I strongly suspect), must we
> use iterator versus const_iterator in non-const functions, even
> though the access to the contained object is const?  If Digital is
> correct, what rules would compiler constructors use to select
> overloads which differ in return type and const specification only?

What you have here appears to be a differance in implementations
of the STL ... it's not the compiler's decision whether there's a conversion
from ClassX::iterator to ClassX::const_iterator ... that depends only on the
type of the iterators ...


Since the types of list<>::iterator and list<>::const_iterator are
implementation defined, it's up to the library author to decide whether to
have one.

The decision not to have iterator convertable to const_iterator, IMHO,
would be a poor one.


Unless you're compiling the same STL files on both compilers, that's it.

If you ARE, let's see the iterators, because if DEC is GUESSING that maybe
there should be a conversion from iterator to const_iterator, it's broken.
<G>


--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say, tell my
C++, OOD, OOA, OOP,      |  employer, but if you don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Here is an interesting problem.  Consider the following (using the STL):

class string;

typedef list<string> StringList;

class AClass {
        .
        .
        .
public:
    void PrintList();
    void TextOut(const string&);
        .
        .
        .
protected:
    StringList MyList;
};

void AClass::PrintList() {
    StringList::const_iterator ci;
    for (ci = MyList.begin();
           ci != MyList.end();
           ++ci)
        TextOut((string&)(*ci));
}

Microsoft Visual C++ version 4.0 rejects this syntax, stating that
there is no conversion from list<string>::const_iterator to
list<string>::iterator.  Specifically, it is selecting the overload
of list<class T>::end() which returns iterator and not that which
returns const_iterator.  There is no typecast or conversion in the
STL between these iterator types.  If PrintList() is declared const,
the correct overload, the one that returns const_iterator, is
selected by the compiler and the syntax error is gone.  This would be
an acceptable situation except for those functions which cannot be
declared const, but for which const_iterator is the desired iterator.

The kicker here is that the version 5.2 C++ compiler for VAX/VMS
accepts this syntax without complaint.  It would seem the DEC
compiler intuits that the const_iterator overload is the desired
selection.  Bizarre, but possible.

The question for you standards experts is:  Which compiler is
correct?  If Microsoft is correct (which I strongly suspect), must we
use iterator versus const_iterator in non-const functions, even
though the access to the contained object is const?  If Digital is
correct, what rules would compiler constructors use to select
overloads which differ in return type and const specification only?

Thanks.

---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]