John Nagle wrote:

> Hyman Rosen wrote:
>=20
>> John Nagle wrote:
>>
>>> Dave Harris wrote:
>>>
>>>> That might prevent existing valid code from compiling, though. The=20
>>>> code is fine so long as it is not actually executed.=20
>>>
>>>
>>>
>>>      That's a very low standard of correctness.
>>
>>
>>
>> Not when non-executing code is used to drive
>> template metaprogramming.
>=20
>=20
>    Presumably, in the next revision of C++, some reasonable
> compile-time execution system will be defined and we will
> get rid of the "template metaprogramming" hack.
>=20
>    I'd suggest, as a starting point, that invocation of
> inline functions be allowed in compile-time expressions.

What I am afraid of is that one compiler might decide to inline a=20
function f, and the other not. Thus using f in a compile-time expression=20
would not be portable.

Or if by inline, you meant "declared with the /inline/ keyword", then it=20
would probably change the meaning of this operator (require inline=20
instead of suggesting it), but more important, if one library writer=20
decides that std::cos is a good candidate for inlining, and the other=20
not, then using std::cos in a compile-time expression would not be portab=
le.

--=20
Lo=EFc

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

I'd like to suggest that the standard make using 'delete' on an expression with type pointer to abstract class ill-formed unless the class has a virtual destructor.

The rationale is that doing so is useless because either the pointer must be:
  -- NULL; so the expression will have no effect
or
  -- a pointer to some derived class, in which case the behavior is undefined.

It seems better to make this case ill-formed.

A concrete example:

  struct ABS { virtual void f() = 0; };  // destructor is not virtual
  void f(ABS* p) {
    delete p;  // useless
  }

Similarly using 'delete []' on an expression with type pointer to abstract class should ill-formed even if

  struct ABS2 { virtual ~ABS2() = 0; };  // destructor is virtual
  void g(ABS* p) {
    delete [] p;  // undefined behavior.
  }

My suggested change to the standard would be to add these sentences to 5.3.5 [expr.delete] (paragraph 2 or 3).

"In the first alternative (delete object), if the static type of the operand is a pointer to a (complete) abstract class and the class has a non-virtual destructor the program is ill-formed."

"In the second alternative (delete array), if the static type of the operand is a pointer to a (complete) abstract class the program is ill-formed."

[I once, long ago, tried to submit this as a defect report.  But it was, reasonably, rejected since it's really and enhancement, not a defect.]

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"scott douglass" <sdouglass@arm.com> wrote in message
news:ceqo09$51b$1@cam-news1.cambridge.arm.com...

> I'd like to suggest that the standard make using 'delete' on an expression
with type pointer to abstract class ill-formed unless the class has a
virtual destructor.
>
> The rationale is that doing so is useless because either the pointer must
be:
>   -- NULL; so the expression will have no effect
> or
>   -- a pointer to some derived class, in which case the behavior is
undefined.
>
> It seems better to make this case ill-formed.

Nice idea.  Of course, implementations are already permitted to reject such
programs (because they can reject any program that is known to cause
undefined behavior), so perhaps you might start by lobbying your favorite
vendor.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

sdouglass@arm.com (scott douglass) wrote (abridged):
> I'd like to suggest that the standard make using 'delete' on an
> expression with type pointer to abstract class ill-formed unless the
> class has a virtual destructor.

That might prevent existing valid code from compiling, though. The code is
fine so long as it is not actually executed. It is also fine if it is
executed when the pointer is NULL.

Do you think this change would find many real bugs? Would a
quality-of-implementation compiler warning be as good? If you really want
an error, you can make the destructor protected.

-- Dave Harris, Nottingham, UK

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:
> That might prevent existing valid code from compiling, though. The code is
> fine so long as it is not actually executed.

      That's a very low standard of correctness.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> Dave Harris wrote:
>> That might prevent existing valid code from compiling, though. The
>> code is fine so long as it is not actually executed.
>
>      That's a very low standard of correctness.

Not when non-executing code is used to drive
template metaprogramming.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen wrote:

> John Nagle wrote:
>
>> Dave Harris wrote:
>>
>>> That might prevent existing valid code from compiling, though. The
>>> code is fine so long as it is not actually executed.
>>
>>
>>      That's a very low standard of correctness.
>
>
> Not when non-executing code is used to drive
> template metaprogramming.

    Presumably, in the next revision of C++, some reasonable
compile-time execution system will be defined and we will
get rid of the "template metaprogramming" hack.

    I'd suggest, as a starting point, that invocation of
inline functions be allowed in compile-time expressions.
That allows arbitrary execution at compile time.  Compile
time expressions would be subject to the following
restrictions:

 -- no calls to non-inline functions.
 -- no use of the built-in operator "&",
 addresses not being meaningful at compile time.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]