In article <28i82v$1nr@fnnews.fnal.gov> b91926@fnclub.fnal.gov (David Sachs) writes:
>In article <4902@hpwala.wal.hp.com>, pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
>|> In article <rfgCDHMnn.LBt@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
>|> |> In article <273k4pINNbap@emx.cc.utexas.edu> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>|> |> >
>|> |> >We can all open our eyes now.  The behaviour we commonly see is
>|> |> >correct and the ARM, contrary to what I wrote above, very clear states
>|> |> >that user-defined conversions are invoked for built-in operators (such
>|> |> >as `delete' and `[]')...
>|> |>
>|> |> This is where I think we will have to agree to differ.
>|> |>
>|> |> I am unconvinced that the ARM states ANYTHING clearly.
>|> |>
>|> |> For example, you have just claimed that user-defined conversions can be
>|> |> used (when needed??) in the presence of built-in operators.
>|> |>
>|> |> Now, consider the following example.  I have discussed this with several
>|> |> implementors, and I have yet to find a consensus of opinion regarding this
>|> |> example:
>|> |>
>|> |>  struct S
>|> |>  {
>|> |>   operator int& ();
>|> |>  };
>|> |>
>|> |>  S object;
>|> |>
>|> |>  void foobar ()
>|> |>  {
>|> |>   object = 99;  // legal???
>|> |>  }
>...
>
>There is way way whatsoever that this could be legal. At best it is ambiguous.
>
>EVERY class has an operator= member function, either user defined or default. This function will ALWAYS be a better match for the left hand side of an assignment like the one shown, than a user conversion.

That's clearly wrong.  Note that for type `struct S' there is no operator=
which even accepts an int!

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCDHMnn.LBt@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> In article <273k4pINNbap@emx.cc.utexas.edu> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
|> >
|> >We can all open our eyes now.  The behaviour we commonly see is
|> >correct and the ARM, contrary to what I wrote above, very clear states
|> >that user-defined conversions are invoked for built-in operators (such
|> >as `delete' and `[]')...
|>
|> This is where I think we will have to agree to differ.
|>
|> I am unconvinced that the ARM states ANYTHING clearly.
|>
|> For example, you have just claimed that user-defined conversions can be
|> used (when needed??) in the presence of built-in operators.
|>
|> Now, consider the following example.  I have discussed this with several
|> implementors, and I have yet to find a consensus of opinion regarding this
|> example:
|>
|>  struct S
|>  {
|>   operator int& ();
|>  };
|>
|>  S object;
|>
|>  void foobar ()
|>  {
|>   object = 99;  // legal???
|>  }

If operator= were user-defined, then it must be a *member* function of some
class.  When calling a member function, the would-be 'this' object of the
function is not subject to automatic conversions; therefore the left
operand of user-defined operator= is not subject to automatic conversions.

I admit that the ARM says nothing about how this applies to built-in
operators, but I like to think of built-in types to be very similar to
classes (or vice-versa :-) ).  So I like to think of there being a built-in
function that looks like:

 int &int::operator=(const int&) ...

Such a definition would imply that, no, the code above is not legal.
This should be clarified in the ARM, of course.

--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
                       (Send mail to either address)
-------------------------------------------------------------------------

In article <4902@hpwala.wal.hp.com> pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
>
>I admit that the ARM says nothing about how this applies to built-in
>operators, but I like to think of built-in types to be very similar to
>classes (or vice-versa :-) ).  So I like to think of there being a built-in
>function that looks like:
>
> int &int::operator=(const int&) ...

Really?  Why?  Built-in types are clearly not class types.  I perfer to
think of there being a built-in like:

 int& ::operator=(int&, int);

I also like to think of the above built-in operator as having the following
companion:

 int volatile& ::operator=(int volatile&, int);

(If such a thing didn't exist, you could never assign to a volatile int!)

>This should be clarified in the ARM, of course.

Better still, it should be clarified in the C++ standard.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <4902@hpwala.wal.hp.com>, pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
|> In article <rfgCDHMnn.LBt@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> |> In article <273k4pINNbap@emx.cc.utexas.edu> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
|> |> >
|> |> >We can all open our eyes now.  The behaviour we commonly see is
|> |> >correct and the ARM, contrary to what I wrote above, very clear states
|> |> >that user-defined conversions are invoked for built-in operators (such
|> |> >as `delete' and `[]')...
|> |>
|> |> This is where I think we will have to agree to differ.
|> |>
|> |> I am unconvinced that the ARM states ANYTHING clearly.
|> |>
|> |> For example, you have just claimed that user-defined conversions can be
|> |> used (when needed??) in the presence of built-in operators.
|> |>
|> |> Now, consider the following example.  I have discussed this with several
|> |> implementors, and I have yet to find a consensus of opinion regarding this
|> |> example:
|> |>
|> |>  struct S
|> |>  {
|> |>   operator int& ();
|> |>  };
|> |>
|> |>  S object;
|> |>
|> |>  void foobar ()
|> |>  {
|> |>   object = 99;  // legal???
|> |>  }
...

There is way way whatsoever that this could be legal. At best it is ambiguous.

EVERY class has an operator= member function, either user defined or default. This function will ALWAYS be a better match for the left hand side of an assignment like the one shown, than a user conversion.

In article <rfgCD2v5p.LJu@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>In article <25iuqnINN99f@emx.cc.utexas.edu> jamshid@emx.cc.utexas.edu
(Jamshid Afshar) writes:
[...]
>>... Nowhere in 5.3.4 is it implied that any kind of function
>>argument matching occurs (which is the only way user-defined
>>conversions are implicitly invoked).
>
>That's where you have it wrong.  You claim that function argument matching
>is the only thing that will cause user-defined conversions to occur...
>and indeed, if we all just closed our eyes to the behavior which we
>commonly see the majority of existing implementations produce (and if
>we blindly believed that what's in the ARM is really the WHOLE story)
>they you might be right.  But the truth is that many existing implementations
>(yes, including cfront) *do* apply user-defined conversions in a number
>of cases in which class-type operands are given as operands to BUILT-IN
>**operators**.

We can all open our eyes now.  The behaviour we commonly see is
correct and the ARM, contrary to what I wrote above, very clear states
that user-defined conversions are invoked for built-in operators (such
as `delete' and `[]').  You seem to have missed the article I posted a
couple of hours after the one to which you replied (strange since you
replied about a week after I posted my articles).  In that article I
corrected the erroneous statement I made above.  I'm appending it.
Sorry to repost but it should clear up this matter.

Repost of a correction from a couple of weeks ago:

From: jamshid@emx.cc.utexas.edu (Jamshid Afshar)
Newsgroups: comp.std.c++
Subject: Re: Delete operator conversions
Date: 26 Aug 1993 14:25:19 -0500
Organization: The University of Texas - Austin
Message-ID: <25j2mvINNlpb@emx.cc.utexas.edu>
Summary: the real reason user-defined conversions are applied

In article <25iuqnINN99f@emx.cc.utexas.edu>,
Jamshid Afshar [that's me] <jamshid@emx.cc.utexas.edu> wrote:
|In article <rfgCBtKxo.Kz8@netcom.com>,
|rfg@netcom.com (Ronald F. Guilmette) writes:
||  struct S { operator char * (); } object;
||  void example () { delete object; }
|| If you find one that DOES complain, please let me know.
||
|| Remember that the built-in global delete operator takes an argument of
|| type `void*'.  Now a value of type `struct S' cannot be used to initialize
|| a void* formal parameter (in a call) but a value of type `char*' can be.
|| Compilers should notice this, and should invoke the user-defined conversion
|| operator (implicitly) on `object' in cases such as the one shown above.
|
|[... You are confusing the `delete operator' with the `operator delete()'
|function(s) ...]
|Nowhere in 5.3.4 is it implied that any kind of function
|argument matching occurs (which is the only way user-defined
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|conversions are implicitly invoked).
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The underlined statement I made is wrong but the silver lining is that
in researching this correction I found a definite answer to the
original question.

There are a number of situations other than argument matching where
user-defined conversions may be implicitly invoked: on an initializer,
on the controlling expression in a selection or iteration statement,
on a function return value, and on an operand of an operator (see ARM 5
intro).                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So, the above code is legal, but not because `object' has to be
converted to a `void*', but because `object' is the operand of
the `delete' operator which needs a pointer.

Jamshid Afshar
jamshid@emx.cc.utexas.edu

In article <273k4pINNbap@emx.cc.utexas.edu> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>
>We can all open our eyes now.  The behaviour we commonly see is
>correct and the ARM, contrary to what I wrote above, very clear states
>that user-defined conversions are invoked for built-in operators (such
>as `delete' and `[]')...

This is where I think we will have to agree to differ.

I am unconvinced that the ARM states ANYTHING clearly.

For example, you have just claimed that user-defined conversions can be
used (when needed??) in the presence of built-in operators.

Now, consider the following example.  I have discussed this with several
implementors, and I have yet to find a consensus of opinion regarding this
example:

 struct S
 {
  operator int& ();
 };

 S object;

 void foobar ()
 {
  object = 99;  // legal???
 }

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <25iuqnINN99f@emx.cc.utexas.edu> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
>In article <rfgCBtKxo.Kz8@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
>| The operand expression given in the delete expression must have a type
>| which is a pointer type AFTER any required/appropriate implicit conversions
>| have been applied to that operand expression.  Thus, I would NOT expect
>| any decent C++ compiler to complain about:
>|  struct S { operator char * (); } object;
>|  void example () { delete object; }
>| If you find one that DOES complain, please let me know.
>|
>| Remember that the built-in global delete operator takes an argument of
>| type `void*'.  Now a value of type `struct S' cannot be used to initialize
>| a void* formal parameter (in a call) but a value of type `char*' can be.
>| Compilers should notice this, and should invoke the user-defined conversion
>| operator (implicitly) on `object' in cases such as the one shown above.
>
>I don't really have an opinion on the legality your example code, but
>I believe you're reasoning as to why it is legal is wrong.  You are
>confusing the `delete operator' with the `operator delete()'
>function(s).  `delete object' is a deallocation-expression.  It will
>call the destructor and call the appropriate `operator delete()'
>function.  See 5.3.4.
>
>Saying that `operator char*()' gets called as a consequence of trying
>to convert `object' to the `void*' parameter of the `operator
>delete()' function is like saying the horse moves because the cart
>pushes it.

OK.  I see your point, but you have misinterpreted mine.

>... Nowhere in 5.3.4 is it implied that any kind of function
>argument matching occurs (which is the only way user-defined
>conversions are implicitly invoked).

That's where you have it wrong.  You claim that function argument matching
is the only thing that will cause user-defined conversions to occur...
and indeed, if we all just closed our eyes to the behavior which we
commonly see the majority of existing implementations produce (and if
we blindly believed that what's in the ARM is really the WHOLE story)
they you might be right.  But the truth is that many existing implementations
(yes, including cfront) *do* apply user-defined conversions in a number
of cases in which class-type operands are given as operands to BUILT-IN
**operators**.

Here is an example which may make you a bit more comfortable with my
earlier example (which used the delete operator):

      struct S { operator char * (); } object;
      void example () { *object; }

Several existing C++ compiler do indeed accept this code (which involves
and application of the built-in unary `*' operator) without complaint.
(Try it on your favorite implementation.)  So even though the ARM may
not be quite complete enough to tell us this is valid C++ code, I believe
that the preponderance of the evidence shows that it is (and I will
continute to believe that existing common practice is a good guide
to what is and what is not "valid" in C++ until X3J16 tell me otherwise).

Anyway, the bottom line is that I hope and trust that you can now see
that there is very little difference between the code I just showed you
and:

      struct S { operator char * (); } object;
      void example () { delete object; }

(which was the subject of my original claim).

As far as I can see, we are applying a built-in operator (requiring a
pointer-type operand) in both cases, and thus the treatment of both of
these cases ought to be consistant (i.e. identical) for any reasonable
implementation... i.e. both ought to be permitted.


--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCBtKxo.Kz8@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> The operand expression given in the delete expression must have a type
|> which is a pointer type AFTER any required/appropriate implicit conversions
|> have been applied to that operand expression.  Thus, I would NOT expect
|> any decent C++ compiler to complain about:
|>
|>  struct S { operator char * (); } object;
|>
|>  void example () { delete object; }
|>
|> If you find one that DOES complain, please let me know.
|>
|> Remember that the built-in global delete operator takes an argument of
|> type `void*'.  Now a value of type `struct S' cannot be used to initialize
|> a void* formal parameter (in a call) but a value of type `char*' can be.
|> Compilers should notice this, and should invoke the user-defined conversion
|> operator (implicitly) on `object' in cases such as the one shown above.
|>
|> --
|>
|> -- Ronald F. Guilmette ------------------------------------------------------

I don't think this is at all clear.  Operator delete() is a special case.
Although it is defined as though it took a void* argument, it behaves as
though it were a compiler-defined *member operator* in every class that
does not override it.  Remember, there is a *big* difference between
new/delete and malloc/free.  Delete needs to know how much to delete, and
it gets this information from the type of its arguement (this is why
delete[] is different from plain delete).  In effect, the delete method is
being called on a pointer object.  Since member functions do not use type
conversions (except for trivial conversions), it should be no surprise that
delete() does not invoke type conversions on its arguments.  I think this
is as it should be.

--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
                       (Mail to either address)
-------------------------------------------------------------------------

In article <4797@hpwala.wal.hp.com> pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
>In article <rfgCBtKxo.Kz8@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
>|> The operand expression given in the delete expression must have a type
>|> which is a pointer type AFTER any required/appropriate implicit conversions
>|> have been applied to that operand expression.  Thus, I would NOT expect
>|> any decent C++ compiler to complain about:
>|>
>|>  struct S { operator char * (); } object;
>|>
>|>  void example () { delete object; }
>|>
>|> If you find one that DOES complain, please let me know.
>|>
>|> Remember that the built-in global delete operator takes an argument of
>|> type `void*'.  Now a value of type `struct S' cannot be used to initialize
>|> a void* formal parameter (in a call) but a value of type `char*' can be.
>|> Compilers should notice this, and should invoke the user-defined conversion
>|> operator (implicitly) on `object' in cases such as the one shown above.
>|>
>|> --
>|>
>|> -- Ronald F. Guilmette ------------------------------------------------------
>
>I don't think this is at all clear.  Operator delete() is a special case.

Really?  Can you provide some citations from the ARM to support that
contention?

>Although it is defined as though it took a void* argument, it behaves as
>though it were a compiler-defined *member operator* in every class that
>does not override it.

Gee! I must have missed that rule too.  Can you please tell me where (in
the ARM) this rule appears??

>... Since member functions do not use type
>conversions (except for trivial conversions), it should be no surprise that
>delete() does not invoke type conversions on its arguments.

Well, I suppose that you might have a point there, but only if the global
opertor delete was indeed treated as though it were a member function (and
I know of no rule which says that it ought to be).

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCBtKxo.Kz8@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
| The operand expression given in the delete expression must have a type
| which is a pointer type AFTER any required/appropriate implicit conversions
| have been applied to that operand expression.  Thus, I would NOT expect
| any decent C++ compiler to complain about:
|  struct S { operator char * (); } object;
|  void example () { delete object; }
| If you find one that DOES complain, please let me know.
|
| Remember that the built-in global delete operator takes an argument of
| type `void*'.  Now a value of type `struct S' cannot be used to initialize
| a void* formal parameter (in a call) but a value of type `char*' can be.
| Compilers should notice this, and should invoke the user-defined conversion
| operator (implicitly) on `object' in cases such as the one shown above.

I don't really have an opinion on the legality your example code, but
I believe you're reasoning as to why it is legal is wrong.  You are
confusing the `delete operator' with the `operator delete()'
function(s).  `delete object' is a deallocation-expression.  It will
call the destructor and call the appropriate `operator delete()'
function.  See 5.3.4.

Saying that `operator char*()' gets called as a consequence of trying
to convert `object' to the `void*' parameter of the `operator
delete()' function is like saying the horse moves because the cart
pushes it.  The `delete operator' must determine what object is being
deleted and must know its type so that it knows what destructor to
call.  Nowhere in 5.3.4 is it implied that any kind of function
argument matching occurs (which is the only way user-defined
conversions are implicitly invoked).

Jamshid Afshar
jamshid@emx.cc.utexas.edu

In article <25iuqnINN99f@emx.cc.utexas.edu>,
Jamshid Afshar [that's me] <jamshid@emx.cc.utexas.edu> wrote:
|In article <rfgCBtKxo.Kz8@netcom.com>,
|rfg@netcom.com (Ronald F. Guilmette) writes:
||  struct S { operator char * (); } object;
||  void example () { delete object; }
|| If you find one that DOES complain, please let me know.
||
|| Remember that the built-in global delete operator takes an argument of
|| type `void*'.  Now a value of type `struct S' cannot be used to initialize
|| a void* formal parameter (in a call) but a value of type `char*' can be.
|| Compilers should notice this, and should invoke the user-defined conversion
|| operator (implicitly) on `object' in cases such as the one shown above.
|
|[... You are confusing the `delete operator' with the `operator delete()'
|function(s) ...]
|Nowhere in 5.3.4 is it implied that any kind of function
|argument matching occurs (which is the only way user-defined
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|conversions are implicitly invoked).
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The underlined statement I made is wrong but the silver lining is that
in researching this correction I found a definite answer to the
original question.

There are a number of situations other than argument matching where
user-defined conversions may be implicitly invoked: on an initializer,
on the controlling expression in a selection or iteration statement,
on a function return value, and on an operand of an operator (see ARM 5
intro).                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So, the above code is legal, but not because `object' has to be
converted to a `void*', but because `object' is the operand of
the `delete' operator which needs a pointer.

Jamshid Afshar
jamshid@emx.cc.utexas.edu

In article <744994538snz@swidev.demon.co.uk> simonh@swidev.demon.co.uk writes:
>Is there any reason why conversions shouldn't be used on the operand of the
>delete operator?
>
>The reason I ask is that I've got a very safe pointer class that I use while
>developing C++ stuff. Problem is, I can't use delete on the pointers. I've
>got a conversion to a pointer, but delete don't use it.
>
>The ARM, pg.62: The operand of delete must be a pointer ...
>
>But why? It makes my pointer class require a cast before the delete operator.

I think you have perhaps misunderstood the intent of the rule.

The operand expression given in the delete expression must have a type
which is a pointer type AFTER any required/appropriate implicit conversions
have been applied to that operand expression.  Thus, I would NOT expect
any decent C++ compiler to complain about:

 struct S { operator char * (); } object;

 void example () { delete object; }

If you find one that DOES complain, please let me know.

Remember that the built-in global delete operator takes an argument of
type `void*'.  Now a value of type `struct S' cannot be used to initialize
a void* formal parameter (in a call) but a value of type `char*' can be.
Compilers should notice this, and should invoke the user-defined conversion
operator (implicitly) on `object' in cases such as the one shown above.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCBtKxo.Kz8@netcom.com> rfg@netcom.com writes:
>The operand expression given in the delete expression must have a type
>which is a pointer type AFTER any required/appropriate implicit conversions
>have been applied to that operand expression.  Thus, I would NOT expect
>any decent C++ compiler to complain about:
>
>        struct S { operator char * (); } object;
>
>        void example () { delete object; }
>
>If you find one that DOES complain, please let me know.
>

Yep, I just as I thought. I know there's some confusion about where class
conversion operator functions are used in expressions which is the reason I
asked.

Borland C++ does not perform implicit conversions on the operand of delete.
Can't say I suprised though.



--
Simon Huntington
Software Interrupt Developments. Leeds, UK.

Is there any reason why conversions shouldn't be used on the operand of the
delete operator?

The reason I ask is that I've got a very safe pointer class that I use while
developing C++ stuff. Problem is, I can't use delete on the pointers. I've
got a conversion to a pointer, but delete don't use it.

The ARM, pg.62: The operand of delete must be a pointer ...

But why? It makes my pointer class require a cast before the delete operator.


--
Simon Huntington
Software Interrupt Developments. Leeds, UK.