🚀 go-pugleaf

In article <Dnt4vo.Gu0@tigadmin.ml.com>,
|> pardoej@lonnds.ml.com (Julian Pardoe LADS LDN X1428) writes:
|> In article <DnKnzv.8t6%spenford@zoo.toronto.edu>,
|> Henry Spencer <henry@zoo.toronto.edu>
|> explains that a compiler might not be able to use an
|> implementation clever than an
|> if/elsif chain when compiling a switch on a pointer
|> value and then goes on to say:
|>  
|> -->. . .                  When the values are not known at compile time,
|> -->it's hard to implement the switch as anything other than a series of
|> -->ifs... and there is no point in writing that as a switch.
|> 
|> Yes there is!  It might be clearer, more readable code.  The fact that the
|> compiler has to implement it in a certain way is not really relevant.
|> 
|> This isn't a big deal in C because one can't really define new types with
|> enum-like behaviour but I really miss a generalized switch in C++.  If I
|> can switch on an enum why can't I switch on a value of some class that wraps
|> up a simple value?  The fact that the compiler has to use an if/elsif chain rather
|> than a jump table is its problem, not mine!

I'm glad someone else sees a need for a generalized switch statement.
I'd be satisfied with the type of constant expression that can be used
in intializers, i.e., a null pointer constant, an address constant, or
an address constant plus or minus an integral constant expression, as
defined in ANSI 6.4 Constant expressions, so that no changes to linkers
are required.

Constants of type ``address constant plus or minus an integral
constant expression'' are of course prime targets for jump tables, especially
if the set of constant expressions constitute a range.  The one optimization
you can't do is binary search for the correct label, since you can't order
the labels at compile time.

Konrad Schwarz