francis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:<BC5$O1R9QQ9AFwTg@robinton.demon.co.uk>...
> A thread on comp.lang.c++.moderated about post construction triggered an
> idea in my mind. A virtual base class is one that get promoted to being
> done first but we do not have a way to supply a base class that must
> always be done last.
>
> Of course any such class would need to be heavily constrained. As a fist
> cut it should consist of a constructor, a destructor and a number of
> pure virtual functions. Given such a class and a mechanism for
> inheriting from it so that it is always applied after the most derived
> ctor has completed we would have the tools for providing a safe
> post-constructor that is always applied to the final object just before
> it is released to the rest of the program.
>
> This would, for example, make registration of an object easy and the
> corresponding dtor would enable deregistration prior to any other
> action. We can even deal with  multiple 'final' base classes by a rule
> of 'right to left, depth last' with the corresponding rule for dtors.
>
> Is there any merit in investigating this idea further?

It is a good idea. I found myself several times needing something like
this, and did workarounds by using templated base-classes. But using
this would most likely make my code cleaner.

Best,
John

John Torjo
Freelancer
-- john@torjo.com

Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/

Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging           - C++)
-- http://www.torjo.com/logview/         (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/        (debugging         - Win32)
                                         (source code available)

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

In article <40F79875.3E36DD5E@iobox.com>, Sergey P. Derevyago
<non-existent@iobox.com> writes
>  2. But should this feature be introduced in _general_ purpose programming
>language? Is it really needed by >80% of C++ community but can't be
>efficiently implemented in current C++?

Exactly the same question could be asked about RTTI. The reason WG21
changed its collective mind was that a small but significant
sub-community (largely those developing frameworks) in the early 90's
were having to find ways to simulate RTTI. Most users rarely explicitly
use RTTI (though it is used indirectly by those using dynamic_cast<>).

We also have a significant body of programmers sensitized to the use of
virtual functions in ctors because they come from a Java background.
Currently we have no mechanism that supports idioms that are entirely
natural to them. That, in itself, would not justify an extension to C++
but combine that with the other minority needs and we have something
that should be considered on a cost/benefit basis. If it is easy to
implement (others will have to tell me if this is the case for my
proposal) and does not break existing code (i.e. is a pure extension)
then the cost is relatively low. Well there is one added cost that
should always be considered -- added complexity to the core of the
language. So the question remains, how much benefit. In the kind of
programming I do, none; but that does not lead me to suppose that there
is actually no benefit. Certainly in an instructional/mentoring mode I
would gain when someone asks me how to get dynamic behaviour in a ctor.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

In article <cd5929$qo9$1@news-reader2.wanadoo.fr>, Lo=EFc Joly=20
<loic.actarus.joly@wanadoo.fr> writes
>I am not very sure of what you mean. Do you imply that in this "post=20
>constructor", calling a virtual function would would use the dynamic=20
>type ?

Effectively, yes. But the rules would be just as they are today -- it=20
would use the type for the current ctor which in the case of a 'final=20
base' would be the type of the complete object.

--=20
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/pr=
ojects

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

A thread on comp.lang.c++.moderated about post construction triggered an
idea in my mind. A virtual base class is one that get promoted to being
done first but we do not have a way to supply a base class that must
always be done last.

Of course any such class would need to be heavily constrained. As a fist
cut it should consist of a constructor, a destructor and a number of
pure virtual functions. Given such a class and a mechanism for
inheriting from it so that it is always applied after the most derived
ctor has completed we would have the tools for providing a safe
post-constructor that is always applied to the final object just before
it is released to the rest of the program.

This would, for example, make registration of an object easy and the
corresponding dtor would enable deregistration prior to any other
action. We can even deal with  multiple 'final' base classes by a rule
of 'right to left, depth last' with the corresponding rule for dtors.

Is there any merit in investigating this idea further?


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

Francis Glassborow wrote:
> A thread on comp.lang.c++.moderated about post construction triggered an
> idea in my mind. A virtual base class is one that get promoted to being
> done first but we do not have a way to supply a base class that must
> always be done last.
>
 IMHO the proposed pre/postconstructor feature must be _intentionally_
separated from virtual inheritance (VI).
 The point is that the preconstruction of virtual base objects is nothing more
than a side effect of VI. For example, one may want to use
pre/postconstructors but doesn't want to deal with unavoidable consequences of
VI.
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

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

Francis Glassborow wrote:

>=20
> A thread on comp.lang.c++.moderated about post construction triggered a=
n=20
> idea in my mind. A virtual base class is one that get promoted to being=
=20
> done first but we do not have a way to supply a base class that must=20
> always be done last.
>=20
> Of course any such class would need to be heavily constrained. As a fis=
t=20
> cut it should consist of a constructor, a destructor and a number of=20
> pure virtual functions. Given such a class and a mechanism for=20
> inheriting from it so that it is always applied after the most derived=20
> ctor has completed we would have the tools for providing a safe=20
> post-constructor that is always applied to the final object just before=
=20
> it is released to the rest of the program.
>=20
> This would, for example, make registration of an object easy and the=20
> corresponding dtor would enable deregistration prior to any other=20
> action. We can even deal with  multiple 'final' base classes by a rule=20
> of 'right to left, depth last' with the corresponding rule for dtors.

I am not very sure of what you mean. Do you imply that in this "post=20
constructor", calling a virtual function would would use the dynamic type=
 ?

--=20
Lo=EFc

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

In article <40F54E35.125402DB@iobox.com>, Sergey P. Derevyago
<non-existent@iobox.com> writes
>Francis Glassborow wrote:
>> A thread on comp.lang.c++.moderated about post construction triggered an
>> idea in my mind. A virtual base class is one that get promoted to being
>> done first but we do not have a way to supply a base class that must
>> always be done last.
>>
>       IMHO the proposed pre/postconstructor feature must be _intentionally_
>separated from virtual inheritance (VI).
>       The point is that the preconstruction of virtual base objects is nothing more
>than a side effect of VI. For example, one may want to use
>pre/postconstructors but doesn't want to deal with unavoidable consequences of
>VI.

I was only using VI to demonstrate that we have a feature in the
language to allow for moving a base up the order of construction (though
the reason is that it is needed for other ctors.)

We often have features in the language that were introduced for one
reason and then used for a different one -- look at the whole of
meta-programming that is based on features introduced to support generic
programming.

Even the concept of inheritance in C++ is broader than that required for
OOP. Were it only to support OOP we would have all member functions
treated as virtual.

Now I am unconvinced that C++ has a need for pre-constructors (I do not
see much effort going into simulating them) however I see considerable
effort going into the problem of C++'s lack of a post-constructor. That
is a sure sign that we should look at the issue (just as we did when we
reversed ourselves over RTTI, which was originally consciously not
supported by C++)

Inventing new syntax is always a dangerous task because it can so easily
have unexpected consequences. We do have a fairly good understanding of
inheritance in C++ and have tackled most of the issues that arise from
it. My idea is that where a programmer wants to delay some action of a
ctor until the whole object is initialised that a way to do this is with
a syntax that forces a 'base' ctor to run after completed
initialisation. Something like:

final struct post {
   virtual void member() = 0;
   virtual void member1() = 0;
   post(){member();}
   ~post() {member1();}
};

class base: final post {
// whatever
};

and now post() will run on exit from the ctor for base. Of course there
must now be implementations for member and member1 if base is to be a
concrete class.

class derived: public base {
// what ever
};

Now the ctors runs in the order base(), derived(), post().

I think this certainly makes post-construction possible as part of the
overall process of construction and allows for exceptions to occur even
during that final phase, but with ~derived() called because the whole
object exists though not yet released to the program as a whole.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

Francis Glassborow wrote:
> Now I am unconvinced that C++ has a need for pre-constructors (I do not
> see much effort going into simulating them) however I see considerable
> effort going into the problem of C++'s lack of a post-constructor.
>
 IMHO there is no need to introduce pre/post construction and give no standard
way to hook the intermediate changes of the object state.

 For example, having

 struct D : B1, B2 {};

the following events might also be "interesting":

 ::onConstructionBegin();      // pre
  D::onConstructionBegin();
   B1::onConstructionBegin();
   B2::onConstructionEnd();
   B1::onConstructionBegin();
   B2::onConstructionEnd();
  D::onConstructionEnd();
 ::onConstructionEnd();        // post

That is:
  1. Some general way to set StateChangedListener(s) might be useful in some
circumstances.
  2. But should this feature be introduced in _general_ purpose programming
language? Is it really needed by >80% of C++ community but can't be
efficiently implemented in current C++?
--
         With all respect, Sergey.               http://ders.angen.net/
         mailto : ders at skeptik.net

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