* Alexander Terekhov:
 >
 > "Alf P. Steinbach" wrote:
 > [...]
 >  > One thing I don't see, immediately at least, is how to implement
 >  > "nonpoly" behavior,
 >
 > ?? "A class that declares or inherits a virtual function is called a
 > polymorphic class." Nonpoly thing would simply "disable" polymorphic
 > behavior (because it just can't be done right [current "cheating"
 > aside for a moment] during object construction and destruction).

Yes, how to do that (no matter where) is one thing I don't see about
how this proposal should work.


 >  >                     and another, how that could be made to not break
 >  > assumptions in base classes (when their constructor have executed
 >  > successfully),
 >
 > ?? What assumptions?

For example, that in any Base member function a Base pure virtual
function can be called without UB.


 >  >                and a third, how to provide that in post-pre calls; i.e.,
 >  > what calls can be made, and how can they be be ensured to be non-poly?
 >
 > struct T {
 >
 >    /* ... */
 >
 >    virtual void f() = 0;
 >
 >    void f1() nonpoly {
 >      // (*this) is "T nonpoly"
 >      f(); // ill-formed
 >    }
 >
 >    void f2() {
 >      // (*this) is "T poly"
 >    }
 >
 >    T() {
 >      // (*this) is "T nonpoly"
 >      f1(); // OK
 >      f2(); // ill-formed
 >    }
 >
 >    post T() {
 >      // (*this) is "T poly"
 >      f1(); // OK
 >      f2(); // OK
 >    }
 >
 >   ~T() throw() {
 >      // (*this) is "T nonpoly"
 >      f1(); // OK
 >      f2(); // ill-formed
 >    }
 >
 >    pre ~T() throw() {
 >      // (*this) is "T poly"
 >      // ...
 >    }
 >
 > };
 >
 > or something like that ("poly_cast<>" aside for a moment).

I'm almost sure I'm now interpreting this incorrectly, but it seems that
by default _all_ calls a constructor can now make would in the new
scheme be ill-formed, thereby breaking all existing C++ code?

Btw., I suggest continuing this discussion in comp.std.c++, which I have
cross-posted this response to (i.e., I suggest removing the
comp.lang.c++.moderated group in any response).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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                       ]

"Alf P. Steinbach" wrote:
[...]
>  >  >                and a third, how to provide that in post-pre calls; i.e.,
>  >  > what calls can be made, and how can they be be ensured to be non-poly?
>  >
>  > struct T {
>  >
>  >    /* ... */
>  >
>  >    virtual void f() = 0;
>  >
>  >    void f1() nonpoly {
>  >      // (*this) is "T nonpoly"
>  >      f(); // ill-formed
>  >    }
>  >
>  >    void f2() {
>  >      // (*this) is "T poly"
>  >    }
>  >
>  >    T() {
>  >      // (*this) is "T nonpoly"
>  >      f1(); // OK
>  >      f2(); // ill-formed
>  >    }
>  >
>  >    post T() {
>  >      // (*this) is "T poly"
>  >      f1(); // OK
>  >      f2(); // OK
>  >    }
>  >
>  >   ~T() throw() {
>  >      // (*this) is "T nonpoly"
>  >      f1(); // OK
>  >      f2(); // ill-formed
>  >    }
>  >
>  >    pre ~T() throw() {
>  >      // (*this) is "T poly"
>  >      // ...
>  >    }
>  >
>  > };
>  >
>  > or something like that ("poly_cast<>" aside for a moment).
>
> I'm almost sure I'm now interpreting this incorrectly, but it seems that
> by default _all_ calls a constructor can now make would in the new
> scheme be ill-formed, thereby breaking all existing C++ code?

Almost (in the ctors and dtors of the polymorhic classes;
"compatibility" mode aside for a moment). How else would you close
that hole in the C++ type system? I'd suggest that people should
better ASAP start using POLY and NONPOLY empty defines. ;-) ;-)

regards,
alexander.

---
[ 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                       ]