J
James Kanze
I have a particular case where I'm having a problem deciding on
a good naming convention. Basically, I have several classes
which are split in two: there is a base class, which is a POD
(designed to support static initialization) and has only const
functions; and a derived class, which has the usual
constructors, and various non-const functions. A good example
of this is SetOfCharacter for UTF8: the base class has functions
like:
template< typename ForwardIterator >
bool isSet( ForwardIterator begin,
ForwardIterator end ) const ;
(where the iterators designate a sequence of UTF-8 characters,
and the function returns true for the first character in the
sequence), and a function:
void dumpAsCpp( std:stream& dest ) const ;
which outputs a declaration of the class with algomerate
initialization (with all of the necessary sub-tables in
anonymous namespace). The derived class has all of the
classical constructors, and the non-const operators, which build
and modify the data structure. The separation is essential
because it allows such objects to be statically initialized and
thus avoids order of initialization problems. It is also useful
in a few cases for performance reasons: one application uses
several thousand such objects, and dynamic construction can take
a significant amount of time.
For the moment, I've named the classes: BasicSetOfCharacter (POD
base class) and SetOfCharacter (derived class). I'm not
particularly happy with this, since it means that functions
taking a const reference really have to take a
BasicSetOfCharacter const&. Other alternatives I've considered
are ConstSetOfCharacter/SetOfCharacter and
SetOfCharacter/DynamicSetOfCharacter, but I'm open to other
suggestions as well.
I'm just curious as to what other programmers think. What would
be a good naming convention for this sort of thing? (I'd also
consider a good solution which doesn't involve two different
classes, but I don't think it's possible, since one has to be a
POD, and the other must at the very least have a destructor,
since the data structure must be built up dynamically, and I'm
not guaranteed to have garbage collection available.)
a good naming convention. Basically, I have several classes
which are split in two: there is a base class, which is a POD
(designed to support static initialization) and has only const
functions; and a derived class, which has the usual
constructors, and various non-const functions. A good example
of this is SetOfCharacter for UTF8: the base class has functions
like:
template< typename ForwardIterator >
bool isSet( ForwardIterator begin,
ForwardIterator end ) const ;
(where the iterators designate a sequence of UTF-8 characters,
and the function returns true for the first character in the
sequence), and a function:
void dumpAsCpp( std:stream& dest ) const ;
which outputs a declaration of the class with algomerate
initialization (with all of the necessary sub-tables in
anonymous namespace). The derived class has all of the
classical constructors, and the non-const operators, which build
and modify the data structure. The separation is essential
because it allows such objects to be statically initialized and
thus avoids order of initialization problems. It is also useful
in a few cases for performance reasons: one application uses
several thousand such objects, and dynamic construction can take
a significant amount of time.
For the moment, I've named the classes: BasicSetOfCharacter (POD
base class) and SetOfCharacter (derived class). I'm not
particularly happy with this, since it means that functions
taking a const reference really have to take a
BasicSetOfCharacter const&. Other alternatives I've considered
are ConstSetOfCharacter/SetOfCharacter and
SetOfCharacter/DynamicSetOfCharacter, but I'm open to other
suggestions as well.
I'm just curious as to what other programmers think. What would
be a good naming convention for this sort of thing? (I'd also
consider a good solution which doesn't involve two different
classes, but I don't think it's possible, since one has to be a
POD, and the other must at the very least have a destructor,
since the data structure must be built up dynamically, and I'm
not guaranteed to have garbage collection available.)