🚀 go-pugleaf

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