Smirnov A.S. (sans@nfsun6.jinr.dubna.su) wrote:
: Hello everybody.

: The question is:
: why not to has the member function which is absolutely the same as
: usual destructor but is not destructor.

: For example:

: struct A
: {
:   ~~A() { cerr << "A::~~A()\n"; }
: }

: struct B
: {
:  A a;
:  ~~B() { cerr << "B::~~B()\n"; }
: };

: struct C
: {
:  A a;
: }

: void main()
: {
:  B b;
:  C c;
:  b.B::~~B();
:  cerr << "*********" << endl;
:  c.C::~~C();
: }
: ----------------------
: output:
: B::~~B()
: A::~~A()
: ***********
: A::~~A()
: ======================

: I mean that member functions ~~* have recursive calls semantic
: provided by *compiler*, not *user*.

: The aim of this is to have the way traverse through subobjects in the
: object, like destructor does, but do something different. Such kind of
: method could be called only by user, not automatically.

: I think that it would be usefull in many cases. For example, printing
: subobject representations, resolving of cycles in object graph with
: reference counts.

: Comments, suggestions... I didn't think about this question a lot,
: so please don't flame me very strong in the case I'm totally wrong.

I had a similar idea a while ago - but had trouble coming up with a
decent syntax for it, it might be useful for implementing
persistence and simplifying copy constructors and assignment
operators (though it's not so hot at the last two).

For example:

 // somewhere standard
 // a default inserter
 template <class T>
 ostream &operator <<(ostream &os, const T&object)
 {
   // each member of T - including the immediate bases
   // assumes some magic to do the bases
   foreach<T,member>
   {
     os << object.member;
   }
 }

 // the default copy constructor is pretty much:
 // foreach<T,member>
 // { new (&target.member) typeof(member)(source.member); }

 // the default constructor is pretty much:
 // foreach<T,member>
 // { new (&target.member) typeof(member)();

 // the default assignment operator is pretty much:
 // foreach<T,member>
 // { target.member = source.member; }

 // Alas, the destructor works backwards (see item (c) below)

 // ... somewhere else
 class Person;
 {
   string Name;
   string Address;
 };
 class Employee : public Person
 {
   string TaxFileNumber; // SSN for USA
 };

 ...
  Employee e;
  ... // something sets s

  cout << e << endl;
  // equivalent to:
  //  cout << Name << Address << TaxFileNumber << endl;

Issues:

(a) it's (much) too late in the standardisation process

(b) syntax - the above is non-obvious - and also what if you need to
cover two or more objects of type 'T' - possibly the item generated
each time is a member pointer (what about bases though?)

(c) ordering - sometime you might want constructor ordering and other
times destructor ordering (maybe foreach~<type,identifier>

(d) tasks between items (in the above you might want something
between each item, but not before everything and after everything).
--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

Hello everybody.

The question is:
why not to has the member function which is absolutely the same as
usual destructor but is not destructor.

For example:

struct A
{
  ~~A() { cerr << "A::~~A()\n"; }
}

struct B
{
 A a;
 ~~B() { cerr << "B::~~B()\n"; }
};

struct C
{
 A a;
}

void main()
{
 B b;
 C c;
 b.B::~~B();
 cerr << "*********" << endl;
 c.C::~~C();
}
----------------------
output:
B::~~B()
A::~~A()
***********
A::~~A()
======================

I mean that member functions ~~* have recursive calls semantic
provided by *compiler*, not *user*.

The aim of this is to have the way traverse through subobjects in the
object, like destructor does, but do something different. Such kind of
method could be called only by user, not automatically.

I think that it would be usefull in many cases. For example, printing
subobject representations, resolving of cycles in object graph with
reference counts.

Comments, suggestions... I didn't think about this question a lot,
so please don't flame me very strong in the case I'm totally wrong.

Andy.