Hello.

 By mistake I wrote interesting code :) Of course it is
not correct, but I'm wondering how much legal it is :))
Interesting thing is that g++ throws internal error here...

The code itself:

#include <set>

class mset : public set<int>
{
  public:
    ~mset();
};

void foo()
{
  mset s;

  s.~set();
}


Of course there should be s.~mset();... If dtor is
virtual it is legal (?) to call base dtor I think..
but what if dtor of base class is not virtual?

--
Best regards from
Kamil Burzynski
Advanced Digital Broadcast Poland, LTD.
 - -
It's clever, but is it art?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

nopik@kamilb.adb.pl wrote:

>  By mistake I wrote interesting code :) Of course it is
> not correct, but I'm wondering how much legal it is :))
> Interesting thing is that g++ throws internal error here...

You're allowed to call the base class destructor, but I
would have thought that an explicit qualifier would be
necessary:

 s.set::~set();

> Of course there should be s.~mset();... If dtor is
> virtual it is legal (?) to call base dtor I think..
> but what if dtor of base class is not virtual?

The virtual distinction only applies to "delete".
In this case, only the ~set() destructor runs.

You've got bigger fish to fry anyhow.  Your code
invokes undefined behavior even if written as you
say you inteded it.  You end the objects lifetime
by calling the destructor, but since you allow the
control to transfer normally out of the block, the
implicit destruction is still there.  This is specifically
undefined behavior 12.4/14

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ron Natalie wrote:
>implicit destruction is still there.  This is specifically
>undefined behavior 12.4/14

Yeah, I've just checked it ;) In fact I was playing with
that bcoz I've found similar call in container definition ;)
Accidentally I've missed one letter and got internal gcc error ;)

--
Best regards from
Kamil Burzynski
Advanced Digital Broadcast Poland, LTD.
 - -
It's clever, but is it art?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

nopik@kamilb.adb.pl wrote:

> Yeah, I've just checked it ;) In fact I was playing with
> that bcoz I've found similar call in container definition ;)

The containers get away with it because they build the objects
in a way where they won't get normal destructor runs (placement
construction).

---
[ 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.research.att.com/~austern/csc/faq.html                ]