Re: type traits and element specific functions: design problem
Andy wrote:
I am writing a framework for writing an installer. The system should
I am faced with a basic problem. Currently we only plan to support a
UNIX terminal based character-based UI. The whole set of dialog strings
or prompt strings which I am supposed to throw at the user is quite
large. As of now, each of these has been given a numeric ID and mapped
from a message catalog using catopen / catgets calls.
Now each of these dialogs is a request to the user for an input. There
are well-defined rules as to what is acceptable and what is not
acceptable as part of the input in response to each Dialog.
In other words, each Dialog Id has associated with it a validation rule
for the input that is read in response to that Dialog.
Now it is not difficult to create a set of Input Validator classes,
each doing one kind of validation. Some do validation on date time
strings, others on File names and directories, and still others on
numeric values. We have been able to keep the number of such generic
validators to 8 at present.
Now let us suppose that each of my (say) 250 Dialogs can be validated
with one of these 8 validators.
So I am wondering how to approach this problem.
I tried the following approach:
Create a dialog_traits class template. For each dialog Id, specialize
it and define a typedef in the specializtion which refers to the type
of the validator appropriate for this dialog. Something like:
template <int DLG_ID> struct dialog_traits;
template <>
struct dialog_traits<Dialog_Which_File> // say Dialog_Which_File == 5
{
typedef FileNameInputValidator validator_t;
};
- This still creates a pretty large number of template classes - one
for each validator and the executable size can increase significantly
because of this.
What "code" could a typedef declaration be adding to a program? Given
that that the program allocates no dialog_traits class template
objects, and thereby instantiates no dialog_traits class template
methods (just a typedef declaration), there is no code "bloat" to be
concerned about - because there is no code at all. The class template
dialog_traits generates no code - and allocates no storage - so it
would be difficult to write a class template whose resource
requirements were any lighter those of dialog_traits.
Granted, all of these dialog_traits template instantiations may
significantly increase the size of a debug build of the program. But
the entire amount of any increase in binary size is simply added
strings. The compiler adds the names of the dialog_traits class
template instantiations to the executable for benefit of the debugger.
But none of this additional data contributes anything during the
program's execution - and all of this added debugging overhead should
be removed in the program's final, release build anyway. So when it
comes time to release the software, the dialog_traits class template
would have ballooned the final build - increasing both the program's
code size and its storage requirements - by precisely zero added bytes
of useless overhead.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]