Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pacbell!att-ih!ihnp4!twitch!anuck!jrl
From: jrl@anuck.UUCP (j.r.lupien)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language: switches
Message-ID: <547@anuck.UUCP>
Date: 24 Mar 88 18:51:15 GMT
References: <18377@think.UUCP>
Organization: AT&T Bell Labs, Andover Ma.
Lines: 26

From article <18377@think.UUCP>, by barmar@think.COM (Barry Margolin):
> In article <1186@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
>> >>Yes, in a sense switch is less powerful than an else-if chain.  Let's keep it,
>> >>for the same reasons that we retain flow constructs less powerful than goto.
>> > 	Theoretically the switch construct is more powerful than an else-if
>> > chain because it selects in one step.  Execution is O(1) rather than O(n)
>> > where n is the number of branches. 

  Things get even better than this. It is possible to define parameters
of switch selection which allow even more optimization. These parameters
involve the number of switch values and the range of values. For any
given machine architecture, certain ranges of these parameters will
perform better using one of: indexed dispatch table, linear search
dispatch table, and hashed dispatch table. The compiler can count
the number of entries, examine the spread, and select the best 
implementation for each switch. 
   Naturally "best" means slightly different things to different 
programmers: some need speed, some need space, some need some arcane
relationship between speed and space. Building in a means for the 
programmer to tell the compiler which feature is more important and
by how much would permit the compiler to make even better choices
for such cases as switch coding. (for instance, MSC 5.0 has 
optimization switches to allow selection of speed or space optimazation)

John R. Lupien
twitch!mvuxa!anuxh!jrl