I get the message. What should be used? Looked at all the documentation that I
have (including my new jeb-doc) and can't find what the alternative is. Sigh.
On another note, while looking for -style I looked at GUI.xs.
Being loath to comment:
1. GUI.xs uses a conditional ladder to perform a search.
2. On success, GUI.xs executes code in the conditional block.
It occurs to me that there are two operations that need to be performed; 1)
search, 2) some action based on the search. The current approach is the same
type of approach that was used in GUI-Constants.cpp. That was changed to a
hash, I wonder if this can also be changed (and yeh, I do know about "it's not
used too often", but the best code is the one to be desired, yes?).
The search consists of two parts:
search, action
A data structure (in C/C++) can be constructed to accomodate this,
to wit:
typedef struct SEARCH {
char * Str;
<type> Action;
};
SEARCH Table[] = { { "string", <attributes> }
, { "string", <attributes> }
, ...
};
where <type> can be any collection of things you might
like done. For example:
<type> could be: typedef bool (*func)(<data type> <data);
yielding pointers to functions, or it could be an int
or an enumeration type, yielding a switch statement,
or ....
In a similar way the <attributes> can be a single
attribute (which is what seems to be done now) or
some complex list of attributes.
And the search code could be something like:
if ( Idx = Search(<input string>) > -1 ) {
Table[Idx].Func(<data>); // or
switch Table[Idx].Swtch; // or something else
}
the choice of Search is left open and need not be
a function (as shown here).
The sole advantage (that I can see) is that the conditional ladder is made a
search through a data structure. The data structure can be altered but the
Search and action code need not be changed, since the search is independent of
data content and the action is captured as part of the data. And, to some
limited extent, it's faster.
On another note, have you thought about reworking your debug statements? What I
usually do is one of:
# if #defined DEBUG_FLAG
#define DEBUG( stmt ) stmt
# else
#define DEBUG( stmt )
# endif
and in use I do something like:
DEBUG( fprintf (...) ); )
or in more complex cases, something like:
DEBUG({ really complex debug code; })
which all disappears if the flag is not defined. I think
the code looks cleaner than:
# if defined DEBUG_FLAG
code;
# endif
Since I normally like to be able interactively turn debugging on and off during
development (and to do it selectively based on some ungodly reasoning), I often
augment the above to something like:
# if #defined DEBUG_FLAG
#define DEBUG( flag, stmt ) if ( flag ) stmt
# else
#define DEBUG( stmt )
# endif
with an example of:
DEBUG( flag, fprintf(); ) // or
DEBUG( flag, {really complex stuff})
And if the flag is not a const then it can be turned
on or off, and if it is a const false, the compiler
should remove the code.
Whew. Another mind buried in ego.
art
