Thread View: comp.std.c++
6 messages
6 total messages
Started by Philippe Verdy
Wed, 27 Mar 1996 21:42
static members as members of a metaclass hierachy
Author: Philippe Verdy
Date: Wed, 27 Mar 1996 21:42
Date: Wed, 27 Mar 1996 21:42
103 lines
4432 bytes
4432 bytes
Many problems in C++ are related to the need of using some
static members in the definition of the class.
There are many cases where those static members have to be
initialized in a proper sane order, as for any instances of
the class they belong.
Shamely, the current C++ definition does not allow for a clean
specification of which (and when) classes are constructed
prior to using them for the construction of other classes.
Why does the C++ standard evolve to a more solid definition
including metaclasses to solve this problem:
So we could instantiate the class in the metaclass constructor.
One can think of creating a collection of classes as being
instances of a metaclass.
How implement it ?
Simply we would define a metaclass like any other C++ class,
but each class constructor (the code which instantiate static
members of the class, as opposed to an instance constructor
which instantiate non static members) could be more safely
called and specified in the class definition itself.
So we would have to manage with a structure like this :
class X : public Y, static M
{
//////////// class construction part ////////////////////
static X()
: M(parameters) // metaclass construction
, static_member1(parameters) // static members construction
{
// code to initilialize static members of X
// after calling static class M constructor
}
static virtual ~X()
{
// code to delete static members of X
// then the static class M destructor will be called
}
static class_member1;
///////////////// instance definition part //////////////
X() // classic instance constructor
: Y (parameter) // base class instance construction
, instance_member2(parameter)
{...}
~X() {...} // classic instance destructor
int instance_member2;
};
Why using static (metaclass) inheritance ?
Because it will ensure that this metaclass is constructed
before initializing class static members.
So it can provide the monitoring which allows classes to
be safely constructed and deleted.
The class would not be really instances of the metaclass
because each metaclass-instance (or class) is fully specified
and cannot be instantiated without defining its behavior.
Then what about static members initializers ?
this would only remain as a common way of initializing them
when there is no static class constructor defined. In that
case, the compiler generates itself the class constructor and
the class destructor, by aggregating all static members
initializer in a compiler-generated function.
When would the metaclass be constructed ? Like any other
classes which are instanciable : by defining a static instance
of the metaclass like this :
static class M; // valid if static M::M() exists
static class X; // valid if static X::X() exists
We do not need then to add the whole list of static members
instances because the class constructor code instantiate
them itself, in the specified order.
How does the compiler control class instantiation order ?
by reading the list of their static inheritances, and the
compiler could manage a flag within the virtual table of
each class, which is specifically devoted to this task.
There can also be some virtual class destructors I think, but
I'm not sure if this would be useful or not.
What do you think of this proposal ? Would it provide
additional problems ? Are there proposals which similarily
go in this sense ?
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: static members as members of a metaclass h
Author: Steve Clamage
Date: Thu, 28 Mar 1996 09:26
Date: Thu, 28 Mar 1996 09:26
53 lines
3030 bytes
3030 bytes
In article doh@arl-news-svc-2.compuserve.com, Philippe Verdy <100105.3120@compu
serve.com> writes:
>Many problems in C++ are related to the need of using some
>static members in the definition of the class.
>
>There are many cases where those static members have to be
>initialized in a proper sane order, as for any instances of
>the class they belong.
>
>Shamely, the current C++ definition does not allow for a clean
>specification of which (and when) classes are constructed
>prior to using them for the construction of other classes.
The lack of specification of initialization order across modules is
not due to lack of trying. Many proposals have been made, and none
have been considered adequate. Your proposal for metaclasses is too big
a change to be considered in this round of standardization.
I believe a reasonable solution to the problem of initialization of non-local
static data is not to use non-local static data!
Instead of a static data object or static class data member, use a
function with a local static object. Example:
T1& global_T1() { static t1(args); return t1; } // instead of T1 global_T1;
class C {
static T2& static_T2(); // instead of T2 static_T2;
};
T2& C::static_T2() { static T2 t2; return t2; }
The only way to access static objects t1 or t2 is to call a function.
The first time the access function is called, the object is initialized
then, and only then. You have whatever control over the order of
initialization you need. Typically the order will be implicitly correct,
since no static data can be used until it is initialized.
Only two features are missing, compared to non-local static objects:
1. If you never reference an object, it is never initialized.
2. The order of destruction remains unspecified. If that is a problem,
possibly the static objects could be of a type which has a do-nothing
destructor and a "destroy" member function which could be called
explicitly at the proper time.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: static members as members of a metaclass h
Author: J. Kanze
Date: Mon, 01 Apr 1996 08:36
Date: Mon, 01 Apr 1996 08:36
39 lines
2551 bytes
2551 bytes
In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:
[...]
|> I believe a reasonable solution to the problem of initialization of
|> non-local static data is not to use non-local static data!
|> Instead of a static data object or static class data member, use a
|> function with a local static object.
[...]
|> Only two features are missing, compared to non-local static objects:
|> 1. If you never reference an object, it is never initialized.
But is this guaranteed by the standard anyway? I know that I have a
significant number of static objects which must be initialized before
main (but in any order), but I have always believed that this works
because of the way current compilers work, and not because of anything
in the standard.
|> 2. The order of destruction remains unspecified. If that is a problem,
|> possibly the static objects could be of a type which has a do-nothing
|> destructor and a "destroy" member function which could be called
|> explicitly at the proper time.
I thought that the order of destruction was the reverse of
initialization. This is what it says in the January draft, at least.
Has this been changed?
--
James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: static members as members of a metaclass h
Author: Jeffrey C. Gealow
Date: Tue, 09 Apr 1996 04:27
Date: Tue, 09 Apr 1996 04:27
19 lines
1550 bytes
1550 bytes
In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve Clamage) writes: I believe a reasonable solution to the problem of initialization of non-local static data is not to use non-local static data! Instead of a static data object or static class data member, use a function with a local static object. But this adds the overhead of the function call mechanism to every use of the object. Jeff --- [ 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 ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: static members as members of a metaclass h
Author: Fergus Henderson
Date: Tue, 09 Apr 1996 13:20
Date: Tue, 09 Apr 1996 13:20
32 lines
2254 bytes
2254 bytes
jgealow@mtl.mit.edu (Jeffrey C. Gealow) writes: >In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM >(Steve Clamage) writes: > > I believe a reasonable solution to the problem of initialization of > non-local static data is not to use non-local static data! > > Instead of a static data object or static class data member, use a > function with a local static object. > >But this adds the overhead of the function call mechanism to every use >of the object. A good compiler will inline the function, especially if you define it as `inline' and put the function definition in the header file. (If it is a non-member function, you need to declare it as `extern inline' to ensure that you get one copy of the static object.) Some compilers don't inline functions containing local static objects, but it is certainly possible to do so; if you have such a compiler, you should ask your compiler vendor to improve their compiler's inlining. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. --- [ 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 ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: static members as members of a metaclass h
Author: Rich Paul
Date: Wed, 10 Apr 1996 14:56
Date: Wed, 10 Apr 1996 14:56
29 lines
1893 bytes
1893 bytes
Jeffrey C. Gealow wrote: > > In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM > (Steve Clamage) writes: > > I believe a reasonable solution to the problem of initialization of > non-local static data is not to use non-local static data! > > Instead of a static data object or static class data member, use a > function with a local static object. > > But this adds the overhead of the function call mechanism to every use > of the object. > If you inline the function, are you guarenteed a single instance, or might there be one in each compilation unit, or in each invocation of the function? If it's safe, inlining the function would get rid of the overhead, but I'm not sure of the safety ... [ 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 ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads