Re: Help with naming convention requested
On Jun 13, 5:50 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Jun 12, 5:06 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* 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::ostream& 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.
Consider using singletons, or completely rethinking that design.
How can singletons help, given that I have many, many instances
of the type?
Given that you really need to have a great many separately
named instances, you can still use the main singleton
implementation ideas to avoid order of initialization
problems; of course they'll not be singletons then but so
what. :-)
That still wouldn't solve the performance problem.
[snip]
I'm working in C++. In the first version, I didn't use
static data, and the program took close to a half an hour to
start. For a program that's typically invoked just to
process a few lines, that's simply not acceptable.
Assuming you're now down to something more reasonable, like
0.1 seconds, that's a factor of 18 000 and sounds like a bug,
not the result of added function call overhead.
Who's talking about function call overhead. These instances are
used in a regular expression based tokenizer. If I use dynamic
initialization, then I need to parse the full regular
expression, building most of them in dynamically allocated
memory. And on my machine, here, that takes almost a half an
hour. Actually, I have modified the strategy somewhat, and the
time is coming down. But it is still measured in minutes (more
than 10), whereas loading a statically initialized table takes
practically 0 time.
[snip]
Since you're aiming for POD'ness, how about including "POD" in
the name?
Because the POD'ness is a means to an end, and not a goal in
itself. And because it's the base class, and for most client
code, it's the class they should be using. In many ways, I
really think that SetOfCharacter should be the name of the base
class, with maybe MutableSetOfCharacter the derived class.
Ah, well, I disagree, for two reasons. First, if my window
abstraction is a means to earn money in order to not suffer
from lacking such, and thus be happy, well I don't name it
BeHappy. Even if that's the final end it is a means for. :-)
Agreed. Otherwise, all of our classes would be named
MakeMoney:-). But you don't have to go to the opposite extreme.
In context, the abstraction that the client code has to deal
with is SetOfCharacter.
And second, I like names to be such that when I see the name I
get a correct impression, or at least not a misleading one,
about what that name names. And what you have been talking
most about for this class is POD'ness, that's apparently the
most important aspect and the reason the class exists at all,
so if I were to choose a name I'd include that most important
aspect, not hide it!
The POD'ness is an important issue for performance reasons, and
it is the major motivation for creating two classes.
Nevertheless, for the client code, it's irrelevant (except for
performance issues); the client code is dealing with a
SetOfCharacter; in one case, a SetOfCharacter which can be
modified, and in the other, one which cannot be modified.
--
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