Lisa Lippincott wrote:

> Consider the following:
>
>     void f( const bool * );
>     void g();
>
>     int main()
>       {
>        const bool *b = new const bool( false );
>        f(b);
>        if (*b)
>           g();
>       }
>
> I would expect that a clever compiler could take advantage of the
> constness of *b to optimize away the call to g.  But that doesn't
> appear to be the case, because f can destroy and reconstruct *b
> without engendering undefined behavior:
>
>     void f( const bool *b )
>       {
>        b->~bool();
>        new ( const_cast<bool *>(b) ) const bool( true );
>       }
>
> If the storage duration of *b were static or automatic, this function
> program would have undefined behavior by 3.8 [basic.life] paragraph 9.

True

> But that paragraph excepts dynamic objects.

This is already under discution (Dublin).

If the user replaces operator new, the typicall implementation
will reuse the same storage:

delete new const T;
delete new const T;

may be translated into

void *big_block = malloc (BLOCK_SIZE);
(new (big_block) const T)->~T();
(new (big_block) const T)->~T();

It'd better not have undefined behaviour. (That doesn't
imply anything about your example, which should be
undefined IMO.)

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:

> In any case, neither form of the proposal handles the case:
>
>   struct A { int& i; ... };
>   struct B { A a;  ... };
>
> where a B is destroyed and reconstructed.  In their current form
> they just create a special (not very useful) case for top-level
> members.

which wasn't my intent (I wanted to make T*const
and T& equivalents -- and still want)

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 [Moderator's note: this defect report has been forwarded to the
 C++ committee.  -moderator(fjh).]

Consider the following:

    void f( const bool * );
    void g();

    int main()
      {
       const bool *b = new const bool( false );
       f(b);
       if (*b)
          g();
      }

I would expect that a clever compiler could take advantage of the
constness of *b to optimize away the call to g.  But that doesn't
appear to be the case, because f can destroy and reconstruct *b
without engendering undefined behavior:

    void f( const bool *b )
      {
       b->~bool();
       new ( const_cast<bool *>(b) ) const bool( true );
      }

If the storage duration of *b were static or automatic, this function
program would have undefined behavior by 3.8 [basic.life] paragraph 9.
But that paragraph excepts dynamic objects.  (I presume the exception
is intended to allow storage to be reused after a const object is
deleted.)  That exception, combined with paragraph 7 of 3.8, gives the
program above defined behavior; it must call g().

The proposed resolution of core language issue 89, "Object lifetime does
not account for reference rebinding," is

     Add a new bullet to the list of restrictions in 3.8 basic.life
     paragraph 7, following the second bullet ("the new object is of
     the same type..."):

       -- the type of the objects, if a class type, does not contain
          any non-static data member whose type is const-qualified or
          a reference type, and

I suggest that this be strengthened to

       -- the type of the original object is not const-qualified, and,
          if a class type, does not contain any non-static data member
          whose type is const-qualified or a reference type, and

                                                      --Lisa Lippincott
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers <ncm@nospam.cantrip.org> wrote:
> In any case, neither form of the proposal handles the case:
>
>   struct A { int& i; ... };
>   struct B { A a;  ... };
>
> where a B is destroyed and reconstructed.  In their current form
> they just create a special (not very useful) case for top-level
> members.

in reference to the proposed resolution of core language issue 89:

     Add a new bullet to the list of restrictions in 3.8 basic.life
     paragraph 7, following the second bullet ("the new object is of
     the same type..."):

       -- the type of the object, if a class type, does not contain
          any non-static data member whose type is const-qualified or
          a reference type, and

Here I took "contain" in a recursive sense, which is not the way it is
generally used in the standard.  The text should indeed be rewritten to
make the recursive intent clear.

                                                --Lisa Lippincott


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]