This might save some untidy work-around, or much worse, copy-
pasting. Let me know if you have a nice neat alternative.
Here's an example of reading a book on weekends, but not weekdays.
Naturally, there could be many more things done on a weekend.
P.
if (Day == Saturday)
{
WalkInPark();
}
else if (Day == Sunday)
{
AttendChurch();
}
also
{
ReadABook();
}
else
{
GoToWork();
}
This is not very clear.
On what days do you ReadABook() ?
On what days do you GoToWork() ?
Do you intend the 'also' code to always execute after *any* branch of the if
statement is taken (bearing in mind there are multiple if statements in
there), and the final else part after *no* branches have been taken?
I doubt whether C is going to provide any new control statements (and even
then they will take a decade or two to become commonplace).
The simplest way is to just use regular logic statements:
if day == saturday or day == sunday
if day == saturday
walkinpark
else
attendchurch
readabook
else
gototowork
--
Bartc
That's one way [and probably what I'd pick] an alternative is to use a
flag, if the "also" block occurs later [non-contiguous] e.g.
flag = 0;
if (a) { flag = 1; ... }
else if (b) { flag = 1; ... }
...code....
if (flag) { ... }
It comes up in protocol parsing enough if anything things I'd like to
see are things like 'case' supporting expressions that result in
things other than integers...
Tom
Saturday, Sunday
> On what days do you GoToWork() ?
When the day is neither Saturday nor Sunday (i.e. Monday - Friday)
> Do you intend the 'also' code to always execute after *any* branch of the
> if
> statement is taken (bearing in mind there are multiple if statements in
> there), and the final else part after *no* branches have been taken?
Yes. Either one 'if' and the 'also' will execute, or only the 'else' will.
> I doubt whether C is going to provide any new control statements (and even
> then they will take a decade or two to become commonplace).
Yes, I very much doubt this, but I sometimes see large chunks copied and
pasted,
and think it could be done more neatly.
> The simplest way is to just use regular logic statements:
>
> if day == saturday or day == sunday
> if day == saturday
> walkinpark
> else
> attendchurch
> readabook
> else
> gototowork
>
Yes, that's about the neatest possible. I'd just prefer to avoid repeating
the condition,
and I find the extra level of containment makes it less readable. Also, if
there are
more days being tested, then the topmost 'if' gets a bit bulky.
Thanks,
P.
switch / case can be made to work: :-)
switch (Day)
{
case Saturday: WalkInThePark () ;
if (0)
{
case Sunday : AttendChurch () ;
}
ReadABook () ;
break ;
default :
GoToWork () ;
break ;
}
Truly horrible (and, yes, I know you know it is!). I think I'd repeat
the ReadABook() function call, but if all repetition is to be avoided
and you need something that scales to more complex tests:
if (Day == Saturday)
WalkInPark();
else if (Day == Sunday)
AttendChurch();
else {
GoToWork();
goto day_over;
}
/* Day not over yet... */
ReadABook();
day_over:
If this were a function with nothing else to do, I'd use an early
return rather than the goto. So, having introspected, my internal
taste meter would prefer (in order):
(a) Small duplication of code other than a test/condition.
(b) Duplication of a simple condition.
(c) Early return.
(d) Goto.
(e) Flag setting and testing.
No idea why anyone would care what my taste would be, but Usenet
thrives on people saying what they think even if no one cares.
Of course, if the weekend test can be inverted, I'd probably never had
the issue:
if (weekday(Day))
GoToWork();
else {
if (Day == Saturday)
WalkInPark();
else AttendChurch();
ReadABook();
}
though, logically, this still has a duplicated test in it. I.e. I'll
bump (b) to the top of the list is I can hide the fact that I'd doing
it. I may need to think on that a bit more.
--
Ben.
See if you can get your church to meet in the park. Even better, if the
park provides seating and sufficient light for reading (which, I guess
would be a prerequisite for holding church services there), your
conditional expression becomes trivial. If the provisions of the C
language are not a good fit to your lifestyle, it is probably simpler to
change your lifestyle than to introduce new keywords into C.
Tony
What about:
****/
switch (Day) {
case Saturday:
WalkInPark();
goto weekend;
case Sunday:
AttendChurch();
weekend:
ReadABook();
break;
default:
GoToWork();
break;
}
/*********************
HTH,
AvK
> Paul wrote:
> switch (Day)
> {
> case Saturday: WalkInThePark () ;
>
> if (0)
> {
> case Sunday : AttendChurch () ;
> }
> ReadABook () ;
> break ;
> default :
> GoToWork () ;
> break ;
>
> }
LOL!
AvK
If your taste is against goto, there is:
do
{
if (Day == Saturday)
WalkInPark();
else if (Day == Sunday)
AttendChurch();
else
{
GoToWork();
break; // out of do..while(0)
}
// Day is Saturday or Sunday
ReadABook();
}
while(0);
Fran�ois Grieu
If your taste is against goto, there is:
do
{
if (Day == Saturday)
WalkInPark();
else if (Day == Sunday)
AttendChurch();
Given that "break" is a (limited) goto in disguise, a lot of people who
have an opposition to goto also have an opposition to break.
Personally (where used appropriately), I don't mind either break or
goto.
That said, I would probably prefer (for the sake of clarity) duplication
of the call than (potentially) obscuring the meaning with goto or break.
I'd be happy that I understood it, but not 100% sure that someone
debugging it at some stage in the future wouldn't misread it.
Can you re-write that in a way which reflects how C interprets it?
I.e. starting with:
if (Day == Saturday)
{
WalkInPark();
}
else
if (Day == Sunday)
{
AttendChurch();
}
At this point, is the "also" associated with the outer "if" or the inner
"if"?
Note that C doesn't have an "else if" statement. The "else" clause can
contain any statement; this can be an "if" statement, or something else.
Even if it *is* an "if" statement, it doesn't get treated any differently
because it's an "if" statement or because it's within an "else" clause.