Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!njin!princeton!phoenix!haahr
From: haahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr)
Newsgroups: comp.lang.c++
Subject: Re: Improved switch statement
Summary: switch is useful;  don't forget about program generators
Message-ID: <5096@phoenix.Princeton.EDU>
Date: 2 Jan 89 21:41:25 GMT
References: <574@redsox.UUCP> <77300018@p.cs.uiuc.edu>
Reply-To: haahr@princeton.edu (Paul Gluckauf Haahr)
Organization: Princeton University, Princeton NJ
Lines: 30

in article <77300018@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
> This discussion about modifying the switch statement in C++ is pretty
> amusing.  Case statements are bad programming style in object-oriented
> programs.  Instead, you should use virtual functions.  Don't say that
> you want to distinguish the values of integers and virtual functions
> won't work in that context.  That just reveals that you are using
> integers where you should be using something else.

the switch statement is very useful for some programs;  it does a large
part of the job when you want to model a finite state automaton.  for
example, a switch construct is normally the best thing for implementing
a lexical analyzer.  many program generators rely on switch; classic
examples are lex and yacc.  i know of a c compiler where the code
generator is a (machine generated) 3000+ line switch statement that
does dag rewriting.  switch (and even goto) are constructs that come in
handy for programs that write programs.

> There are certainly places where one should use switch statements, mainly
> when you are converting from a non-object-oriented part of the system
> to the clean, elegant part.  However, I put switch statements in the same
> category with goto statements: sometimes necessary but never elegant.

maybe a lexical analyzer or parser is a "non-object-oriented part of
[a] system," but that doesn't mean it should be discounted.

i put switch and goto in the same category:  the appropriate constructs
to model some actions, typically a finite state machine which is the
output of a program.

paul haahr		haahr@princeton.edu	princeton!haahr