In article <3A30FE6A.AC7C11C2@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:

> Christopher Eltschka wrote:

> > IMHO a conversion operator should only convert to something which
> > has a superset of values (f.ex. a Square class could have an
> > automatic conversion to Rectangle, so you can pass Square to any
> > function expecting a value of type Rectangle).

> In most cases, this works fine without defining conversion
> operators.  If a square is derived from a rectangle, it converts
> fine just based on the constructors.

Christopher mentioned this case, stating that square should NOT derive
from rectangle.  This is a very old OO discussion: typically, classes
like Rectangle, or Elipse, will have functions allowing the
independant modification of the X and Y attributes.  Obviously, if I
have a Square, and modify X without modifying Y, it ceases to be a
square.  If my Rectangle class supports this operation, then there are
cases where a Square cannot be substituted for a Rectangle, mainly,
anywhere where these modifications take place.

IMHO, the error is in failing to make something like Rectangle
immutable.  But that's a very personal believe, and not at all shared
by the entire OO community.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie wrote:
>
> rado42 wrote:
> >
> >
> > Bugs like this make me think that cast operators should not be used.
> > They make the things so complicated sometimmes..
>
> Precisely.  Especially when teamed with "converting" constructors.
> Especially onerous are when the cast is to some simple thing like
> char* or an integral type that is widely convertable to other things.
>
> This is why it's more practical to use "operator void*" as a status
> indicator than "operator bool".  void* doesn't implicilty convert
> to too much, where ints are used all over the place.

IMHO a conversion operator should only convert to something which
has a superset of values (f.ex. a Square class could have an automatic
conversion to Rectangle, so you can pass Square to any function
expecting a value of type Rectangle).

The conversion to bool generally comes from types which themselves have
more values. Indeed, it's usually used to enable if(foo) for objects of
the class to be tested against one specific value (or one specific
state). IMHO this is a bad usage anyway, and using operator void*()
only cures the symptoms.

Automatic conversion, if correctly uses, IMHO is a sort of "is-a"
(not exactly the same as the "inheritance is-a", as can be seen that
it makes perfect sense to have a conversion Square->Rectangle, but
inheriting Square from Rectangle is plain wrong).

Indeed, implicit conversion is IMHO much closer to the common use of
"is-a" than inheritance (a square is a rectangle). Inheritance is less
an "is-a" than a "behaves-like-a". However note that inheritance
always includes "conversion is-a": it automatically includes a
conversion to the base type. Also, it implies corresponding
conversions on pointers: A pointer to Derived is-a pointer to Base -
but only in the conversion sense: Derived* can be converted to Base*,
but a Base** cannot point to a Derived*.

Unfortunately there are many cases of bad conversions in C (and
therefore C++), and some more in C++ which are a result from C
compatibility.
The following list may not be complete, but it contains the IMHO most
problematic implicit conversions (whenever "float" or "int" is
mentioned, it represents the whole corresponding class of types):

   float -> int
   bool  -> int
   int   -> bool
   T*    -> bool
   char  -> int   (well, actually it's the double-use of char as
   int   -> char   character and as a small number)

There are also a few conversions which are wrong from purist view, but
are needed anyway (because without them you'd be casting all the way):

   long -> int -> short
   long double -> double -> float

And finally, there's one case where the idiom even went into the
standard library:

    std::ios -> void*

Now, if conversions were exclusively used for is-a, you could even
allow "conversion chains" without the fear of confusion: If a
square is a rectangle, and a rectangle is a polygon, then a square
is a polygon, and therefore the conversion sequence
square->rectangle->polygon should be allowed.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Christopher Eltschka wrote:
>
> IMHO a conversion operator should only convert to something which
> has a superset of values (f.ex. a Square class could have an automatic
> conversion to Rectangle, so you can pass Square to any function
> expecting a value of type Rectangle).
>
In most cases, this works fine without defining conversion operators.
If a square is derived from a rectangle, it converts fine just based
on the constructors.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Fri,  8 Dec 2000 14:57:43 GMT, Christopher Eltschka <celtschk@physik.tu-m=
uenchen.de> pisze:

> Now, if conversions were exclusively used for is-a, you could even
> allow "conversion chains" without the fear of confusion: If a
> square is a rectangle, and a rectangle is a polygon, then a square
> is a polygon, and therefore the conversion sequence
> square->rectangle->polygon should be allowed.

I believe that finding a chain among arbitrary conversions and
conversion templates is an undecidable problem.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <9015s3$df5$1@nnrp1.deja.com>,
  Gene Bushuyev <gbush@my-deja.com> wrote:
> Because you defined:
> operator int() const { return i_; }
> that is used for comparison rather than non-const operator==
>
> >    operator int() const { return i_; }
> >
> >    bool operator==( int i )
>
> [snip]
>
> > but my compiler (gcc) doesn't complain. And most amazing (at least
to
> > me) is the output of this program:
>
> -------------------------------------
> Gene Bushuyev
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your
bookmarks.     ]
>
>

Bugs like this make me think that cast operators should not be used.
They make the things so complicated sometimmes..

Rado
--


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <903sa1$jsm$1@nnrp1.deja.com>,
  rado42 <rado42@my-deja.com> wrote:

> Bugs like this make me think that cast operators should not be used.
> They make the things so complicated sometimmes..

Type conversion operators *should* rarely be used.  They are an
extreme form of operator overloading, and like overloading, can result
in real obfuscation.  Also like operator overloading, there are a few
specific cases where they are perfectly appropriate.  (Proxy classes,
for example, come to mind.)

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orientie objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

rado42 wrote:
>
>
> Bugs like this make me think that cast operators should not be used.
> They make the things so complicated sometimmec..

Precisely.  Especially when teamed with "converting" constructors.
Especially onerous are when the cast is to some simple thing like
char* or an integral type that is widely convertable to other things.

This is why it's more practical to use "operator void*" as a status
indicator than "operator bool".  void* doesn't implicilty convert
to too much, where ints are used all over the place.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hi,

Consider the following example:

#include <iostream>
using std::cout;

class A
{
private:
   int i_;

public:
   A( int i ) : i_( i ) {}
   A( const A& a ) : i_( a.i_ ) { cout << "COPY" << endl; }
   ~A() {}

   operator int() const { return i_; }

   bool operator==( int i )
   {
      i_ = 42;
      return i_ == i;
   }
};

int main()
{
   const A a = 5;

   cout << a << endl;

   if( a == 5 ) cout << "a==5" << endl;
   if( !(a == 5) ) cout << "!(a==5)" << endl;
   if( a == 42 ) cout << "a==42" << endl;

   cout << a << endl;
   cout << A(a) << endl;

   return 0;
}

I wonder if this is standard conforming C++, because operator== is not
defined as:

  bool operator==( int i ) const

but my compiler (gcc) doesn't complain. And most amazing (at least to
me) is the output of this program:

dfrey@dpcl006:~/work/test_operator_equal_const > ./t
5
a==5
5
COPY
5
dfrey@dpcl006:~/work/test_operator_equal_const >

This is strange. I don't really understand what's happening and I wonder
what the standard says about this. I suspect, that although there is no
second call to the copy-constructor, a copy is made and used for the
comparison. So I wonder if all the operator== I see in the STL, etc.
make copies for const objects... Can anyone help and explain it? Thanks
in advance...

Regards, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Hammerweg 4, 52074 Aachen, Germany
Tel: +49 (0)241 96106-17, Fax: +49 (0)241 96106-20
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Daniel Frey" <d.frey@aixigo.de> wrote...
> Hi,
>
> Consider the following example:
>
> #include <iostream>
> using std::cout;
>
> class A
> {
> private:
>    int i_;
>
> public:
>    A( int i ) : i_( i ) {}
>    A( const A& a ) : i_( a.i_ ) { cout << "COPY" << endl; }
>    ~A() {}
>
>    operator int() const { return i_; }
>
>    bool operator==( int i )
>    {
>       i_ = 42;
>       return i_ == i;
>    }
> };
>
> int main()
> {
>    const A a = 5;
>
>    cout << a << endl;
>
>    if( a == 5 ) cout << "a==5" << endl;
>    if( !(a == 5) ) cout << "!(a==5)" << endl;
>    if( a == 42 ) cout << "a==42" << endl;
>
>    cout << a << endl;
>    cout << A(a) << endl;
>
>    return 0;
> }
>
> I wonder if this is standard conforming C++, because operator== is not
> defined as:
>
>   bool operator==( int i ) const
>
> but my compiler (gcc) doesn't complain. And most amazing (at least to
> me) is the output of this program:
>
> dfrey@dpcl006:~/work/test_operator_equal_const > ./t
> 5
> a==5
> 5
> COPY
> 5
> dfrey@dpcl006:~/work/test_operator_equal_const >
>
> This is strange. I don't really understand what's happening and I
wonder
> what the standard says about this. I suspect, that although there is
no
> second call to the copy-constructor, a copy is made and used for the
> comparison. So I wonder if all the operator== I see in the STL, etc.
> make copies for const objects... Can anyone help and explain it?
Thanks
> in advance...

Your operator == is not being called because it doesn't meet the
requirement (the object should be non-const).  Instead, the cast
operator (operator int() const) is called and the two ints are
compared.

Why are you surprised?  The compiler explores different ways to
compare your object to an int (5) and finds that the provided
equality operator cannot be used, and the built-in for ints can.

Victor
--
Please remove capital A's from my address when replying by mail



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Victor Bazarov wrote:
>
> Why are you surprised?  The compiler explores different ways to
> compare your object to an int (5) and finds that the provided
> equality operator cannot be used, and the built-in for ints can.

3 colleague all failed to see it - and me. But now you mention it...
it's so... obvious...

Thanks, Daniel

--
Daniel Frey

aixigo AG - Financial Research and Education
Hammerweg 4, 52074 Aachen, Germany
Tel: +49 (0)241 96106-17, Fax: +49 (0)241 96106-20
EMail: D.Frey@aixigo.de

"Operator.. give me the number for 911" (Homer Simpson)

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Daniel Frey wrote:


>
> This is strange. I don't really understand what's happening and I wonder
> what the standard says about this. I suspect, that although there is no
> second call to the copy-constructor, a copy is made and used for the

A copy is being made, but it isn't of your A object.  Since you have
an operator int what is happening in each if statement is that
you are converting a to an "int" and then using the builtin
int-to-int equality operator.

Put a debug message in operator int() and I think you will be more enlightened.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Because you defined:
operator int() const { return i_; }
that is used for comparison rather than non-const operator==


>    operator int() const { return i_; }
>
>    bool operator==( int i )

[snip]

> but my compiler (gcc) doesn't complain. And most amazing (at least to
> me) is the output of this program:

-------------------------------------
Gene Bushuyev


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]