In article <STEVE.95Jun6145158@spokane.ia-us.com>,
Stephen Williams <steve@spokane.ia-us.com> wrote:
>In article <gregorD9Irv5.EtJ@netcom.com> gregor@netcom.com (Greg Colvin) writes:
>
>   >>I think auto_ptr should have an additional member function:
>   >>
>   >>   operator bool() const  { return get() != 0; }
>
>   As the author of the auto_ptr proposal I'm still trying to get the WP to
>   match my proposal, let alone add any new features, but this is kinda cute.
>
>
>Er, not so cute really.

 I tend to oppose _any_ use of operator conversions
that is not very carefully scrutinised. When in doubt -- DONT.

 Conversions and overloading already "clash" and create
ambiguities and confusion. When the conversions are provided by

 i) the system (eg Derived --> Base conversion)
 ii) constructors
 iii) operator conversions

and you also have

 iv) overloading
 v) templates
 vi) default arguments

then you have 6 separate ways to get confused. The "explicit" keyword
helps reduce the impact of (ii). Not defining operator conversions
helps reduce the impact of (iii).  Never using default
arguments reduces the impact of (vi).

In cases where such conversions are needed and will be used often,
I sometimes steal unused operators:

 class string {
  int length;
  char *data;
 public:
  size_t operator +() const { return length; }
  char * operator ~() { return data; }
  bool operator !()const { return !length; }
  ...
 };

 string s .....
 if(!!s) for(int i = 0; i<+s; ++i) fiddle(~s+i);


>I have run into the following error (my own)
>that caused me some consternation and led me to avoid operator bool()
>converstion operators.
>
>If you put an object with such a conversion into a context requiring
>an integral value, I think C++ will convert to bool the perform
>integral promotion. This can be  especially icky when the class is
>intended to represent a pointer.

 Best to avoid even the possibility of this (whether or not
the exact language rules mean you're right or not).

> auto_ptr<char> x = ...;

 WOOPS. You can't do that. You need to say

 auto_ptr<char> x(new char);

and not

 auto_ptr<char> x = new char;

because the C++ rules require the conversion of
the RHS to the type of the LHS and the _copying_ of that rvalue.
That is, the case above _copies_ an auto_ptr object. The one
thing one should NEVER do with them.  (No matter what hackery
is provided to make it appear to work)

> char*y = ...;
>
> int foo = x - y;
> int bar = y - x;
> int bat = foo + x; // ICK! (arguably a typo, but...

 I believe this has been discussed and is still a semi-open
issue. There is a similar problem with conversions to void*.

 In my opinion the way to approach conversions is as
follows: a conversion represents an IS-A relation of values.
(Implicit) Conversions are appropriate for mono-morphisms --
structure preserving injective mappings.

 The conversion Derived* --> Base* is just one
example of this (and it is not right unless Derived really is-a Base).

 If you think a auto-ptr is-a bool, provide the conversion.
Otherwise do not. In this case, I do not think a pointer of ANY kind
is-a bool.

Note: unfortunately C does NOT follow this rule. The conversion
long --> int clearly isn't injective (value preserving).
The conversion T* --> bool isn't either.

Anything that throws away information (like converting a pointer
to a bool) should require a cast (or other explicit means of
extracting that specific information).

In some cases, one may break this rule and provide an automatic
conversion for a non-injective structure preserving mapping,
but this should be done with care.

["structure preserving" means something like:

 real is-a complex.
 real a,b;

 assert( complex(a+b) == complex(a) + complex(b) );

-- for EACH method of the classes. So for example the mapping
int --> float is NOT structure preserving in C, despite being
a mathematical injection (usually), because

 float ( i/j ) != float(i)/float(j);

Preserving structure is essential for automatic conversions
because it IS the rule required for referential transparency:
it doesn't matter where the conversions are done, so you do
not have to study the code -- if it compiles at all without
ambiguity it will do the right thing]

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3r6ecv$cre@boson.epita.fr> Loic Tregan@epita.fr (tregan_l)
writes:

|> In article <KANZE.95Jun7130952@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:


|> -=)> I agree, and would also oppose any implicit conversions.  On the other
|> -=)> hand, adding a function is_valid is perhaps not a bad idea.

|>   I much prefer a few keywords used in many cases than a keyword by case, and I
|> think there is always too many keywords in C++.

The name of a member function is not a keyword.

|>   For instance, is " p == NULL " less clear, less comprehensive than
|>   "p.is_valid()" ??

Actually, another alternative would be to add an implicit conversion
operator (operator T*()) to auto_ptr.  I'd want a detailed analysis
before doing so, though, as conversion operators typically end up
being called when you least expect (or want) them.

Also: `p.is_valid()' *is* clearer and more explicit than `p == NULL'.
It says exactly what is meant.

Using NULL as an invalid pointer is a widespread convention, of
course.  So widespread in the C/C++ world that the difference in
readability is probably negligible in this case.  But you don't really
mean to say that it is difficult to understand what `is_valid' means,
do you?

|>   For instance, "f() = 0" was choosen against smthg like " abstract f()".

Because in this case, it would have required a new keyword, and not
just an added symbol with limited scope.
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <STEVE.95Jun6145158@spokane.ia-us.com>, steve@spokane.ia-us.com (Stephen Williams) writes:

-=)> In article <gregorD9Irv5.EtJ@netcom.com> gregor@netcom.com (Greg Colvin) writes:
-=)>    In article <3qkvvt$nae@news0.cybernetics.net> chip@cybernetics.net (Chip Salzenberg) writes:
-=)>    >According to mlg@scr.siemens.com (Michael Greenberg):
-=)>    >>I think auto_ptr should have an additional member function:
-=)>    >>
-=)>    >>   operator bool() const  { return get() != 0; }
-=)>    >
-=)>    >Yes, as well as:
-=)>    >
-=)>    >    bool operator ! () const  { return get() == 0; }
-=)>    >

   No !!

   if( p ) ...  makes your source unreadable !
  I always write if( p != NULL ) ..to explicitly convert void* to bool.

 It's always the same fight : programmers who came from C against who came from
Pascal or Ada ... And I think that the aim of C++ is not to use C style tricky
syntax. ( well, I like to use C++ in this way ).

In article <KANZE.95Jun7130952@slsvhdt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:


-=)> I agree, and would also oppose any implicit conversions.  On the other
-=)> hand, adding a function is_valid is perhaps not a bad idea.

  I much prefer a few keywords used in many cases than a keyword by case, and I
think there is always too many keywords in C++.

  For instance, is " p == NULL " less clear, less comprehensive than
  "p.is_valid()" ??

  For instance, "f() = 0" was choosen against smthg like " abstract f()".

In article <3r6e3g$cre@boson.epita.fr> Loic Tregan@epita.fr (tregan_l)
writes:

|> In article <STEVE.95Jun6145158@spokane.ia-us.com>, steve@spokane.ia-us.com (Stephen Williams) writes:

|> -=)> In article <gregorD9Irv5.EtJ@netcom.com> gregor@netcom.com (Greg Colvin) writes:
|> -=)>    In article <3qkvvt$nae@news0.cybernetics.net> chip@cybernetics.net (Chip Salzenberg) writes:
|> -=)>    >According to mlg@scr.siemens.com (Michael Greenberg):
|> -=)>    >>I think auto_ptr should have an additional member function:
|> -=)>    >>
|> -=)>    >>   operator bool() const  { return get() != 0; }
|> -=)>    >
|> -=)>    >Yes, as well as:
|> -=)>    >
|> -=)>    >    bool operator ! () const  { return get() == 0; }
|> -=)>    >

|>    No !!

|>    if( p ) ...  makes your source unreadable !
|>   I always write if( p != NULL ) ..to explicitly convert void* to bool.

|>  It's always the same fight : programmers who came from C against who came from
|> Pascal or Ada ... And I think that the aim of C++ is not to use C style tricky
|> syntax. ( well, I like to use C++ in this way ).

Actually, even a lot of programmers who came from C prefer to be type
correct.  I've actually worked with people programming in C who wanted
their programs to be readable.
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

The Library working group considered giving auto_ptr an operator X*()  but
decided that an X* operator*() would be safer, if slightly less convenient.
We also considered operator bool(), but decided that "if (ap.get())" was
safer and clearer than "if (ap)" and no less convenient than
"if (ap.is_valid())".

In article <STEVE.95Jun6145158@spokane.ia-us.com>
steve@spokane.ia-us.com (Stephen Williams) writes:

|> In article <gregorD9Irv5.EtJ@netcom.com> gregor@netcom.com (Greg Colvin) writes:


|>    In article <3qkvvt$nae@news0.cybernetics.net> chip@cybernetics.net (Chip Salzenberg) writes:
|>    >According to mlg@scr.siemens.com (Michael Greenberg):
|>    >>I think auto_ptr should have an additional member function:
|>    >>
|>    >>   operator bool() const  { return get() != 0; }
|>    >
|>    >Yes, as well as:
|>    >
|>    >    bool operator ! () const  { return get() == 0; }
|>    >

|>    As the author of the auto_ptr proposal I'm still trying to get the WP to
|>    match my proposal, let alone add any new features, but this is kinda cute.


|> Er, not so cute really. I have run into the following error (my own)
|> that caused me some consternation and led me to avoid operator bool()
|> converstion operators.

|> If you put an object with such a conversion into a context requiring
|> an integral value, I think C++ will convert to bool the perform
|> integral promotion. This can be  especially icky when the class is
|> intended to represent a pointer.

|>  auto_ptr<char> x = ...;
|>  char*y = ...;

|>  int foo = x - y;
|>  int bar = y - x;
|>  int bat = foo + x; // ICK! (arguably a typo, but...

I agree, and would also oppose any implicit conversions.  On the other
hand, adding a function is_valid is perhaps not a bad idea.
--
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 en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article nae@news0.cybernetics.net, chip@cybernetics.net (Chip Salzenberg) writes:
>According to mlg@scr.siemens.com (Michael Greenberg):
>>I think auto_ptr should have an additional member function:
>>
>>   operator bool() const  { return get() != 0; }
>
>Yes, as well as:
>
>    bool operator ! () const  { return get() == 0; }
>
>Would anyone else like to write this up for the Commitee?

I have put such a request in the comments I am submitting to ANSI.
However, I would like to point out the following:

   -- The chances of a suggestion being adopted *increase* with
      the number of people who request it.

   -- Comp.std.c++ is not an official organ of the Committee, and
      comments made here--however meritorious they may be--will have
      no effect on the standard (unless a Committee member who reads
      this group happens to agree with you, and decides to carry the
      banner on your behalf).

So, I would advise anyone who has a sincere interest in C++ to submit
comments through the *official* channel.  Even comments that you believe
have already been made by someone else are relevant, since the Committee
will (I assume) be more inclined to listen to those comments that are made
repeatedly.

---
Marc Shepherd
Salomon Brothers Inc
shepherd@schubert.sbi.com The opinions I express are no one's but mine!

In article <gregorD9Irv5.EtJ@netcom.com> gregor@netcom.com (Greg Colvin) writes:


   In article <3qkvvt$nae@news0.cybernetics.net> chip@cybernetics.net (Chip Salzenberg) writes:
   >According to mlg@scr.siemens.com (Michael Greenberg):
   >>I think auto_ptr should have an additional member function:
   >>
   >>   operator bool() const  { return get() != 0; }
   >
   >Yes, as well as:
   >
   >    bool operator ! () const  { return get() == 0; }
   >

   As the author of the auto_ptr proposal I'm still trying to get the WP to
   match my proposal, let alone add any new features, but this is kinda cute.


Er, not so cute really. I have run into the following error (my own)
that caused me some consternation and led me to avoid operator bool()
converstion operators.

If you put an object with such a conversion into a context requiring
an integral value, I think C++ will convert to bool the perform
integral promotion. This can be  especially icky when the class is
intended to represent a pointer.

 auto_ptr<char> x = ...;
 char*y = ...;

 int foo = x - y;
 int bar = y - x;
 int bat = foo + x; // ICK! (arguably a typo, but...

--

Stephen 2. Williams
steve@icarus.com

    Fight License Managers! Buy from
    vendors who use honor system!

In article <3qkvvt$nae@news0.cybernetics.net> chip@cybernetics.net (Chip Salzenberg) writes:
>According to mlg@scr.siemens.com (Michael Greenberg):
>>I think auto_ptr should have an additional member function:
>>
>>   operator bool() const  { return get() != 0; }
>
>Yes, as well as:
>
>    bool operator ! () const  { return get() == 0; }
>
>Would anyone else like to write this up for the Commitee?
>--
>            Chip Salzenberg, aka <chip@cybernetics.net>
>     "And remember to worship at the railroad of your choice."
>        -- Mike Nelson, MST3K: "The Amazing Transparent Man"

As the author of the auto_ptr proposal I'm still trying to get the WP to
match my proposal, let alone add any new features, but this is kinda cute.
If you like it enough, you'll just have to do it for yourself: the public get()
function provides all the needed functionality IMHO.

I think auto_ptr should have an additional member function:

   operator bool() const  { return get() != 0; }

This way you can write something like:

  auto_ptr<foo> x = bar() ;
  if (x) { ... }


Comments?

--
Michael Greenberg                      email: mgreenberg@scr.siemens.com
Siemens Corporate Research             phone: 609-734-3347
755 College Road East                  fax: 609-734-6565
Princeton, NJ 08540

According to mlg@scr.siemens.com (Michael Greenberg):
>I think auto_ptr should have an additional member function:
>
>   operator bool() const  { return get() != 0; }

Yes, as well as:

    bool operator ! () const  { return get() == 0; }

Would anyone else like to write this up for the Commitee?
--
            Chip Salzenberg, aka <chip@cybernetics.net>
     "And remember to worship at the railroad of your choice."
        -- Mike Nelson, MST3K: "The Amazing Transparent Man"

mlg@scr.siemens.com (Michael Greenberg) writes:
> I think auto_ptr should have an additional member function:
>
>    operator bool() const  { return get() != 0; }
>
> This way you can write something like:
>
>   auto_ptr<foo> x = bar() ;
>   if (x) { ... }
>
>
> Comments?

IMO this misses the point of auto_ptr, which is that what's inside is
supposed to be allocated for the lifetime of the auto_ptr.

However, there is the case when an auto_ptr gives its value to another
auto_ptr and empties itself. C++ is not able to enforce linear
programming, so the auto_ptr sticks around but empty, so is_valid()
could be useful in that case, but it's a stopgap measure.

In any case, I don't think it should be a conversion operator. I would
call it

        bool    is_valid( void );

...or...

        bool    is_ok( void );

        Tom