Nesting if statements in switch structures

[Technoid]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?

switch(freq)
{
case 1: CASENAME
if (variable==1)
{
do some code
}
else
{
do some other code
}
break;
case 2:
.
.
.

The compiler says we have a syntax error on the if statement.

 

[Robert Gamble]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?
Yes.

switch(freq)
{
case 1: CASENAME
if (variable==1)
{
do some code
}
else
{
do some other code
}
break;
case 2:

The compiler says we have a syntax error on the if statement.

I don't know what CASENAME is supposed to be but it is a syntax error,
everything else looks okay, conceptionally. It would much more helpful
if you provided the exact code that caused the error and the exact
error message, why wouldn't you do this?

Robert Gamble

 

[Eric Sosman]

Technoid wrote On 04/04/06 15:19,:

Is it possible to have a conditional if structure nested inside a
conditional switch structure?

Yes.

switch(freq)
{
case 1: CASENAME
if (variable==1)
{
do some code
}
else
{
do some other code
}
break;
case 2:
.
.
.

The compiler says we have a syntax error on the if statement.

Get rid of `CASENAME', for starters. Then
replace `do some code' and `do some other code'
with valid code.

 

[Michael Mair]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?
Yes.

switch(freq)
{
case 1: CASENAME
if (variable==1)
{
do some code
}
else
{
do some other code
}
break;
case 2:
.
.
.

The compiler says we have a syntax error on the if statement.

This nicely illustrates why it makes sense to provide
a compiling minimal example. If the above is copied from
your code, then remove CASENAME.
Apart from that consider

#include <stdio.h>

enum A_VAL { SOME_VAL, SOME_OTHER_VAL, TEN_VAL = 10 };

#define MAGIC 42

int main (void)
{
int a;
double b;

a = TEN_VAL;
b = 7.5;

switch (a) {
case SOME_VAL:
case SOME_OTHER_VAL:
puts("AllowedVal");
break;
case TEN_VAL:
if (b * MAGIC >= a + MAGIC) {
puts("TenMagic");
} else {
puts("TenMundane");
}
break;
default:
puts("Default");
break;
}

return 0;
}

Compiles and links.

Cheers
Michael

 

[Ivanna Pee]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?

Only on the condition that you unconditionally know how to nest
conditions.

 

[blufox]

remove CASENAME

 

[Keith Thompson]

Only on the condition that you unconditionally know how to nest
conditions.

[...]

You've posted four responses in this newsgroup. One of them was
actually meaningful; the others have been completely useless, and not
nearly as funny as you think.

If you want to participate here, feel free to do so. If not, please
go away.

 

[Keith Thompson]

remove CASENAME

From what?

Read <http://cfaj.freeshell.org/google/>.

 

[Ian Collins]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?

Yes - but I'd suggest you don't, call an appropriately named function
instead. I makes the code easier to read and maintain.

 

[Al Balmer]

Yes - but I'd suggest you don't, call an appropriately named function
instead. I makes the code easier to read and maintain.

Depends. Often I'd rather have a simple conditional in front of me
than buried in a function somewhere else.

 

[Julian V. Noble]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?

switch(freq)
{
case 1: CASENAME
if (variable==1)
{
do some code
}
else
{
do some other code
}
break;
case 2:
.
.
.

The compiler says we have a syntax error on the if statement.

It's possible (with the correction noted by others), but IMO it's
a VERY poor idea. Whenever you nest decision structures it means
you haven't thought the problem through very well. Worse, you are
asking for trouble because the resulting code is harder to read
and MUCH harder to debug. The usual problem is accidentally putting
in logical conditions that are either impossible to realize or two
or more conditions that are not mutually exclusive and can lead to
unexpected behavior. The first creates dead code that may not be
positively harmful, but is certainly unprofessional. The second can
produce bugs that are sporadic and therefore hard to track down. I
know, because I have committed both errors in my time.

In C, using switch, you can easily generate a finite state machine.
Table-based FSM's are clear to understand and handle most logic
problems without resorting to nested decision structures. Sad
experience leads me to recommend the FSM approach to complex logic.

--
Julian V. Noble
Professor Emeritus of Physics

http://galileo.phys.virginia.edu/~jvn/

"For there was never yet philosopher that could endure the
toothache patiently."

-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.

 

[Ian Collins]

Depends. Often I'd rather have a simple conditional in front of me
than buried in a function somewhere else.

Simple is the key word there!

 

[Al Balmer]

Simple is the key word there!

Agreed. Julian's point is well taken, also. If you find that you need
conditionals in a switch, consider the possibility that there's a
better way to approach the problem.

 

[Richard Bos]

It's possible (with the correction noted by others), but IMO it's
a VERY poor idea. Whenever you nest decision structures it means
you haven't thought the problem through very well.

Fiddlesticks. To illustrate, here's a paraphrase of code I wrote
recently, in another language:

switch (object.type) {
case TextFrame:
if (adjust_content)
fit_header_width(object);

fit_frame_content(object);
object.length+=descender;
break;

case ImageFrame:
if (adjust_content) {
fit_image_frame_minimal(object);
if (object.content.width<object.width)
fit_image_frame_maximal();
}
fit_frame_content(object);
break;

default:
message("Can't fit that.");
break;
}

where adjust_content is a (user-provided) parameter to the fitting
procedure. Care to explain how I'd have done this more clearly with a
single switch?

Richard

 

[Ivanna Pee]

Only on the condition that you unconditionally know how to nest
conditions.

[...]

You've posted four responses in this newsgroup. One of them was
actually meaningful; the others have been completely useless, and not
nearly as funny as you think.

If you want to participate here, feel free to do so. If not, please
go away.

OK. Alright I'll let you do all of the homework assignments posted
here. When I was learning C, 17+ years ago, we learned by reading
manuals, trial and error, instrumenting code and debugging. Suffering
over bugs, then eventually sovling them. That is how you learn. You
learn because you know that you never want to make that mistake again,
and so it sinks in fast, real fast. You think you are helping these
kids, but you are not. They need to learn how to learn, not have a
teacher over their shoulder pointing out bugs.

If you want to participate here, throw hints/suggestions at the OPs
design / coding problem. Do not give specifics, as I see you frequently
do, unless of course the question is a specific C question.

 

[Julian V. Noble]

Fiddlesticks. To illustrate, here's a paraphrase of code I wrote
recently, in another language:

switch (object.type) {
case TextFrame:
if (adjust_content)
fit_header_width(object);

fit_frame_content(object);
object.length+=descender;
break;

case ImageFrame:
if (adjust_content) {
fit_image_frame_minimal(object);
if (object.content.width<object.width)
fit_image_frame_maximal();
}
fit_frame_content(object);
break;

default:
message("Can't fit that.");
break;
}

where adjust_content is a (user-provided) parameter to the fitting
procedure. Care to explain how I'd have done this more clearly with a
single switch?

Richard

To every sad experience there are exceptions. Your example is simple
enough that it is still clear, although it might have been clearer had
the actions for each case been factored out as separate subroutines
with names that indicate what they do, i.e.

switch (object.type) {

case TextFrame:
fitText(adjust_content,object);
break;

case ImageFrame:
fitImage(adjust_content,object);
break;

default:
message("Can't fit that.");
break;
}

where the if's are factored into the subroutines. If your language
permits ? marks in names you could indicate the conditionality by
naming the routines ?fitText and ?fitImage , and it would be even
clearer. But these are stylistic decisions and "de gustibus non
disputandum est", after all.

How bad it gets depends on how deeply it is nested. Moreover, there
are other useful decision structures, such as decision tables. One
is not limited to FSM's, of course.

--
Julian V. Noble
Professor Emeritus of Physics

http://galileo.phys.virginia.edu/~jvn/

"For there was never yet philosopher that could endure the
toothache patiently."

-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.

 

[Al Balmer]

To every sad experience there are exceptions. Your example is simple
enough that it is still clear, although it might have been clearer had
the actions for each case been factored out as separate subroutines
with names that indicate what they do, i.e.

As you say, it's in the eye of the beholder, but I find Richard's
version clearer than yours. It tells me immediately what
"adjust_content" is good for. In your version, I would be surprised to
go to fitText() only to find out that the passed parameter was used
only to return without doing anything. In fact, I would factor out
that useless parameter

 

[Keith Thompson]

If you want to participate here, throw hints/suggestions at the OPs
design / coding problem. Do not give specifics, as I see you frequently
do, unless of course the question is a specific C question.

Sadly, you've chosen to introduce yourself to this newsgroup by acting
like a particularly obnoxious troll. It's not inconceivable that you
might have a valid point, but you've already destroyed your chance of
being taken seriously. Calling yourself "Ivanna Pee" doesn't help
either. That's life.

You're not the first person to jump in here and tell us we've been
running this newsgroup wrong for all these years.

BTW, it's rarely necessary to quote the entire article to which you're
replying; in particular, don't quote the signature unless you're
actually commenting on it.

 

[Joe Wright]

Simple is the key word there!

Indeed.

 

[Old Wolf]

Is it possible to have a conditional if structure nested inside a
conditional switch structure?

switch(freq)
{
case 1: CASENAME
if (variable==1)
{
do some code
}
else
{
do some other code
}
break;
case 2:

The compiler says we have a syntax error on the if statement.

That's caused by CASENAME.

You can even do this:

switch(freq)
{
case 1:
if ( variable == 1 )
some_code();
else
case 2:
some_other_code();
}

Also possible is:

switch(freq)
{
case 1:
if ( variable == 1 )
{
some_code();
case 2:
some_other_code();
}
break;
}