I posted the original question in this thread, but I got a little
busy and didn't read the newsgroup for a couple of weeks. I received
no answers by email, but apparently articles were posted here, because now I
see the followup postings. Could someone please bring me up to date?


  Thanks,
  Dave

  djones@megatest.com

In article <Cssu2s.IDs@megatest.com:, Dave Jones <djones@megatest.com> wrote:
:
:I posted the original question in this thread, but I got a little
:busy and didn't read the newsgroup for a couple of weeks. I received
:no answers by email, but apparently articles were posted here, because now I
:see the followup postings. Could someone please bring me up to date?
:
:
:  Thanks,
:  Dave
:
:  djones@megatest.com
:


I don't know what the answer is, but I have to comment that I laughed a bit when I
read the request.

ciao: Ronnie Braverman.

In article <JASON.94Jun23140654@deneb.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>This behavior conforms to the January WP:
>
>  5.3.5  Delete                                            [expr.delete]
>
>...
>
>5 A program that applies  delete to a pointer to constant is ill formed.
>

 const int * cpi = new const int; // is this allowed?
 delete const_cast<int*>(cpi); // fine??

This code is not ill formed, the delete applies to a pointer
to int (not a pointer to const int). Whether deletion of
objects created by "new const int" is permitted is another
issue and depends on there existing const objects.

 I do not believe const objects exist.



--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:

>  const int * cpi = new const int; // is this allowed?
>  delete const_cast<int*>(cpi); // fine??

> This code is not ill formed

Well, actually, it is:

  5.3.4  New                                                  [expr.new]
...
3 The  type-specifier-seq may not  contain    const,    volatile,  class
  declarations, or enumeration declarations.

Jason

jason@cygnus.com (Jason Merrill) writes:

>  5.3.4  New                                                  [expr.new]
>...
>3 The  type-specifier-seq may not  contain    const,    volatile,  class
>  declarations, or enumeration declarations.

 I just looked it up (r5.3.3 in my Stroustrup), and I was surprised to
see it.  What if I need something like the following?

const int** array = new const int*[5];

If I omit the second "const", IBM's xlC compiler complains (and rightfully so,
I think).

--
Terry Lee (terry@uivlsi.csl.uiuc.edu)
Coordinated Science Lab
University of Illinois

>>>>> Terry Lee <terry@uivlsisd.csl.uiuc.edu> writes:

>> 5.3.4  New                                                  [expr.new]
>> ...
>> 3 The  type-specifier-seq may not  contain    const,    volatile,  class
>> declarations, or enumeration declarations.

>  I just looked it up (r5.3.3 in my Stroustrup), and I was surprised to
> see it.  What if I need something like the following?

> const int** array = new const int*[5];

> If I omit the second "const", IBM's xlC compiler complains (and
> rightfully so, I think).

I think that the intent is clear; to avoid allocating arrays of const or
volatile objects.  Arrays of pointers to const are fine; the wording is
poor.  It also misses this (ill-formed, IMO) code:

typedef const int foo;
const int *p = new foo;

Jason

A new compiler I am testing allows me to create a const object using operator
new. That seems very reasonable. But when I try to delete it, the compiler
tells me that deleting a const object is an "anachronism". If I understand the
intent of the message, the word "anachronism" is a threat that the compiler
will reject the code in subsequent releases. That does not seem right.

If you can "new" it, you should be able to "delete" it, right?

What's the deal?

Notice that I can use a volatile integer in the construction of the object,
guaranteeing that the compiler can not know the value of the const object
at compile time, for what that's worth. It should not matter.

Something, either the proposed standard or the compiler, is not behaving
at all reasonably. Pray tell, which is it?

  -- Dave


^^^^^ snip ^^^^^ snip ^^^^^ snip ^^^^^ snip ^^^^^ snip ^^^^^ snip ^^^^^ snip

volatile int j;

class Foo {
  public:
     int i;
     Foo(int ii) : i(ii + j) {;}
};

int main()
{
  const Foo *p = new Foo(88); // This is okay. So far, so good.

  p->i = 7; // This is an error, as it should be, because *p is const.
            // Detecting such stuff at compile time is what "const" is for.

  delete p; // But if I remove the assignment above, this gets a severe
            // warning message. WHY?

  return 0;
}

This behavior conforms to the January WP:

  5.3.5  Delete                                            [expr.delete]

...

5 A program that applies  delete to a pointer to constant is ill formed.

In article <CrtoCE.Dqq@megatest.com> djones@megatest.com (Dave Jones) writes:
>A new compiler I am testing allows me to create a const object using operator
>new. That seems very reasonable. But when I try to delete it, the compiler
>tells me that deleting a const object is an "anachronism". If I understand the
>intent of the message, the word "anachronism" is a threat that the compiler
>will reject the code in subsequent releases. That does not seem right.

 ARM doesnt allow it.
>
>If you can "new" it, you should be able to "delete" it, right?

 Why should this follow?
>
>What's the deal?
>

 I asked the same question. Bjarne's reply was that
if you cant _modify_ the object, you sure shouldn't be able to
destroy it -- a much "bigger" type of modification than mere mutation.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CrvK96.Ass@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes:

[...]

>  Bjarne's reply was that if you cant _modify_ the object, you
> sure shouldn't be able to destroy it -- a much "bigger" type of
> modification than mere mutation.

Exactly what are the ramifications of this for automatic const
objects?  If I have a class C (with a destructor) then

 void f()
 {
  C const * pc = new const C;
  delete pc;
 }

is illegal. But what about

 void g()
 {
  C const cc;
 }

If a destructor is considered to "change" an object, then it shouldn't
be called on `cc' in `g', the object just becomes inaccessible.  (And
the memory it occupies could still be reclaimed.)

What do the WP say about this?

-- Olaf Weber

In article <Crw75x.tB@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:

[code about deleting a const object allocated with 'new' removed.]
   is illegal. But what about

    void g()
    {
     C const cc;
    }

   If a destructor is considered to "change" an object, then it shouldn't
   be called on `cc' in `g', the object just becomes inaccessible.  (And
   the memory it occupies could still be reclaimed.)

I don't know what the WP says about this, but it would seem natural to
allow calling destructor implicitly at a point where the object goes
out of scope, but doing it explicitly using delete or explicit destructor
call is IMHO disallowed.
---
   Esa Pulkkinen                       | Disclaimer:
   E-Mail: esap@cs.tut.fi              |   These opinions are mine, so
   WWW   : http://www.cs.tut.fi/~esap/ |   don't blame others on them.