🚀 go-pugleaf

Steve Willer wrote:
> ... the (April '95) draft standard auto_ptr doesn't have an operator
> bool() function in it, making it inconvenient to write "if (ptr)" type
> constructs. Is there some sort of reason for that? I know that implicit type
> conversion is generally a bad thing, but I can't see how this one would be
> particularly dangerous (also, can the new explicit keyword be used on the
> return type?).

Automatic conversion only to bool would not, as Steve suggests, be
likely to cause problems.  However, once converted to bool, it would
then convert freely to int, char, or double.  

> the latest iostream standard has an operator bool() and an operator!() 
> defined. So why not be consistent?

This problem is serious enough that the Core working group has resolved
to consider restricting conversion sequences involving bool. 

If the Core WG doesn't resolve the problem, the Library WG will replace
iostream's operator bool() with operator void*().  (This alternative is 
less attractive in the case of auto_ptr<>, where it would cause confusion.)

Automatic conversions can be a problem in general, but the problems 
with automatic conversions to a numeric type are ridiculous.  
Compatibility with C has its downside. 

As a side note...  The problem with automatic conversions is not
only that the conversion may be called unexpectedly; the 
possibility of the conversion affects overloading, so it may 
force you to add "unnecessary" casts to guide the compiler to 
the correct choice of function to call.

Nathan Myers
ncm@cantrip.org   http://www.cantrip.org/
---
[ 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.
]

In article <313ddfd9.16044605@sqarc.sq.com> willer@carolian.com (Steve
Willer) writes:

|> I hope I don't sound like I'm second-guessing people who are likely much more
|> experienced than I am in library design, but I have another question about
|> auto_ptrs.

|> Specifically, the (April '95) draft standard auto_ptr doesn't have an operator
|> bool() function in it, making it inconvenient to write "if (ptr)" type
|> constructs. Is there some sort of reason for that? I know that implicit type
|> conversion is generally a bad thing, but I can't see how this one would be
|> particularly dangerous (also, can the new explicit keyword be used on the
|> return type?).

The real danger is in the following:

	auto_ptr< T >	p1 ;
	auto_ptr< T >	p2 ;

	if ( p1 == p2 ) ...

You thought you were comparing two pointers, but in fact, you are
comparing the results of comparing these pointers to null.  The
expression in the if (illegal with the current definition) will cause
the conversion operator bool to be called for both pointers.

|> Now, Meyers's latest book describes an auto_ptr that has member templates, so
|> obviously the April WP does not have the latest auto_ptr, but I get the
|> impression even the current auto_ptr doesn't have an operator bool(). My
|> reading of Meyers's discussion of smart_ptrs mentions that operator bool()
|> would allow comparison of two different types of auto_ptrs, but the latest
|> iostream standard has an operator bool() and an operator!() defined. So why not
|> be consistent?

I agree.  But the better solution would be to remove the operators
from iostream:-).

More likely, the problem is that an auto_ptr looks very much like a
regular pointer, and people often compare pointers.  How often have
you wanted to actually compare two streams:-)?

|> In fact, as another idea, what about defining a new class, say, explicit_bool?
|> explicit_bool would have an operator bool() defined, but would also have an
|> operator==(const explicit_bool &rhs) and operator!=(const explicit_bool &rhs)
|> defined as a private function. It would also have operator!() return an
|> explicit_bool. This way, constructs such as "if (myptr)" and "if (!myptr)"
|> would work, but "if (myptr==otherptr)" and "if (myptr != otherptr)" wouldn't
|> compile.

I'm not sure what this would buy us.  The `obvious' solution for
auto_ptr is to add an `isValid' function; in the meantime, just use
`if ( ptr.get() == NULL )'.  (Another possible alternative is to
provide a conversion operator to the underlying pointer type, so that
you can write `if ( ptr == NULL )', just as you would with a normal
pointer.  I personally don't like the fact that this might result in
free pointers to the memory without having called a function
explicitly.) 

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone

"Nathan Myers, http://www.cantrip.org/" <ncm@cantrip.org> wrote:

>Automatic conversions can be a problem in general, but the problems 
>with automatic conversions to a numeric type are ridiculous.  
>Compatibility with C has its downside. 
>
>As a side note...  The problem with automatic conversions is not
>only that the conversion may be called unexpectedly; the 
>possibility of the conversion affects overloading, so it may 
>force you to add "unnecessary" casts to guide the compiler to 
>the correct choice of function to call.

Sounds like another reason to permit the keyword "explicit" to apply to
conversion operators. I really don't see why the committee is so
resistant to this concept. I think the following would be a perfectly
satisfactory usage:

   class istream : public ...
   {
     ...
     explicit operator bool() const;
     ...
   };

   void f()
   {
     while (bool(cin))
       // do something
   }

Its clear. Its easy to remember. Its clean. Same would work for
auto_ptr<>.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent 
those of my employer.
---
[ 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 
]

Pablo Halpern wrote:
> I really don't see why the committee is so
> resistant to this concept. I think the following would be a perfectly
> satisfactory usage:
> 
>    class istream : public ...
>    {
>      ...
>      explicit operator bool() const;
>      ...
>    };
> 
>    void f()
>    {
>      while (bool(cin))
>        // do something
>    }

There's an awful lot of code out there that says "while (cin) ...", and 
no one wants to rewrite it all just to coax it through the new compiler. 
That's probably the reason.

-- 

Ciao,
Paul D. DeRocco
---
[ 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                             ]

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

>The real danger is in the following:
>
>	auto_ptr< T >	p1 ;
>	auto_ptr< T >	p2 ;
>
>	if ( p1 == p2 ) ...

Well, there is obviously a solution of either modifying the way bool
works (so it can't be compared to another), or perhaps creating a new
explicit_bool type.

But what about this solution as a way to implement an auto_ptr:

class explicit_bool {
   bool state_;
   bool operator==(const explicit_bool &rhs) const;
   bool operator!=(const explicit_bool &rhs) const;
public:
   explicit_bool(bool state) { state_ = state; }
   operator bool() { return state_; };
};

template <class T> class auto_ptr {
public:
   /* explicit */ auto_ptr(T *p=0): pointee(p) {}
//  template<class U> auto_ptr(auto_ptr<U> &rhs):
pointee(rhs.release()) {}
   auto_ptr(auto_ptr<T> &rhs): pointee(rhs.release()) {}
   ~auto_ptr() { delete pointee; }
//  template<class U> auto_ptr<T>& operator=(auto_ptr<U> &rhs) {
   auto_ptr<T> &operator=(auto_ptr<T> &rhs) {
      if (this != &rhs) reset(rhs.release());
      return *this;
   }
   T& operator*() const {return *pointee;}
   T* operator->() const {return pointee;}
   T* get() const {return pointee;}
   T* release() {
      T *oldPointee = pointee;
      pointee = 0;
      return oldPointee;
   }
   operator explicit_bool() { return explicit_bool(pointee != 0); }
   explicit_bool operator!() { return explicit_bool(pointee == 0); }
//   operator bool() {return (pointee != 0);}  // apparently not part
of the std
//   bool operator!() {return (pointee == 0);} // ditto
   void reset(T *p=0) {delete pointee; pointee = p;}
private:
   T *pointee;
};

class myclass{};
int main(char,char**) {
   auto_ptr<myclass> a1,a2;

   a1 = a2;
   a1 == a2;
   a1 != a2;
   if (a1);
   if (!a1);

   return 0;
}

To tell you the truth, I'm not 100% sure this would work properly,
because I don't have my C++ books here (I'm at home sick), and my
compiler doesn't have "bool" as a built-in type (it's a class). With
my current compiler, the "a1==a2" and "a1!=a2" lines don't work
(illegal structure operation), which is exactly how I'd expect it. The
"if (a1)" line doesn't compile either, but wouldn't it work if "bool"
was a built-in type? This would mean an implicit conversion to
explicit_bool and then to bool, but my (somewhat faulty)  memory is
that that's legal.

Even if that's not legal, what about defining "template <class T>
template<class U>auto_ptr<T>::operator==(const auto_ptr<U>& rhs)" and
the equivalent operator!= as private?
---
[ 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                             ]

Pablo Halpern wrote:
> 
> "Nathan Myers, http://www.cantrip.org/" <ncm@cantrip.org> wrote:
> 
> >Automatic conversions can be a problem in general, but the problems
> >with automatic conversions to a numeric type are ridiculous.
> >Compatibility with C has its downside.
> >
> >As a side note...  The problem with automatic conversions is not
> >only that the conversion may be called unexpectedly; the
> >possibility of the conversion affects overloading, so it may
> >force you to add "unnecessary" casts to guide the compiler to
> >the correct choice of function to call.
> 
> Sounds like another reason to permit the keyword "explicit" to apply to
> conversion operators. I really don't see why the committee is so
> resistant to this concept. I think the following would be a perfectly
> satisfactory usage:
> 
>    class istream : public ...
>    {
>      ...
>      explicit operator bool() const;
>      ...
>    };
> 
>    void f()
>    {
>      while (bool(cin))
>        // do something
>    }
> 
> Its clear. Its easy to remember. Its clean. Same would work for
> auto_ptr<>.
> 

I'd agree with that.  An explicit cast from a string to a <charT> * would be 
nice as well ... much cleaner than c_str() and data().
---
[ 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                             ]

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:

>The real danger is in the following:
>
>	auto_ptr< T >	p1 ;
>	auto_ptr< T >	p2 ;
>
>	if ( p1 == p2 ) ...
>
>You thought you were comparing two pointers, but in fact, you are
>comparing the results of comparing these pointers to null.  The
>expression in the if (illegal with the current definition) will cause
>the conversion operator bool to be called for both pointers.

> ...  The `obvious' solution for
>auto_ptr is to add an `isValid' function; in the meantime, just use
>`if ( ptr.get() == NULL )'.  (Another possible alternative is to
>provide a conversion operator to the underlying pointer type, so that
>you can write `if ( ptr == NULL )', just as you would with a normal
>pointer.  I personally don't like the fact that this might result in
>free pointers to the memory without having called a function
>explicitly.) 

Why not just have

private:
  bool auto_ptr<T>::operator==(const auto_ptr<T>&)

public:
  bool auto_ptr<t>::operator==(void *p)
    { return (this->get() == NULL) && (p == NULL); }

The latter would return true if and only if both the auto_ptr and the
passed pointer were NULL.
-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent 
those of my employer.
---
[ 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                             ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:

>>      while (bool(cin))
>There's an awful lot of code out there that says "while (cin) ...", and 
>no one wants to rewrite it all just to coax it through the new compiler. 
>That's probably the reason.

Right, but that's not really my point. My point is that allowing the
keyword "explicit" for conversion operators would make a lot of sense.
If the committee ever did want to eliminate implicit conversion from
istream to bool, then they could simply make it explicit. Sure, people
would have to change their code, but at least the change would be
mnemonic and readable. More importantly would be the addition of 

   template <class T> class auto_ptr {
     ...
     explicit operator bool() const;
   };

This would be a clean syntax that would allow

   auto_ptr<foo> x;
   while (bool(x))
     ...

I shouldn't have confused the issue by using cin as my example.
-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent 
those of my employer.


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