In article <DpZxjGGXgz+8EwKz@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>Pattern matching in Haskell is based on the fact, that every value
>>contains information on which "constructor" has created it. E.g.
>>values of list type have two constructors: nilary constructor [] and
>>binary constructor `:`, and looking at list value runtime can tell,
>>which constructor has been used to create it. The constructors are
>>used to form patterns. In C++ the values have no unique
>>"constructions".
>
>I am not familiar enough with Haskell to understand the significance of
>this.

Oh, it is just like this: Suppose that we use the list concatenation of
two list as the constructor for lists. In C++ pseudo-code:
  class list {
  public:
    list(const list& x, const list& y) {
      // Construct *this as the concatenation of x and y }
  };
Also, in pattern matching assume this constructor has the symbol ++. Then
the line
    f(x ++ y) = ... (formula in x, y)
should, when this function is used as f(z), where z is a list, be able to
apply the pattern "x ++ y" and derive what the quantities "x" and "y"
should be. This does not work, however, because the function constructor
is not (using a mathematical term) injective; in general, for each z,
there are more than pair (x, y).

That is, the constructor function
    ++: list x list -> list
does not have the property that a value in the codomain "list" has a
_unique_ value in the domain "list x list" of the "++" function. (If, on
the other hand, there would be not such "reverse image lifting by the
constructor function, then one would say that the patterns does not match,
and go to the next pattern in the list.)

Instead, one restricts oneself in languages like Haskell and Prolog to a
few simple functions like x:xs,
    A x list(A) -> list(A)
Here, for every list y = x:xs in the codomain, one can always determine
when there is a first component x (i.e., when the list has length > 0),
and uniquely determine the "tail" of the list xs is such a case.

>From the mathematical point of view, there is not a problem to admit
arbitrary constructor functions (even though they are not injective). But
one must then either impose the condition that the definition in the RHS
is independent of this lifting in the LHS side pattern match (this is in
fact a very common approach of defining new functions in math), or accept
that the function is "multivalued", i.e., the return value is a set, and
not a single element (in math, this approach shows up in complex analysis,
for example).

In a computer language, there is, from the generalistic point of view, the
problem to pin down these different situations and find something that
works in a computer implementation.

So for C++, one could probably consider those ideas, but I figure that one
would stay on the conservative side, and just put in things that are
well-known, and known to work well.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

remove.haberg@matematik.su.se (Hans Aberg) wrote in message news:<remove.haberg-0306021251310001@du134-226.ppp.su-anst.tninet.se>...
[snip]
> >  switch (l)
> >  {
> >    case (Cons *cons) : return 1 + length(cons->next);
> >    case (Nil *)      : return 0;
> >    default (List *)  : throw "unknown subclass of List";
> >  }
[snip]
> >* reorder freely (except some degenerate cases),
[snip]
> The question is how to communicate such data to the compiler in a general
> fashion. For example, if one knows that functions are pure, their
> computational order can be re-arranged.

What I had in mind was rearranging the case branches that do not
overlap. I mentioned this to stress, that testing the conditions do
not involve executing the constructors, so there is no need to pay
attention to side-effects. Previously presented extension of switch
had this problem (although conceptually it was quite a different
construct, orthogonal to the one presented here).

Regards
Grzegorz

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <23b84d65.0205291735.208a70d6@posting.google.com>,
Allan_W@my-dejanews.com (Allan W) wrote:

>>.. But C++ could add
>> its own high level construct, why not call it "cases":
>>
>>   cases (v) {
>>     case e_1: s_1;
>>     ...
>>     case e_k: s_k;
>>   };
>> This would work so that expressions v == e_1, ..., v == e_k are evaluated
>> sequentially, and on the first value "true", say for v == e_i, the
>> corresponding statement s_i is executed, whereafter "cases" ends (unless
>> there are some jumps).
...
>Hmmm. I've seen this type of thing before. I think it was in some COBOL
>programs that I saw the equivalent

Check Haskell http://haskell.org. I recall that in Haskell (like in SML
and some other functional languages), one can define functions by patterns
   f []     = a
   f (x:xs) = b
which internally is translated to something like (C++ pseudo-code)
   f y = cases (y) {
     case []:     return a;
     case (x:xs): return b;
     default: do_default;
   };

>Unlike C++, when switch/case works this way the default case must
>always come last.

It becomes like a sequence of logical filters or mathematical sets, where
the earlier steps will gulp up everything its set covers. Thus, there is
no point in putting later a specialization of what is covered together
logically by the earlier steps.

> Also, I suspect that the ability to optimize is
>much more rare than it is in C++; basically, you HAVE to treat it
>like a series of if/then statements (never tested this assumption,
>though).

Unless the language is provided with some constructs, making it possible
to deduce whether the steps must be computed sequentially or not.

One can note, first that constructs has been in use for a long time in
other languages (like functional languages). Then, I am told that the fact
that statements can be rearranged in a "switch" statement and that is
useful in optimizations is largely an illusion, because, most there is not
good way to implement the "switch" statement anyhow, but to use a series
of "if" statements.

>I might have missed the beginning of this thread.

I missed that too.

> Did anyone ever
>explain why the proposed changes to switch/case are better than
>an if/else if chain? In the case where you really want sequential
>testing, I find if/else if to be extremely easy to read, write, and
>maintain. What's wrong with it?

I gather one can become used to most. Check some examples from say Haskell
code, where the "cases" construct is used extensively, usually in the form
of pattern matching. It simplifies code greatly.

This is the motivation that I see in it: People seem to want it, and it is
thought to be easy and logical. Clearly, just as in the case of "switch",
one can use "if" code instead.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<remove.haberg-3105021317100001@du131-226.ppp.su-anst.tninet.se>, Hans
Aberg <remove.haberg@matematik.su.se> writes
>One can note, first that constructs has been in use for a long time in
>other languages (like functional languages). Then, I am told that the fact
>that statements can be rearranged in a "switch" statement and that is
>useful in optimizations is largely an illusion, because, most there is not
>good way to implement the "switch" statement anyhow, but to use a series
>of "if" statements.

Where did you find this 'information'? Once you get more than a few
cases in a switch statement compilers usually use one of two strategies:

1) A jump table based on the value of the control variable
2) an indirect jump table in which the index is computed from the value.

The major point of either technique is that all cases are treated on
level terms and you do not have to process a number of if's to access
later cases.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

remove.haberg@matematik.su.se (Hans Aberg) wrote in message news:<remove.haberg-3105021317100001@du131-226.ppp.su-anst.tninet.se>...
> Check Haskell http://haskell.org. I recall that in Haskell (like in SML
> and some other functional languages), one can define functions by patterns

Pattern matching in Haskell is based on the fact, that every value
contains information on which "constructor" has created it. E.g.
values of list type have two constructors: nilary constructor [] and
binary constructor `:`, and looking at list value runtime can tell,
which constructor has been used to create it. The constructors are
used to form patterns. In C++ the values have no unique
"constructions". However there is an analogy between Haskell value and
C++ dynamic type, thus your list example can be translated into:

struct List { virtual ~List() {} };
struct Cons : public List { int value; List *next; } ;
struct Nil  : public List { } ;

int size(List *l)
{
  switch (l)
  {
    case (Cons *cons) : return 1 + length(cons->next);
    case (Nil *)      : return 0;
    default (List *)  : throw "unknown subclass of List";
  }
}

Currently this code can be simulated with dynamic_cast, but when
compiler sees it as a dedicated construct it is able to:

* reorder freely (except some degenerate cases),

* optimize by emitting new virtual functions for classes taking part
  in switches.

Unfortunately, this technique kills encapsulation (but enables
multiple dispatch).

Best regards
Grzegorz

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <c8c98175.0206010716.4d6e7adc@posting.google.com>, Grzegorz
Jakacki <jakacki@cidc.com.cn> writes
>remove.haberg@matematik.su.se (Hans Aberg) wrote in message news:<remove.haberg-3105021317100001@du131-226.ppp.su-anst.tninet.se>...
>> Check Haskell http://haskell.org. I recall that in Haskell (like in SML
>> and some other functional languages), one can define functions by patterns
>
>Pattern matching in Haskell is based on the fact, that every value
>contains information on which "constructor" has created it. E.g.
>values of list type have two constructors: nilary constructor [] and
>binary constructor `:`, and looking at list value runtime can tell,
>which constructor has been used to create it. The constructors are
>used to form patterns. In C++ the values have no unique
>"constructions".

I am not familiar enough with Haskell to understand the significance of
this. However it is perfectly possible for C++ objects to track which
ctor has been used to construct them:

class X {
   enum ctor{ default_ctor, copy_ctor, type1_ctor ...};
   ctor const which;
...
public:
   X():which(default_ctor)...{...}
   X(X const &):which(copy_ctor)...{...}

....
 };

And, of course, you must provide an assignment operator.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <hx051hDhbK+8Ew+Q@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>One can note, first that constructs has been in use for a long time in
>>other languages (like functional languages). Then, I am told that the fact
>>that statements can be rearranged in a "switch" statement and that is
>>useful in optimizations is largely an illusion, because, most there is not
>>good way to implement the "switch" statement anyhow, but to use a series
>>of "if" statements.
>
>Where did you find this 'information'? Once you get more than a few
>cases in a switch statement compilers usually use one of two strategies:
>
>1) A jump table based on the value of the control variable
>2) an indirect jump table in which the index is computed from the value.

So how do you implement the jump table?

-- You have a large integral type, and some sporadic numbers on which to
jump, the rest not handled by the default case.

I said that this is the table compressions problem, and I can think of a
variety of solutions.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <c8c98175.0206010716.4d6e7adc@posting.google.com>,
jakacki@cidc.com.cn (Grzegorz Jakacki) wrote:
>> Check Haskell http://haskell.org. I recall that in Haskell (like in SML
>> and some other functional languages), one can define functions by patterns
>
>Pattern matching in Haskell is based on the fact, that every value
>contains information on which "constructor" has created it.

This is right, in addition to the translation of a more general (relative
C++) "cases" construction, Haskell has a pattern matching feature,
building on the idea that certain (in Haskell named) "constructors" can be
inverted.

As C++ does not have anything directly corresponding to Haskell
constructors (the C++ constructors can be written to general for this
stuff to work), I decided to exclude that part. I just felt it might take
too much to add something like that to C++, but this does not mean that
the feature is not interesting.

> E.g.
>values of list type have two constructors: nilary constructor [] and
>binary constructor `:`, and looking at list value runtime can tell,
>which constructor has been used to create it. The constructors are
>used to form patterns.

These constructors, used not only in functional language like Haskell, but
also on Prolog type languages, are in fact very special: If one, instead
of the simple x:xs constructor, adds the full list concatenation xs ++ ys
constructor, then problems like unification and pattern matching are
transformed from relatively straightforward problems into very difficult
ones of mathematical group and monoid theory.

> In C++ the values have no unique
>"constructions".

So therefore, it looks as though there is no way to allow such general,
user defined constructors, as is possible in C++, and keep the pattern
matching.

> However there is an analogy between Haskell value and
>C++ dynamic type, thus your list example can be translated into:

>struct List { virtual ~List() {} };
>struct Cons : public List { int value; List *next; } ;
>struct Nil  : public List { } ;

>int size(List *l)
>{
>  switch (l)
>  {
>    case (Cons *cons) : return 1 + length(cons->next);
>    case (Nil *)      : return 0;
>    default (List *)  : throw "unknown subclass of List";
>  }
>}

>Currently this code can be simulated with dynamic_cast, but when
>compiler sees it as a dedicated construct it is able to:

So it might be the case that such a "cases" construction can help in
various frequently occuring situations.

It might be that limited pattern matching can be allowed by digging into
C++'s template system. For example:
template<class X>
const char* what_am_I(X x) {
  cases (X) {
    case int: return "I am an int";
    default: return "I am not an int";
  };
}
The template system would match the cases, discovering that there are two
different implementations required (instead of using the template
specialization system). -- Just an idea, an input that might be used for
something useful.

So it might be case that having look onto such a "cases" construction can
come result in something quite useful to the programmer..

>* reorder freely (except some degenerate cases),

>* optimize by emitting new virtual functions for classes taking part
>  in switches.

The question is how to communicate such data to the compiler in a general
fashion. For example, if one knows that functions are pure, their
computational order can be re-arranged. In a cases construction, one need
in addition to know something the relative generality of those statements,
so that not a statement that is covering up parts of another statement is
computed before that other statement.

This is the "=>" implication order. In C++, perhaps the best way to
express such a relation is via the system of derived classes. (I do not
see the details though.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

remove.haberg@matematik.su.se (Hans Aberg) wrote in message news:<remove.haberg-2305020021200001@du134-226.ppp.su-anst.tninet.se>...
> Carl Daniel wrote:
>
> > Nevertheless, there are many languages which do permit arbirtray types in
> > switch/case constructs, so I doubt there's any technical reason why C++
> > couldn't have been specified that way.
>
> I figure that "switch" is a C legacy that won't change. But C++ could add
> its own high level construct, why not call it "cases":
>
>   cases (v) {
>     case e_1: s_1;
>     ...
>     case e_k: s_k;
>   };
> This would work so that expressions v == e_1, ..., v == e_k are evaluated
> sequentially, and on the first value "true", say for v == e_i, the
> corresponding statement s_i is executed, whereafter "cases" ends (unless
> there are some jumps).
>
> One needs then not worry about optimization problems of "switch" as it is
> a new statement. One can probably do optimizations if C++ supplies the
> right information (like knowledge about pureness and disjointness of the
> value sets { v == e_i }, i = 1, ..., k, etc.), but this is another
> question, again as it is not the old "switch" statement.

Hmmm. I've seen this type of thing before. I think it was in some COBOL
programs that I saw the equivalent of:

    switch (true) {
       case a==1: { ... handle case where a==1 ... }; break;
       case a==2 && b<5: { ... handle this case... }; break;
       case true: { ... this is what C++ currently calls "default"... }
    }

Unlike C++, when switch/case works this way the default case must
always come last. Also, I suspect that the ability to optimize is
much more rare than it is in C++; basically, you HAVE to treat it
like a series of if/then statements (never tested this assumption,
though).

I might have missed the beginning of this thread. Did anyone ever
explain why the proposed changes to switch/case are better than
an if/else if chain? In the case where you really want sequential
testing, I find if/else if to be extremely easy to read, write, and
maintain. What's wrong with it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3CF1A84E.4070406@mail.com>, Hyman Rosen <hyrosen@mail.com> wrote:
>> Isn't it a bit strange to second guess the opinions of a group of people,
>> like the committee, or any individual, instead of letting them speak for
>> themselves?
>
>Not strange at all. I've been reading this group for years,
>from well before the standard was adopted. I believe I have
>some insight into the kinds of things that are acceptable
>and the kinds of things that are not. If anything like this
>cases thing makes it into a revision, I'll eat my hat.

It seems me that you posts contains some contradictions, as you said
something to the effect that are not a member of the committee, but wanted
to join just in order to ensure that the proposal should not be accepted.
If your intuition about the outcomes of future C++ committee work it has
not even started to consider, why join it in order to alter its outcome?
-- It does not seem logical to me.

In my experience, when one sees highly emotional statements like "the C++
committee will do this or that", one can be pretty sure that is used in
order to hide away the fact that there are no real underlying factual
arguments.

-- See my other post for the factual argument about the "cases" construct
I suggested.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <cefd6cde.0205270036.49edb6b@posting.google.com>,
Michiel.Salters@cmg.nl (Michiel Salters) wrote:
>> The suggestion indicated the order.
>
>No, it doesn't. It only indicates the order in which the results of the
>evaluations are compared with the switch-argument.
>E.g.
>j=0;
>switch(6){
>  case j=j+1 : ...
>  case j=j+2 : ...
>  case j=j+3 : ...
>}
>
>The proposal was clear that the first case label is the first to be tested
>against j, but if all case-labels are evaluated first, in reverse order,
>the first case will be 6.

This must a different proposal than my "cases" proposal: I said that the
"case" parts should be evaluated sequentially (in the order written) to
find the first match; then if such a case is found, the corresponding
statement is evaluated; thereafter the whole "cases" statement terminates.

I do not see any problems with order here.

>As my previous example shows, the proposal must be tightened before the
>perception problem decreases.

There may be other things to be consider though: Haskell has such a
construct with pattern matching. One should probably look at such
constructs as well before deciding anything.

>> Isn't it a bit strange to second guess the opinions of a group of people,
>> like the committee, or any individual, instead of letting them speak for
>> themselves?
>
>It's mostly a premature argument; this isn't a real proposal so we can't
>be expected to have final opinions yet. OTOH, he (Hyman Rosen) is right;
>like him I'm not in favor of these kinds of extensions.

I have no use of it myself, but I know that this a "FAR" (Frequently Asked
Request): A lot of people seem to want to have some improvement to get a
high-level switch. Then, if programmers seem to think that they may
benefit from it, it is prudent to give the question at least some
consideration. I think that it was considered for the current C++ standard
but was rejected for some reason.

One should note that the current "switch" does not give much room for
compiler optimization over a sequence of "if"'s: The reason is that one
have a small set of values on an integral type with many values to
implement, and there is no good way to implement this but to use a series
of "if"'s -- or rather, the generalization is the table compression
problem.

Therefore, if one should add a new version of "switch", I think it should
be a high-level construct that really helps the programmer conceptually;
the optimization question is secondary to that.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:
> It seems me that you posts contains some contradictions, as you said
> something to the effect that are not a member of the committee, but wanted
> to join just in order to ensure that the proposal should not be accepted.

There was a smiley on that.

> In my experience, when one sees highly emotional statements like "the C++
> committee will do this or that", one can be pretty sure that is used in
> order to hide away the fact that there are no real underlying factual
> arguments.

That's not a highly emotional statement, just my opinion about what
is likely to happen, based on what I have seen on this newsgroup for
many years. A highly emotional statement would go something like this:
"The cases statement is an abortion that could only have been designed
by a Visual Basic programmer, and a dumb one at that. If the committee
ever allows such a thing, I'm going to switch to writing all my programs
in J# and never use C++ again." See the difference?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <acotm6$t8v$1@glue.ucr.edu>, thp@cs.ucr.edu wrote:
>: Because the committee works by consensus, and I'm certain that
>: there are enough members who will have the same reaction to this
>: that I do.
>
>In fact, if we didn't already have the for-expression, I doubt we
>could get it adopted.  ;-)

Actually, I classified these loop constructs semantically, and I arrived
at the construction where one only has a single "loop" construct, same as
"forever" with the addition of "break" and "continue". Then all other
variations can be viewed as syntactic sugar of that construct.

-- So, forgetting about its heritage, it might be possible to clean up C++
a bit, by removing all syntactic sugar. :-)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:
> Isn't it a bit strange to second guess the opinions of a group of people,
> like the committee, or any individual, instead of letting them speak for
> themselves?

Not strange at all. I've been reading this group for years,
from well before the standard was adopted. I believe I have
some insight into the kinds of things that are acceptable
and the kinds of things that are not. If anything like this
cases thing makes it into a revision, I'll eat my hat.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

remove.haberg@matematik.su.se (Hans Aberg) wrote in message news:<remove.haberg-2405022333100001@du129-226.ppp.su-anst.tninet.se>...
[ proposal for a proposal for switch w/ expressions as case labels ]

> In article <3CEE94AC.4060302@mail.com>, Hyman Rosen <hyrosen@mail.com> wrote:
> >Because it will raise questions on which case labels are
> >evaluated, and in what order.
>
> The suggestion indicated the order.

No, it doesn't. It only indicates the order in which the results of the
evaluations are compared with the switch-argument.
E.g.
j=0;
switch(6){
  case j=j+1 : ...
  case j=j+2 : ...
  case j=j+3 : ...
}

The proposal was clear that the first case label is the first to be tested
against j, but if all case-labels are evaluated first, in reverse order,
the first case will be 6.

> >Because it doesn't solve any problems.
>
> It solves the perception problem of the human user while increasing the
> chance for optimizations, just as with the intent of all language
> constructs.

As my previous example shows, the proposal must be tightened before the
perception problem decreases.

> >Because the committee works by consensus, and I'm certain that
> >there are enough members who will have the same reaction to this
> >that I do.
>
> This does not seem to be a factual argument:
>
> Isn't it a bit strange to second guess the opinions of a group of people,
> like the committee, or any individual, instead of letting them speak for
> themselves?

It's mostly a premature argument; this isn't a real proposal so we can't
be expected to have final opinions yet. OTOH, he (Hyman Rosen) is right;
like him I'm not in favor of these kinds of extensions.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

My answer was stressing the fact that you considered a scenario  which
is already covered by the current semantics: switch condition of class
type and case values of integral type (see below).

Of course if we extended the switch to allow arbitrary types (in case
labels) it sounds natural to define the new semantics in terms of
operator =3D=3D(); and as others have pointed one rule in that case could
be "choose the first that matches". Anyhow that's not what holds with
your example (unless you don't want to force your new semantics to it
and forget backward compatibility; BTW that compatibility would make
such an extension quite a mess but I think the OP question referred to
allowing arbitrary types in C++ from the beginning, in which case
there wouldn't probably be the current conversion on the switch
condition)



> In any event, even the current semantics have issues. Consider my
>example:
>
>MyFoo f;
>switch(f)
>{
> case 1: // code
> case 2: // code
>};
>
> Suppose '(int) f' would return 7 but 'f.operator=3D=3D(int)' would retu=
rn
>'true' for '1' and 'false' for '2'.
>

As I said above here C++ requires f to be converted to integral or
enumeration type. There must be exactly one conversion function that
allows this (otherwise the code is ill-formed). Once f has been
converted let's say to int, then the resulting value is compared with
1 and 2.

I don't know why you insinst; have you checked =A76.4.2 ?


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Niklas Matthies wrote:
> The proposed construct seems a lot more readable and concise than your
> solution. That's one reason why.

Ugh. Fortunately, there is no chance that this construct
or anything like it will be added to C++.

I keep thinking that I should join the committee,
just to make sure :-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<slrnaeqpn1.sg.news_comp.std.c++_expires-2002-07-01@nightrunner.nmhq.net>,
news_comp.std.c++_expires-2002-07-01@nmhq.net (Niklas Matthies) wrote:

>On Thu, 23 May 2002 17:15:07 GMT, Hyman Rosen <hyrosen@mail.com> wrote:
>>  Why in the world would anyone add a new language construct for this?
>>  Just do
>>
>>       const v_type &v_ref = v;
>>            if (v_ref == e_1) { s_1; }
>>       else if (v_ref == e_2) { s_2; }
>>       ...
>>       else if (v_ref == e_k) { s_k; }
>
>The proposed construct seems a lot more readable and concise than your
>solution. That's one reason why.

Right, so called "syntactic sugar" is one, as it helps the user. Please
recall that if the idea was not to help the human user, one could write
binary code directly, bypassing computer languages altogether. :-)

The other reason is that one might elaborate on the "cases" construct,
aiding specialty optimizations (even though I do not have any good
suggestions for that now).

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3CEE4814.3070102@mail.com>, Hyman Rosen <hyrosen@mail.com> wrote:
>> The proposed construct seems a lot more readable and concise than your
>> solution. That's one reason why.

>Ugh. Fortunately, there is no chance that this construct
>or anything like it will be added to C++.

Why?

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:
>>Ugh. Fortunately, there is no chance that this construct
>>or anything like it will be added to C++.
>
> Why?

Because it will raise questions on which case labels are
evaluated, and in what order.

Because it doesn't solve any problems.

Because the committee works by consensus, and I'm certain that
there are enough members who will have the same reaction to this
that I do.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3CEE94AC.4060302@mail.com>, Hyman Rosen <hyrosen@mail.com> wrote:
>Because it will raise questions on which case labels are
>evaluated, and in what order.

The suggestion indicated the order.

>Because it doesn't solve any problems.

It solves the perception problem of the human user while increasing the
chance for optimizations, just as with the intent of all language
constructs.

>Because the committee works by consensus, and I'm certain that
>there are enough members who will have the same reaction to this
>that I do.

This does not seem to be a factual argument:

Isn't it a bit strange to second guess the opinions of a group of people,
like the committee, or any individual, instead of letting them speak for
themselves?

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen <hyrosen@mail.com> wrote:
: Hans Aberg wrote:
:>>Ugh. Fortunately, there is no chance that this construct
:>>or anything like it will be added to C++.
:>
:> Why?

: Because it will raise questions on which case labels are
: evaluated, and in what order.

: Because it doesn't solve any problems.

: Because the committee works by consensus, and I'm certain that
: there are enough members who will have the same reaction to this
: that I do.

In fact, if we didn't already have the for-expression, I doubt we
could get it adopted.  ;-)

Tom Payne




















---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Carl Daniel wrote:

> Nevertheless, there are many languages which do permit arbirtray types in
> switch/case constructs, so I doubt there's any technical reason why C++
> couldn't have been specified that way.

I figure that "switch" is a C legacy that won't change. But C++ could add
its own high level construct, why not call it "cases":

  cases (v) {
    case e_1: s_1;
    ...
    case e_k: s_k;
  };
This would work so that expressions v == e_1, ..., v == e_k are evaluated
sequentially, and on the first value "true", say for v == e_i, the
corresponding statement s_i is executed, whereafter "cases" ends (unless
there are some jumps).

One needs then not worry about optimization problems of "switch" as it is
a new statement. One can probably do optimizations if C++ supplies the
right information (like knowledge about pureness and disjointness of the
value sets { v == e_i }, i = 1, ..., k, etc.), but this is another
question, again as it is not the old "switch" statement.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:
>   cases (v) {
>     case e_1: s_1;
>     ...
>     case e_k: s_k;
>   };

Why in the world would anyone add a
new language construct for this?
Just do

 const v_type &v_ref = v;
      if (v_ref == e_1) { s_1; }
 else if (v_ref == e_2) { s_2; }
 ...
 else if (v_ref == e_k) { s_k; }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 23 May 2002 17:15:07 GMT, Hyman Rosen <hyrosen@mail.com> wrote:
>  Hans Aberg wrote:
> >   cases (v) {
> >     case e_1: s_1;
> >     ...
> >     case e_k: s_k;
> >   };
>
>  Why in the world would anyone add a new language construct for this?
>  Just do
>
>   const v_type &v_ref = v;
>        if (v_ref == e_1) { s_1; }
>   else if (v_ref == e_2) { s_2; }
>   ...
>   else if (v_ref == e_k) { s_k; }

The proposed construct seems a lot more readable and concise than your
solution. That's one reason why.

-- Niklas Matthies
--
Never attribute to malice what can be explained by sheer stupidity.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota wrote:
>
> On Tue, 30 Apr 2002 18:44:01 GMT, David Schwartz
> <davids@webmaster.com> wrote:
>
> [...]
> >
> >       There are reasons. Consider:
> >
> >MyFoo f;
> >
> >switch (f)
> >{
> > case 1:
> >  // code
> > case 2:
> >  // code
> >}
> >
> >       What should happen if MyFoo::operator==(int) returns 'true' for both 1
> >and 2?
> >
>
> I think you completely missed the point.
> We are talking about using non-integral expressions in case labes, not
> in the switch condition.

 Simply switch 'f' with '1' and '2'. Use 'f' and 'g'. The argument
stands, just correct the minor transposition.

 In any event, even the current semantics have issues. Consider my
example:

MyFoo f;
switch(f)
{
 case 1: // code
 case 2: // code
};

 Suppose '(int) f' would return 7 but 'f.operator==(int)' would return
'true' for '1' and 'false' for '2'.

 Say I implement my own boolean type where anything but a '0' means true
and operator==(int) knows this. What happens with:

MyBool f;
switch(f)
{
 case 0: // code for false
 case 3: // code for true
};

 In this case, 'f' is equivalent to '3', but switch gets it wrong. (Not
through any fault of its own).

 IMO, any extenstion of 'switch' makes things worse. It should simply be
deprecated in any but cases involving simple integers or enumerated
values.

 DS

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Schwartz <davids@webmaster.com> writes:

|>   In an event, switch/case is largely obsolete and on many
|>  platforms is actually slower than corresponding if/else code at
|>  low levels of optimization.

I don't know about speed, but a switch is often clearer for the
reader.  (And of course, if I'm worried about speed, I won't be using
the low levels of optimization.)

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Schwartz <davids@webmaster.com> writes:

>  In an event, switch/case is largely obsolete

Virtual functions have reduced the need of switches, but not to the
level of making it useless or obsolete.  It is still the more clear
way to express some multiway conditions in C++.

> and on many platforms is actually slower than corresponding if/else
> code at low levels of optimization.

I wonder what make you concerned by the performance of low levels of
optimization.

--
Jean-Marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Schwartz (davids@webmaster.com) wrote:

DS> and on many platforms is actually slower than
DS> corresponding if/else code at low levels of optimization.

At least on one platform code generated from switch/case
is a lot faster than that from if/else if. And of course
speed is not right factor for choosing between if/else
and case. Readability and ease of maintainance is.

--
Pavel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri,  3 May 2002 17:34:09 GMT, "Pavel Kuznetsov"
<pavel@despammed.com> wrote:

>David Schwartz (davids@webmaster.com) wrote:
>
>DS> and on many platforms is actually slower than
>DS> corresponding if/else code at low levels of optimization.
>
>At least on one platform code generated from switch/case
>is a lot faster than that from if/else if. And of course
>speed is not right factor for choosing between if/else
>and case. Readability and ease of maintainance is.

NOTE: this is not actually a reply to Pavel, but rather a general
remark.

Usually I do not participate in "this is faster... this is less
efficient" threads: they tend to be a quite sterile fight of opinions,
supported by reasonings that base on vagueness their apparent
plausibility. Indeed there is little you can say at this level which
is not an opinion.

The definite answer to the switch/if-else dilemma, as well as to other
similar questions, is *you can't know in general*.

Not even if you go to the assembly output: yes,  you see the output
for a specific source code snippet, but the output could actually
depend on how many case labels you have, whether they all have a
break, whether they have consecutive values or, let's say, whether the
compiler manages to derive a formula that expresses those values as a
function of n, where n is an integer, etc...etc....

Certainly, an implementation is free to do as much analysis as it
wants and translate the same way a switch construct and its
semantically equivalent if-else (I'm not speaking of variable
scope/lifetime and other stuff, obviously).

And "the same way" might even mean equally bad, or equally well.

Now, if your profiler indicates that you must  optimize let's say an
if-else snippet and you *verify* that, in that place, a switch/case is
actually faster, than do the change (and add some comments). Otherwise
don't do harm to you, to anyone will maintain the code and definitely
to your employer choosing the less clear/readable/expressive form.

If you are not convinced about that (humans tend to prefer simple
answers to correct one, i.e. "yes" or "no" to "it depends") please
take a look at

http://developer.intel.com/technology/itj/q41999/articles/art_1.htm

expecially the parts about predication and if-conversion. And since
you are there, take a look at the part about loop unrolling too.

>From our C++ sources we are on a too high level of abstraction to
decide whether a construct is less efficient than another, less than
ever to say if it is *always* more efficient.

Of course I'll be glad to be corrected on any of my statements :)


Genny.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota (gennaro_prota@yahoo.com) wrote:

GP> The definite answer to the switch/if-else dilemma, as well as to
GP> other similar questions, is *you can't know in general*.

Complete agreement on this point. Actually this is
what I implied with my reply to David Schwartz.
You did it better.

--
Pavel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pavel Kuznetsov" <pavel@despammed.com> writes:

|>  David Schwartz (davids@webmaster.com) wrote:

|>  DS> and on many platforms is actually slower than corresponding
|>  DS> if/else code at low levels of optimization.

|>  At least on one platform code generated from switch/case is a lot
|>  faster than that from if/else if.=20

More generally, I would say that the code generated for switch/case
should never be slower than that for if/else if. Because generating a
series of if/else if is a perfectly legitimate way of implementing
switch/case, and if it is the fastest way, the compiler should choose
it.

In practice, I cannot conceive of an architecture on which switch/case
would not be faster for at least some cases of switches.

|>  And of course speed is not right factor for choosing between
|>  if/else and case. Readability and ease of maintainance is.

Unless, of course, profiling has shown that there is a problem, and
that the problem is due to the implementation of switch.

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Schwartz wrote:
>
> Carl Daniel wrote:
>
> > Nevertheless, there are many languages which do permit arbirtray types in
> > switch/case constructs, so I doubt there's any technical reason why C++
> > couldn't have been specified that way.
>
>         There are reasons. Consider:
>
> MyFoo f;
>
> switch (f)
> {
>  case 1:
>   // code
>  case 2:
>   // code
> }
>
>         What should happen if MyFoo::operator==(int) returns 'true' for both 1
> and 2?

The languages that I'm familiar with that allow such constructs, follow
a rule that the case chosen is the first one that matches, even if
muliple cases match.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 30 Apr 2002 18:44:01 GMT, David Schwartz
<davids@webmaster.com> wrote:

[...]
>
> There are reasons. Consider:
>
>MyFoo f;
>
>switch (f)
>{
> case 1:
>  // code
> case 2:
>  // code
>}
>
> What should happen if MyFoo::operator==(int) returns 'true' for both 1
>and 2?
>

I think you completely missed the point.
We are talking about using non-integral expressions in case labes, not
in the switch condition.

With the current rules, the following is legal:


class A {
    public:
 typedef char whatever;
 A(whatever) {}
 operator int() const { return 1;}
};


switch (A a = 'x') {
 case 1:
  /*...*/
 case 2:
  /*...*/
 default:
}

and causes A::operator int() const to be invoked at the evaluation of
A a = 'x' . No operator ==() is currently needed.


P.S.: for Greg Comeau (I hope you are reading...). Comeau online seems
to accept the above switch statement in some cases where A has more
than one conversion function to integral/enumeration types, for
instance:

       operator int() const { return 1;}
       operator char() const {return 'a';}
       operator bool() {return true;}


Anyhow it emits an error if I declare also operator bool() as a
const-function. Isn't this a bug?


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3CCF365F.E06A362A@wizard.net...
> David Schwartz wrote:
> >
> > Carl Daniel wrote:
> >
> > > Nevertheless, there are many languages which do permit arbirtray types
in
> > > switch/case constructs, so I doubt there's any technical reason why
C++
> > > couldn't have been specified that way.
> >
> >         What should happen if MyFoo::operator==(int) returns 'true' for
both 1
> > and 2?
>
> The languages that I'm familiar with that allow such constructs, follow
> a rule that the case chosen is the first one that matches, even if
> muliple cases match.
>

That's the rule I'm familiar with as well.  I seem to recall a Pascaloid
language used internally at Xerox (can't recall the name), that would run
every case which matched.

-cd

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Carl Daniel wrote:

> Nevertheless, there are many languages which do permit arbirtray types in
> switch/case constructs, so I doubt there's any technical reason why C++
> couldn't have been specified that way.

 There are reasons. Consider:

MyFoo f;

switch (f)
{
 case 1:
  // code
 case 2:
  // code
}

 What should happen if MyFoo::operator==(int) returns 'true' for both 1
and 2?

 In an event, switch/case is largely obsolete and on many platforms is
actually slower than corresponding if/else code at low levels of
optimization.

 DS

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Schwartz wrote:
>
>         In an event, switch/case is largely obsolete

I must be behind the times. I use it quite often.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 21 Mar 2002 18:04:50 GMT, "Carl Daniel" <cpdaniel@pacbell.net>
wrote:

>Nevertheless, there are many languages which do permit arbirtray types in
>switch/case constructs, so I doubt there's any technical reason why C++
>couldn't have been specified that way.

At least for why *floating points* are not allowed, the motivation, as
given in both the C89 rationale and the C99 draft rationale, is that
"exact equality in floating point is not portable". There's no clue
however as to why other types are prohibited too. To be honest, I'm
quite suspicious about the "hard to optimize" motivation.


Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Why doesn't the standard allow switch to be used w/ non-integral types?

ex:
  int i;
  char ch;

  //...
  switch i{ // legal -- integral type
    case 1:
      //...
    default:
      //...
  }
  switch ch{ // illegal -- non-integral type
    case 'A':
      //...
    default:
      //...
  }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

char IS an integral type, so you example is valid, assuming you fixed your
switch statements to put the switch expression inside parentheses... (e.g.
switch (i), switch (ch)).

As for truly non-integral types, like std::string, I'd hazzard a guess that
it's because switch was adopted as-is from C, and such things are illegal in
C.

They're illegal in C because the motivation for the switch statement was to
crete a multiway branch that's more efficient than an if/else ladder.  If
non-integral types are allowed as case labels, the compiler will likely have
little option but to generate an if/else ladder - which you could just have
easily written yourself.

Nevertheless, there are many languages which do permit arbirtray types in
switch/case constructs, so I doubt there's any technical reason why C++
couldn't have been specified that way.

-cd

"Robb" <ArchonTreborus@netscape.net> wrote in message
news:6ee7d287.0203202005.63e0b7b3@posting.google.com...
> Why doesn't the standard allow switch to be used w/ non-integral types?
>
> ex:
>   int i;
>   char ch;
>
>   //...
>   switch i{ // legal -- integral type
>     case 1:
>       //...
>     default:
>       //...
>   }
>   switch ch{ // illegal -- non-integral type
>     case 'A':
>       //...
>     default:
>       //...
>   }
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Robb" <ArchonTreborus@netscape.net> wrote in message
news:6ee7d287.0203202005.63e0b7b3@posting.google.com...
> Why doesn't the standard allow switch to be used w/ non-integral types?
>
> ex:
>   int i;
>   char ch;
>
>   //...
>   switch i{ // legal -- integral type
           ^^^

This isn't legal.  The syntax for a switch statement is

    switch (i)
    {
      // ...
    }

Note the brackets.

>     case 1:
>       //...
>     default:
>       //...
>   }

>   switch ch{ // illegal -- non-integral type

No.  A char is an integer type, so this is legal (other than the missing
brackets).

--
Richard Smith


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]