Re: Repository of all objects of a certain type
On 7 mar, 22:30, Marcel M=FCller <news.5.ma...@spamgourmet.org> wrote:
James Kanze wrote:
Would something like the following work here:
template< typename ObjType, typename KeyType >
class ContainerSupport
{
private:
static sorted_vector_p<ObjType, KeyType> RP_Index;
public:
// Factory:
// Fetches an existing instance or creates a new one for the
key K.
static my_intrusive_ptr<ObjType> GetByKey(const K& key);
// Fetches an existing instance or return NULL.
static my_intrusive_ptr<ObjType> FindByKey(const K& key)
{ return RP_Index.find(key); }
} ;
then:
class MyObject : public ContainerSupport< MyObject, MyKey >
// ...
{
// ...
} ;
As long as the only things in the base class template which
depend on the template parameter are static members or friends,
I think it should work.
Well, the only disadvantage I see is that the factory of
ObjType (or the constructor) must be public. This is a bit
dangerous with respect to data integrity.
I thought the factory was public in your original example. Or
do you mean rather: the constructor must be public (which of
course, allows client code to create instances which aren't in
the index). If this is a problem, you can declare
ContainerSupport< MyObject, MyKey > friend of MyObject, and keep
the destructors private.
> You might have to use the compilation
firewall idiom or the singleton pattern for the RP_Index, but I
don't think it should be necessary. Static data members of a
template should only be instantiated when and where used;
It should be sufficient when the statics are linked as weak
symbols when the template class is instantiated for some
certain parameters from a C++ file. But you are right.
Strictly speaking there is a cyclic dependency to the derived
class. I have to check this since the compiler is quite old.
But I think I already used something like that.
Barton and Nackmann described a similar idiom, in which the
templated base class only contained friend functions; the
standard explicitly makes this legal. If I understand things
correctly, the same rules apply here: the class template itself
is instantiated when it appears as a base class, the member
functions and static data members, however, only when they are
used. In this case (as with the Barton and Nackmann trick),
there is nothing in the class definition itself which requires a
complete definition of the instantiation type, so the fact that
it is instantiated before the class definition is complete
shouldn't be a problem. Any possible problem would be because
of two phase look-up -- if you do something in a non-dependent
context which requires the complete class type, I'm not sure
what is supposed to happen. But how could an expression which
required the complete class type be non-dependent? The only
thing I'm not sure of is the way dependency affects static data
members. (But I'm not sure that that's really relevant here
either. It's not so much a case of name lookup, but whether the
class is complete at the point of instantiation. And it will
be.)
I just tested the following:
class MyObject : public ContainerSupport<MyObject, MyKey>
{ friend class ContainerSupport<MyObject, MyKey>;
...
It works as far as I can see and the constructor of MyObject
is private. I wonder a bit since ContainerSupport<MyObject,
MyKey> is not yet a friend of MyObject when the template is
instantiated.
But it is! The constructor of MyObject is only used in the
functions, not in the class itself, and the functions are only
instantiated when they are actually used, at the point of use.
Note that the real question here isn't whether the friend
declaration is visible. The rule is that any code which
constructs an object requires a complete class definition. The
key here is that the templated class itself doesn't need the
type to be complete---the completeness is only required in
static data members and member functions, which are only
instantiated if and where needed, and the point of instantiation
"immediately follows the namespace scope declaration or
definition that refers to the specialization". (See =A714.7.1 and
=A714.6.4.1.)
But at least the 17 year old IBM compiler and gcc 3.3.5 ate
it. Maybe because of the same reason as the above dependency.
I wouldn't count on this working with just any 17 year old
compiler. 17 years ago, class instantiation was all or nothing
for most compilers (if they supported templates at all). IBM is
probably an exception---that's where Barton and Nackmann worked,
and they pushed the compiler team considerably (much like Boost
has in recent times). At the time, IBM was considerably in
advance of anyone else with regards to templates.
Pretty useful pattern.
Yep. I can't take credit for it, however---Barton and Nackmann
proposed a variant of it well over ten years ago.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34