Here is a simple standard approach for your purpose:

Scott Langham wrote:
> I often find code that switches on an enum's values. For example:
>
> enum Fruit
> {
>     Apple,
>     Pear,
>     Orange

      ,N_Fruits // last entry

> };
>
>
> void Eat( Fruit f )
> {
>     switch( f )
>     {
>     case Apple:
>         EatApple();
>         break;
>     case Pear:
>         EatPear();
>         break;
>     case Orange:
>         EatOrange()
>         break;

       default:
           assert( N_Fruits == 3 );
           // or even better: a compile_time_assert<bool> template
           break;
>     }
> }
>
> Code like this can often cause problems when used in large projects.

If you want to add another Fruit, just grep for "N_Fruit" to find all
places you have to touch.


Ralph

---
[ 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                       ]

Hello All,

I know in a proper OO language we're supposed to avoid switch statements in
favour of virtual function dispatching. However, I find in real code they
pop up all over the place.

I often find code that switches on an enum's values. For example:

enum Fruit
{
 Apple,
 Pear,
 Orange
};


void Eat( Fruit f )
{
 switch( f )
 {
 case Apple:
  EatApple();
  break;
 case Pear:
  EatPear();
  break;
 case Orange:
  EatOrange()
  break;
 }
}

Code like this can often cause problems when used in large projects. The
Fruit definition might be in one header file that gets included and switched
on in all sorts of places in the code base. The problem with it is that when
one programmer goes and adds Melon to the Fruit definition, they often don't
find and make appropriate adjustments to all of the relevant switch's.
Depending upon what the switches do, this can have different effects ranging
from no problem at all, to catastrophic meltdown. So, in trying to be a good
defensive programmer, if I think a future new Fruit value might mean that
the switch I'm writing will also have to change, I'll add a default case
like this:

void Eat( Fruit f )
{
 switch( f )
 {
 case Apple:
  EatApple();
  break;
 case Pear:
  EatPear();
  break;
 case Orange:
  EatOrange()
  break;
 default:
  assert(false);
  break;
 }
}

Now any switches that were missed when the new Fruit was added will shout at
us. That is assuming that tests are sufficient enough to execute the switch
with the new value, and that the test is running on a debug build. Often
though, mistakes can make it out into the real world before they are
discovered. You might see where I'm going now; a straightforward language
change could prevent this problem at compile time. Here's the new idea, look
out for the explicit keyword:

void Eat( Fruit f )
{
 explicit switch( f )
 {
 case Apple:
  EatApple();
  break;
 case Pear:
  EatPear();
  break;
 case Orange:
  EatOrange()
  break;
 }
}

I'd like the explicit keyword to alter the switch's behaviour for enums such
that if there isn't an explicit case for every enum value, a compiler error
will be generated. Even if there are a few values for which the switch
doesn't need to do anything, this behaviour could still be useful. I find it
quite nice to be able to see from the code that the programmer intended not
to do anything.

void Eat( Fruit f )
{
 explicit switch( f )
 {
 case Apple:
  EatApple();
  break;
 case Pear:
  EatPear();
  break;
 case Orange:
  EatOrange()
  break;

 case Melon:
 case Kiwi:
  // do nothing
  break;
 }
}

This idea could be extended further to help when switching on values with
integral type. Here's a quick stab at some suitable syntax. I'm sure you
guys and gals may have some better ideas.

void DoSomething( int i )
{
 explicit(0,3) switch( i )
 {
 case 0:
  DoZero();
  break;
 case 2:
  DoTwo();
  break;
 }
}

Here the parameters to explicit are the start value, and the number of
cases. I'm not so sure that the use of the explicit keyword really adds much
value in this situation. But, I'm sure that using explicit with enum values
could save a lot of programmers a lot of debugging time.

The good thing about using the keyword 'explicit' is that it's already a
keyword, I don't think there's any ambiguity about it being confused with
its use in other contexts.

-Scott Langham


---
[ 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                       ]

Scott Langham wrote:
>
> Now any switches that were missed when the new Fruit was added will
> shout at us. That is assuming that tests are sufficient enough to
> execute the switch with the new value, and that the test is running on a
> debug build.

Debug build or not, if you test your code properly you'll find this
omission because the behavior that's supposed to occur with the new
enumerator won't occur. And, of course, if you rely on 'explicit switch'
to replace careful testing, how will you insure that you use 'explicit
switch' instead of 'switch' in all the places that you haven't tested?

--

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                       ]

* Pete Becker:
> Scott Langham wrote:
> >
> > Now any switches that were missed when the new Fruit was added will
> > shout at us. That is assuming that tests are sufficient enough to
> > execute the switch with the new value, and that the test is running on a
> > debug build.
>
> Debug build or not, if you test your code properly you'll find this
> omission because the behavior that's supposed to occur with the new
> enumerator won't occur. And, of course, if you rely on 'explicit switch'
> to replace careful testing, how will you insure that you use 'explicit
> switch' instead of 'switch' in all the places that you haven't tested?

Paraphrasing: "if you rely on 'for' to replace careful testing [of 'while'],
how will you insure that you use 'for' instead of 'while' in all the places
that you haven't tested?"

The reason that analogy doesn't quite hold is that 'while' and 'for' are
different keywords, used for different things, so that a perfect program might
still contain a 'while' or two, whereas in the proposal both constructs
include the keyword 'case' and the new one is meant to replace the old one.

This suggests that some keyword other than 'switch' is a good idea, or else,
perhaps let the semantics of 'switch' depend on some configuration macro.

I think a new, less extremely error-prone construct would be a good idea.

I've argued for that before, and the main counter-argument, as I recall, was
that it required a new keyword.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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                       ]

langham_scott@hotmail.com ("Scott Langham") wrote (abridged):
> void Eat( Fruit f )
> {
>  explicit switch( f )

Wouldn't it be better to make the "explicit" part of the type? Meaning
that only named values are legal for the enum. Thus:

    enum Colour { Red, Green, Blue };
    explicit enum Fruit { Apple, Pear, Orange };

    Colour c = Colour(3); // OK, as now.
    Fruit f = Fruit(3); // Undefined behaviour.

Your behaviour for switch would fall out of this, and it would naturally
apply to all switches on Fruit. You couldn't forget one.

I wrote "undefined behaviour" rather than "diagnostic required", because
the compiler couldn't detect more complex cases, but vendors would be
encouraged to warn about ones they could detect.

-- Dave Harris, Nottingham, UK.

---
[ 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                       ]

alfps@start.no (Alf P. Steinbach) wrote (abridged):
> > I do not believe that is the same as the original proposal.  In your
> > scenario, if you have a 'default' clause, 'explicit' is meaningless.
> > This would significantly reduce the usefulness of such a keyword,
> > since the 'default' clause may be there for other purposes (such as
> > error reporting of a bad value converted to the enum).
>
> _If_ that's desirable, which I'm not sure I agree with (but it's an
> interesting angle), how about having the 'switch' reporting a bad value
> for an 'explicit' type by throwing e.g. a std::bad_cast exception?

It doesn't make much sense to me as a switch isn't a cast. As I said
earlier, I'd rather add an invariant to the type. Bad values should be
caught as early as possible, before they are even converted. We shouldn't
wait for them to be switched-on.

I would like to see more support for dynamic checks generally, eg as
extensions for dynamic_cast<>. Boost already has numeric_cast<>, which is
the kind of thing I have in mind, but for enums we really want compiler
support.

    explicit enum Colour { red=0, green=1, blue=5 };

    Colour c1 = dynamic_cast<Colour>( 3 ); // throws.
    Colour c2 = dynamic_cast<Colour>( 1 ); // OK.
    Colour c3 = static_cast<Colour>( rand() ); // ??

    switch (c3) {
    case red: return "red";
    default: return "not red";
    }

Ideally the switch would not need to check that the enum is valid. If
rand() returns too large a number, it should be undefined behaviour. In
practice unchecked casts are too common, unless we make:

    Colour c4 = (Colour) rand();
    Colour c5 = Colour( rand() );

into dynamic checks, which I don't think we should.

-- Dave Harris, Nottingham, UK.

---
[ 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                       ]

"Scott Langham" wrote:
>
> I'd like the explicit keyword to alter the switch's behaviour
> for enums such that if there isn't an explicit case for every
> enum value, a compiler error will be generated.

I don't think this needs a language extension. There are already
compilers which warn on a switch for enums where there is no
default case, and one of the possible enum values has been
omitted.

If the programmer really intended to omit a case, it is
no harder to add a "default: break;" to the end, than it
is to add "explicit" as you suggested.

I, for one, prefer the "opt-out" solution: the compiler will
always warn if you omit a case, unless you tell it to shut up.
Your proposal is an "opt-in" case, which has the problem that
the programmer may forget to opt in.

The same goes for explicit constructors; I think that with
hindsight, most people would have preferred that no
constructors are considered for default conversions,
unless the programmer specifically says so.

I have also heard it argued that pointer and reference types
should have defaulted to 'const', unless the programmer
specifically made them writable.

---
[ 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                       ]

"Alf P. Steinbach" wrote:

> I think a new, less extremely error-prone construct would be a good idea.
>
> I've argued for that before, and the main counter-argument, as I recall,
> was
> that it required a new keyword.
>
It may not:

switch (an_enum) {
  case a: ...
  case b: ...
  ! default: ;
}

where the "! default" must be empty, ignored
and is used ony for enums.

/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                       ]

Dave Harris wrote:

> langham_scott@hotmail.com ("Scott Langham") wrote (abridged):
>
>>void Eat( Fruit f )
>>{
>> explicit switch( f )
>
>
> Wouldn't it be better to make the "explicit" part of the type? Meaning
> that only named values are legal for the enum.

 > explicit enum Fruit { Apple, Pear, Orange };

    Now that actually make sense.

    It can be generalized, too.

    -- Variables or types can be given the "explicit" attribute.
    -- Making a type explicit makes all instances of that type
       explicit.
    -- Making a class or struct explicit makes all its data
       members explicit.
    -- "explicit" is meaningful for all types for which all possible
       stored bit patterns are not valid values. So
       it is meaningful for enum, bool, float, double,
       and all pointers.  It's not meaningful for "int"
       on most machines.
    -- All "explicit" variables must be initialized.
    -- Conversions to an explicit type must be checked, and
 "domain_error" must be raised on a bad conversion.
    -- Switch statements based on explicit variables (even if
       a type for which all values are valid, like "int")
       must either have cases for all possible values or have a
       "default" case.

That would be a consistent restriction - "explicit" means
"contains a valid value at all times".  (Admittedly it
won't detect dangling pointers, but it will prevent
uninitialized ones.)

    John Nagle
    Animats

---
[ 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                       ]

Hi

Scott Langham wrote:

> The problem with it
> is that when one programmer goes and adds Melon to the Fruit definition,
> they often don't find and make appropriate adjustments to all of the
> relevant switch's. Depending upon what the switches do, this can have
> different effects ranging from no problem at all, to catastrophic
> meltdown.

My compiler (g++ 3.3.5) tells me:
warning: enumeration value `Melon' not handled in switch

I think most compilers will emit a similar warning.

IMHO this is all you need. I think that there is absolutely no need to bloat
the language.

 Markus

---
[ 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                       ]

Alf P. Steinbach wrote:

>>
>>Debug build or not, if you test your code properly you'll find this
>>omission because the behavior that's supposed to occur with the new
>>enumerator won't occur. And, of course, if you rely on 'explicit switch'
>>to replace careful testing, how will you insure that you use 'explicit
>>switch' instead of 'switch' in all the places that you haven't tested?
>
>
> Paraphrasing: "if you rely on 'for' to replace careful testing [of 'while'],
> how will you insure that you use 'for' instead of 'while' in all the places
> that you haven't tested?"

That is not a paraphrase; I was talking about switch, and you changed it
to for and while.

>
> The reason that analogy doesn't quite hold is that 'while' and 'for' are
> different keywords, used for different things, so that a perfect program might
> still contain a 'while' or two, whereas in the proposal both constructs
> include the keyword 'case' and the new one is meant to replace the old one.
>

'while' and 'for' are (almost) completely interchangeable, and the
choice of one over the other is generally a matter of style, not
meaning. If you are arguing that this difference is unnecessary, and we
should have only one, I might be inclined to agree, except that they're
well established, and removing 'while' would break existing code. But
prior design errors do not justify new design errors.

> I think a new, less extremely error-prone construct would be a good idea.

Do you have numbers to back up "extremely error-prone"? And numbers to
back up your implicit assertion that requiring all cases to be handled
would reduce the frequency of errors without imposing excessive costs
(for example, having to write code to handle all cases even though your
design says they won't occur in some places)?

--

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                       ]

===================================== MODERATOR'S COMMENT:
  Please avoid top-posting in replies.


===================================== END OF MODERATOR'S COMMENT
In the real world, even proper code testing doesn't elimiate all bugs. Even
where testers think they have reasonably tested code to an acceptable level,
software can be the cause of loss of human life. I want all the help I can
get from my tools and the language to help prevent bugs enter the system
before testing even begins.

Explicit switch is an aid to help write less buggy code, I don't think
anybody wouldn't rely on it to replace careful testing... just in the exact
same way that programmers use 'const'. Const is also an aid to help
programmers write less buggy code, there's nothing that forces you to use
const appropriately, but programmers find bennefit from const. They find
benefit from using 'explicit' for appropriate constructors too, why not
switches also?

-Scott Langham


"Pete Becker" <petebecker@acm.org> wrote in message
news:lOCdnX6w3eS_kMrfRVn-hA@giganews.com...
> Scott Langham wrote:
>>
>> Now any switches that were missed when the new Fruit was added will shout
>> at us. That is assuming that tests are sufficient enough to execute the
>> switch with the new value, and that the test is running on a debug build.
>
> Debug build or not, if you test your code properly you'll find this
> omission because the behavior that's supposed to occur with the new
> enumerator won't occur. And, of course, if you rely on 'explicit switch'
> to replace careful testing, how will you insure that you use 'explicit
> switch' instead of 'switch' in all the places that you haven't tested?
>
> --
>
> 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                       ]
>


---
[ 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                       ]

* Pete Becker:
> Alf P. Steinbach wrote:
>
> >>
> >>Debug build or not, if you test your code properly you'll find this
> >>omission because the behavior that's supposed to occur with the new
> >>enumerator won't occur. And, of course, if you rely on 'explicit switch'
> >>to replace careful testing, how will you insure that you use 'explicit
> >>switch' instead of 'switch' in all the places that you haven't tested?
> >
> >
> > Paraphrasing: "if you rely on 'for' to replace careful testing [of 'while'],
> > how will you insure that you use 'for' instead of 'while' in all the places
> > that you haven't tested?"
>
> That is not a paraphrase; I was talking about switch, and you changed it
> to for and while.
>
> > The reason that analogy doesn't quite hold is that 'while' and 'for' are
> > different keywords, used for different things, so that a perfect program might
> > still contain a 'while' or two, whereas in the proposal both constructs
> > include the keyword 'case' and the new one is meant to replace the old one.
> >
>
> 'while' and 'for' are (almost) completely interchangeable, and the
> choice of one over the other is generally a matter of style, not
> meaning. If you are arguing that this difference is unnecessary, and we
> should have only one, I might be inclined to agree, except that they're
> well established, and removing 'while' would break existing code. But
> prior design errors do not justify new design errors.

I think anybody could be bewildered if someone responded to each individual
word (with lengthy explanations) instead of to the words' combined meaning;
the above seems to me to be like that but at the sentence level.


> > I think a new, less extremely error-prone construct would be a good idea.
>
> Do you have numbers to back up "extremely error-prone"?

No, such numbers probably do not exist, and that point is not contested;
it's rather silly to ask for numbers for that.


> And numbers to  back up your implicit assertion that requiring all cases to be handled
> would reduce the frequency of errors without imposing excessive costs
> (for example, having to write code to handle all cases even though your
> design says they won't occur in some places)?

_Excessive cost_ to write "default:"?

This posting that I'm replying to doesn't make sense.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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                       ]

Scott Langham wrote:

> ===================================== MODERATOR'S COMMENT:
>   Please avoid top-posting in replies.
>
>
> ===================================== END OF MODERATOR'S COMMENT
> In the real world, even proper code testing doesn't elimiate all bugs. Even
> where testers think they have reasonably tested code to an acceptable level,
> software can be the cause of loss of human life. I want all the help I can
> get from my tools and the language to help prevent bugs enter the system
> before testing even begins.

Then program is Pascal. People say it does that. <g>

>
> Explicit switch is an aid to help write less buggy code, I don't think
> anybody wouldn't rely on it to replace careful testing... just in the exact
> same way that programmers use 'const'. Const is also an aid to help
> programmers write less buggy code, there's nothing that forces you to use
> const appropriately, but programmers find bennefit from const. They find
> benefit from using 'explicit' for appropriate constructors too, why not
> switches also?
>

There are many things that people think would make their code better.
For most of those things there is no concrete evidence to support their
position. const has been proven over time. explicit switch has not.

--

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                       ]

===================================== MODERATOR'S COMMENT:


Would all posters in this thread please ensure that personal attacks are
avoided, as is required by the charter of this group.

Moderation policy should not have allowed the previous post; apologies
for the oversight in allowing the questionable post through to  the
group.
We are all human (so far).


===================================== END OF MODERATOR'S COMMENT
Alf P. Steinbach wrote:

>
>>>I think a new, less extremely error-prone construct would be a good idea.
>>
>>Do you have numbers to back up "extremely error-prone"?
>
>
> No, such numbers probably do not exist, and that point is not contested;
> it's rather silly to ask for numbers for that.
>

Huh? How is it silly to ask what data backs up your assertion?
Especially when your answer is "none"?

>
> This posting that I'm replying to doesn't make sense.
>

Moderators, please pay more attention. This comment is out of line.

--

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                       ]

* Pete Becker:
>
> ===================================== MODERATOR'S COMMENT:
>
> Would all posters in this thread please ensure that personal attacks are
> avoided, as is required by the charter of this group
>
> Moderation policy should not have allowed the previous post; apologies
> for the oversight in allowing the questionable post through to  the
> group.
> We are all human (so far).

I must assume that refers to my comment that a posting didn't make
sense.

That was not meant as a personal attack.


> ===================================== END OF MODERATOR'S COMMENT
> Alf P. Steinbach wrote:
>
> >
> >>>I think a new, less extremely error-prone construct would be a good idea.
> >>
> >>Do you have numbers to back up "extremely error-prone"?
> >
> > No, such numbers probably do not exist, and that point is not contested;
> > it's rather silly to ask for numbers for that.
>
> Huh? How is it silly to ask what data backs up your assertion?

A different question than numbers.

I don't think it's silly to ask for the basis of an assertion, but that
is very different from asking for statistics.

The problems of 'switch' have been discussed numerous times in this forum,
over the years, with several proposal for making it safer.

AFAIK no-one have, earlier, questioned that unsafety; it's that common an
experience.

You'll find the missing 'break' and the 'dfault:' and failure to include all
cases listed in a host of "common errors" lists; and from a language
design perspective at least one language, C#, has now tackled some of that.

It would be nice if C++ could develop in that direction too.

Several good proposal have been forthcoming in this thread; the best,
IMO, the proposal to declare types as 'explicit' (I think that's simply
brilliant  --  no change of 'switch' syntax, no change of semantics for
existing code, and yet a guarantee where it matters for new code).


> Especially when your answer [regarding statistics] is "none"?

It's simply not relevant.

There's no need for statistics on problems caused by e.g. 'goto', and I
doubt it makes it into the top five coding errors (casts, macros,
uninitialized, IIRC), but it's Bad; likewise for C/C++ 'switch'.

I repeat the question snipped at the end below: exactly how can writing
"default:" constitute an excessive cost?

That doesn't make sense to me.

And add one more: how should I be able to comply with the request to provide
statistics on a hypothetical non-existing situation for C++, "numbers to  back
up your implicit assertion that requiring all cases to be handled would reduce
the frequency of errors without imposing excessive costs (for example, having
to write code to handle all cases even though your design says they won't
occur in some places)"?

I have not implied such a thing, because it doesn't make sense: it's trivial
to avoid excessive costs.

Perhaps there exists numbers for e.g. Ada, but I'm not a statistic-service for
hypotheticals, especially not for undesirable hypotheticals.


> > This posting that I'm replying to doesn't make sense.
>
> Moderators, please pay more attention. This comment is out of line.

That doesn't make sense to me as a technical argument.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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 <425e1d37.2072148093@news.individual.net>,
 alfps@start.no (Alf P. Steinbach) wrote:

> You'll find the missing 'break' and the 'dfault:' and failure to include all
> cases listed in a host of "common errors" lists; and from a language
> design perspective at least one language, C#, has now tackled some of that.

However, this proposal does not address the missing 'break' case.

> I repeat the question snipped at the end below: exactly how can writing
> "default:" constitute an excessive cost?

I do not believe that is the same as the original proposal.  In your
scenario, if you have a 'default' clause, 'explicit' is meaningless.
This would significantly reduce the usefulness of such a keyword, since
the 'default' clause may be there for other purposes (such as error
reporting of a bad value converted to the enum).

What I believe that the original poster was proposing is that every
label in an enum must be handled explicitly in the switch statement and
not implicitly by a 'default' clause.  In this way, if someone adds a
label to an enum, the program won't compile until the explicit switch
statements are fixed.

Not that I agree with this proposal.  Virtual functions are a better,
more scalable solution for this sort of thing, precisely because you can
localize where the change has to go.  New features shouldn't be
encouraging not so good idioms...

Regards,
 Nevin ":-)" Liber

---
[ 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                       ]

* Nevin ":-]" Liber:
> [snip]
>
> > I repeat the question snipped at the end below: exactly how can writing
> > "default:" constitute an excessive cost?
>
> I do not believe that is the same as the original proposal.  In your
> scenario, if you have a 'default' clause, 'explicit' is meaningless.
> This would significantly reduce the usefulness of such a keyword, since
> the 'default' clause may be there for other purposes (such as error
> reporting of a bad value converted to the enum).

_If_ that's desirable, which I'm not sure I agree with (but it's an
interesting angle), how about having the 'switch' reporting a bad value for an
'explicit' type by throwing e.g. a std::bad_cast exception?

Which would preserve the usual meaning of 'default:'.

I guess this question is just as much directed to Dave Harris and John
Nagle, who may have superior ideas & viewpoints.


[snip]

> Not that I agree with this proposal.  Virtual functions are a better,
> more scalable solution for this sort of thing, precisely because you can
> localize where the change has to go.  New features shouldn't be
> encouraging not so good idioms...

Each way has its uses, IMO.

Virtual functions impose a number costs that may not be acceptable in
a given situation:

* Cost of knowing that much of the language (i.e., safety is provided only
  if you know enough, not for the causal maintenance programmer or newbie).

* Cost of implementing a number of a classes every place you'd otherwise
  have a simple enum.

* Cost of losing C compatibility (POD'ness), if there was a class in the first
  place.

* Cost of more memory usage due to hidden v-table pointer, or whatever
  mechanism the implementation uses.

* Run-time execution cost of virtual calls.

In conflict with the "don't pay for what you don't need" C++ language design
guideline.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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                       ]