Topic: extend(C/C++) || die() ;-)
Author: seebs@solon.com (Peter Seebach)
Date: 1997/01/03 Raw View
In article <MPLANET.32cabbcbjcoffin989b09@news.rmi.net>,
Jerry Coffin <jcoffin@taeus.com> wrote:
>However, none of Borland's C or C++ compilers (nor their ancestor,
>Wizard C) has _ever_ included such an option - all of them have done
>short-circuit evaluation of boolean expressions since day 1. (day 1
>being a _very_ long time ago indeed - even the CP/M versions of Wizard
>C had this right, around 10 years before the C standard existed...)
Now I'm confused; I was sure I recalled someone suggesting that option
as a "solution". However, looking at it now, I don't see any such thing.
(I do see an option for "nested comments", though.)
Perhaps it was a different compiler, or it was an option that no one sane
used. (I'm quite sure they didn't have the broken behavior *by default*.)
(All I can check is 4.52; other versions may vary.)
*sigh*. That's the problem with reading about compilers.
-s
--
Copyright 1996 Peter Seebach - seebs at solon.com - C/Unix Wizard
I am not actually dns-admin@earthlink.net but junk mail is accepted there.
The *other* C FAQ, the hacker FAQ, et al. http://www.solon.com/~seebs
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: seebs@solon.com (Peter Seebach)
Date: 1996/12/31 Raw View
In article <5a233t$tv6$1@nntpd.lkg.dec.com>,
Norman Diamond <diamond@tbj.dec.com> wrote:
>Since B didn't have C's || and && operators, B compilers tended to treat |
>and & in if-expressions as if they were C's || and &&, which was convenient
>though pedantically incorrect in B. In C it would have been unnecessary
>and incorrect from day 1, so I really doubt that implementors would do that.
(http://www.lysator.liu.se/c/dmr-on-or.html)
dmr says "Early C had no separate operators for & and && or | and ||.".
Thus, it wouldn't have been unnecessary *from day 1*. It became unnecessary
fairly early on. (However, it is this early confusion that gives us the
dubious precedence of & and |. As dmr said,
After all, we had several hundred kilobytes
of source code, and maybe 3 installations....
...)
It is true that we've had &&/|| for a *very* long time, and that only a
mind-numbingly strange excuse could lead to an implementation offering an
option of non-short-circuit boolean operators.
Lest anyone wonder, it would also require a mind-numbingly strange excuse to
not link the floating-point capable version of printf in a program which
declares objects of floating-point types, and the same implementation (can)
get both of these wrong.
Borland C/C++ had the no-short-circuit option, and still may, "for
compatability with Turbo Pascal". I guess the installed base has, yet again,
produced something incomprehensible.
-s
p.s.: I am on the C committee. DEC has a rep on the C committee. Norman is
not that rep. Ergo, I have not discussed the C standard or language with
Norman; any statements in my post that appear to relate to statements in his
are entirely illusory.
--
Copyright 1996 Peter Seebach - seebs at solon.com - C/Unix Wizard
I am not actually dnsadmin@earthstar.com but junk mail is accepted there.
The *other* C FAQ, the hacker FAQ, et al. http://www.solon.com/~seebs
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1997/01/02 Raw View
In article <5abo0h$6r1@solutions.solon.com>, seebs@solon.com says...
[ ... ]
> Borland C/C++ had the no-short-circuit option, and still may, "for
> compatability with Turbo Pascal". I guess the installed base has,
> yet again, produced something incomprehensible.
Not so - Turbo Pascal 4.0 and newer have an option to allow full
evaluation for compatibility with older versions of their Pascal
compiler. (The J&W definition of Pascal didn't define whether boolean
evaluation was short-circuited or not, so neither is a violation of
much of anything.)
However, none of Borland's C or C++ compilers (nor their ancestor,
Wizard C) has _ever_ included such an option - all of them have done
short-circuit evaluation of boolean expressions since day 1. (day 1
being a _very_ long time ago indeed - even the CP/M versions of Wizard
C had this right, around 10 years before the C standard existed...)
--
Later,
Jerry.
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1996/12/23 Raw View
Oleg Krivosheev <kriol@fnal.gov> writes:
>if you change first line in main to
>
> doit() || (die(), 1); // or doit() || (die(), true);
>
>it works just fine [...]
Yes, but that defeats any readability advantage.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Walter Briscoe <walter@wbriscoe.demon.co.uk>
Date: 1996/12/23 Raw View
I find that declaring die as "int die();" works for me. The minor
irritation of a return value not actually being generated does not
bother me. The same must happen in any function which calls abort(),
exit(), longjmp(), etc. I find that declaring die as
"int die(const char *fmt, ...)" and implementing it with the combined
semantics of fprintf to stderr and abort covers most needs. In certain
environments, exit or longjmp would be more appropriate death methods.
It strikes me as such a useful little thing that I would like to see it
in the standard. Mind you, I would find it difficult to express a
generally acceptable specification and would also like to see return,
break, continue etc allowed as expressions to facilitate compact writing
such as:
morework || return;
which seems a reasonable concise form of
if (!morework) return;
I admit to the influence of Perl and Algol68, but recognise that I shall
have to live with current practice. :)
In article <59c0vl$9v0@mulga.cs.mu.OZ.AU>, Fergus Henderson
<fjh@mundook.cs.mu.OZ.AU> writes
>b91926@fsui02.fnal.gov (David Sachs) writes:
>
>>Of course in c++ (or c for that manner), you could write the statement as:
>>
>>open(FILE, file) || die(); // C++ is not Pascal
>
>In K&R C it worked fine, but unfortunately this particular idiom
>died in ANSI C and C++.
>
> void die() { die(); die(); } /* die a nasty death */
> int doit() { return 1; }
> int main() {
> doit() || die();
> return 0;
> }
>
[snip]
--
Walter Briscoe
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: herbs@cntc.com (Herb Sutter)
Date: 1996/12/23 Raw View
On 19 Dec 1996 18:27:25 PST, fjh@mundook.cs.mu.OZ.AU (Fergus
Henderson) wrote:
>>Of course in c++ (or c for that manner), you could write the statement as:
>>
>>open(FILE, file) || die(); // C++ is not Pascal
>
>In K&R C it worked fine, but unfortunately this particular idiom
>died in ANSI C and C++.
>
> void die() { die(); die(); } /* die a nasty death */
> int doit() { return 1; }
> int main() {
> doit() || die();
> return 0;
> }
[suggests change to draft to allow the above code]
<humour>
Heck, if we're using "||" to get rid of an "if" anyway, why not go all
the way and avoid those bothersome braces too:
open(FILE, file) || ( die(), evil(), death() );
</humour>
(I think Fergus was just kidding, but I'm playing it safe... :-)
---
Herb Sutter (herbs@cntc.com)
Current Network Technologies Corp.
3100 Ridgeway, Suite 42, Mississauga ON Canada L5L 5M5
Tel 416-805-9088 Fax 905-608-2611
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Michael R Cook <mcook@cognex.com>
Date: 1996/12/23 Raw View
>>>>> "HS" == Herb Sutter <herbs@cntc.com> writes:
HS> <humour>
HS> Heck, if we're using "||" to get rid of an "if" anyway, why not go all
HS> the way and avoid those bothersome braces too:
HS> open(FILE, file) || ( die(), evil(), death() );
Surely you meant
open(FILE, file) || die() - evil() - death();
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: herbs@cntc.com (Herb Sutter)
Date: 1996/12/26 Raw View
On 22 Dec 1996 06:34:55 GMT, Chelly Green <chelly@eden.com> wrote:
>Why is this thread still alive? Is there something wrong with the
>OBVIOUS
>
> if ( !doit() ) die();
>
>Is it too hard to say what you mean?
I was originally going to write a reply saying just that, but then
realised that this thread is probably intended as a csc++ new year's
joke. :-)
---
Herb Sutter (herbs@cntc.com)
Current Network Technologies Corp.
3100 Ridgeway, Suite 42, Mississauga ON Canada L5L 5M5
Tel 416-805-9088 Fax 905-608-2611
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: "F. van Leeuwen" <fvl@iaehv.nl>
Date: 1996/12/27 Raw View
Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote
> Oleg Krivosheev <kriol@fnal.gov> writes:
>
> >if you change first line in main to
> >
> > doit() || (die(), 1); // or doit() || (die(), true);
> >
> >it works just fine [...]
>
> Yes, but that defeats any readability advantage.
>
Who's talking about readability?
Why not just use if?
doit() || die();
if (!doit()) die();
It uses THREE characters more. Using the '||' way has
the disadvantage that it is not compatible with those
buggy compilers that evaluate the second part of the
or-statement in any case. (Yes there are such nasty
compilers!)
Frank.
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: phalpern@truffle.ma.ultranet.com (Pablo Halpern)
Date: 1996/12/27 Raw View
fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>Hence, I propose the following extension to ANSI C and C++: the
>right-hand operand of `&&' and `||' expressions may have void type;
>if so, the `&&' or `||' expression itself has void type.
Better yet, adopt a control construct from the Babage Computer Language.
For those of you unfamiliar with Babage, it came out just when Ada was
getting a lot of press. Ada was named after Ada of Lovelace, "the first
computer programmer." Babage is named after Lord Babage, the inventer of
the difference engine, who died in poverty with his invention still
incomplete. The Babage Computer Language, therefore, was named after the
first systems engineer to run overbudget and behind schedule ;-)
The solution to the "doit() || die()" problem, therefore, is to adopt
Babage's "do it or else" control construct :-)
-------------------------------------------------------------
Pablo Halpern phalpern@truffle.ultranet.com
I am self-employed. Therefore, my opinions *do* represent
those of my employer.
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: "Clive D.W. Feather" <Clive@on-the-train.demon.co.uk>
Date: 1996/12/27 Raw View
In article <32c60921.5050079@news.ma.ultranet.com>, Pablo Halpern
<phalpern@truffle.ma.ultranet.com> writes
>Babage is named after Lord Babage, the inventer of
>the difference engine,
It's "Babbage" and "Difference Engine". And he wasn't a peer, so not
"Lord" either.
--
Clive D.W. Feather | Associate Director | Director
Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd.
Fax: +44 181 371 1150 | <clive@demon.net> | <cdwf@cityscape.co.uk>
Written on my laptop - please reply to the Reply-To address <clive@demon.net>
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: diamond@tbj.dec.com (Norman Diamond)
Date: 1996/12/30 Raw View
In article <01bbf3ec$866c5a60$b34697c2@fvl.iaehv.nl>, "F. van Leeuwen" <fvl@iaehv.nl> writes:
>Using the '||' way has the disadvantage that it is not compatible with those
>buggy compilers that evaluate the second part of the or-statement in any case.
In order to pander to compilers that are so severely buggy as this, it would
be necessary to omit the entire program.
>(Yes there are such nasty compilers!)
Actuall I doubt it. There might have been ("ought" to have been, IMHO)
B compilers which would do that even in if-expressions, exactly as defined
in both the B and C language. But I doubt it in C+=n compilers.
Since B didn't have C's || and && operators, B compilers tended to treat |
and & in if-expressions as if they were C's || and &&, which was convenient
though pedantically incorrect in B. In C it would have been unnecessary
and incorrect from day 1, so I really doubt that implementors would do that.
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1996/12/19 Raw View
b91926@fsui02.fnal.gov (David Sachs) writes:
>Of course in c++ (or c for that manner), you could write the statement as:
>
>open(FILE, file) || die(); // C++ is not Pascal
In K&R C it worked fine, but unfortunately this particular idiom
died in ANSI C and C++.
void die() { die(); die(); } /* die a nasty death */
int doit() { return 1; }
int main() {
doit() || die();
return 0;
}
Here's the obituaries:
GNU C
die.c:4: void value not ignored as it ought to be
DEC C
cc: Error: die.c, line 4: In this statement, "die(...)" has
void type, but occurs in a context that requires a non-void
result.
doit() || die();
--------------------------^
DEC OSF C
/usr/lib/cmplrs/cc/cfe: Error: die.c, line 4: Reference an
expression of void type or an incomplete type. (3.2.2.1)
doit() || die();
-------------^
LCC
die.c:4: operands of || have illegal types `int' and `void'
die.c:4: operands of != have illegal types `void' and `int'
[huh? say what??]
Sun C
"die.c", line 4: operand cannot have void type: op "||"
"die.c", line 4: operands must have scalar type: op "||"
SGI C
(4) Error: Reference of an expression of void type or an
incomplete type.
Cfront
"die.c", line 4: error: void operand for ||
GNU C++
die.c:4: void value not ignored as it ought to be
Sun C++
"die.c", line 4: Error: A value of type void is not allowed.
SGI C++
"die.c", line 4: error(3134): expression must have arithmetic or
pointer type
doit() || die();
^
Hence, I propose the following extension to ANSI C and C++: the
right-hand operand of `&&' and `||' expressions may have void type;
if so, the `&&' or `||' expression itself has void type.
C++ DWP changes required: in
] 5.14 Logical AND operator [expr.log.and]
replace
] 1 logical-and-expression:
] inclusive-or-expression
] logical-and-expression && inclusive-or-expression
] The && operator groups left-to-right. The operands are both implic-
] itly converted to type bool (_conv_). The result is true if both
] operands are true and false otherwise. Unlike &, && guarantees left-
] to-right evaluation: the second operand is not evaluated if the first
] operand is false.
]
] 2 The result is a bool. All side effects of the first expression except
] for destruction of temporaries (_class.temporary_) happen before the
] second expression is evaluated.
with
[ 1 logical-and-expression:
[ inclusive-or-expression
[ logical-and-expression && inclusive-or-expression
[ The && operator groups left-to-right. The first operand is
[ implicitly converted to type bool. Unlike &, && guarantees left-
[ to-right evaluation: the second operand is not evaluated if the first
[ operand is false. If the second operand has
[ type (possibly cv-qualified) void, then the result has type void.
[ Otherwise the second operand is implicitly converted to type bool,
[ and the result has type bool; the result is true if both
[ operands are true and false otherwise.
[
[ 2 All side effects of the first expression except
[ for destruction of temporaries (_class.temporary_) happen before the
[ second expression is evaluated.
and similarly for "5.15 logical OR operator [expr.log.or]".
Oh, and it's pretty easy to implement too.
Here's a patch to gcc-2.7.2.1 which implements it.
--- c-typeck.c.orig Sun Jun 30 02:27:15 1996
+++ c-typeck.c Fri Dec 20 04:05:58 1996
@@ -1782,13 +1782,31 @@
enum tree_code code;
tree arg1, arg2;
{
- tree result = build_binary_op (code, arg1, arg2, 1);
+ tree result;
char class;
char class1 = TREE_CODE_CLASS (TREE_CODE (arg1));
char class2 = TREE_CODE_CLASS (TREE_CODE (arg2));
enum tree_code code1 = ERROR_MARK;
enum tree_code code2 = ERROR_MARK;
+
+ /* As an extension to ANSI C, we allow `&&' and `||' expressions with a
+ right-hand operand of type void, for code such as `errno == 0 || abort()'.
+ We implement this by simply replacing expressions such as
+ `FOO && (void) BAR' with `FOO ? (void) BAR : 0', and
+ `FOO || (void) BAR' with `FOO ? 1 : (void) BAR'. */
+ if ((code == TRUTH_ANDIF_EXPR || code == TRUTH_ORIF_EXPR)
+ && TREE_CODE (TREE_TYPE(arg2)) == VOID_TYPE)
+ {
+ if (pedantic)
+ pedwarn ("ANSI C forbids right-hand operand to `%s' of type void",
+ (code == TRUTH_ANDIF_EXPR ? "&&" : "||"));
+ result = (code == TRUTH_ANDIF_EXPR
+ ? build_conditional_expr(arg1, arg2, integer_zero_node)
+ : build_conditional_expr(arg1, integer_one_node, arg2));
+ }
+ else
+ result = build_binary_op (code, arg1, arg2, 1);
if (class1 == 'e' || class1 == '1'
|| class1 == '2' || class1 == '<')
--- cp/typeck.c.orig Fri Dec 20 03:50:17 1996
+++ cp/typeck.c Fri Dec 20 04:11:48 1996
@@ -2853,6 +2853,23 @@
if (code == MEMBER_REF)
return build_m_component_ref (build_indirect_ref (arg1, NULL_PTR),
arg2);
+
+ /* As an extension to ANSI C++, we allow `&&' and `||' expressions with a
+ right-hand operand of type void, for code such as `errno == 0 || abort()'.
+ We implement this by simply replacing expressions such as
+ `FOO && (void) BAR' with `FOO ? (void) BAR : 0', and
+ `FOO || (void) BAR' with `FOO ? 1 : (void) BAR'. */
+ if ((code == TRUTH_ANDIF_EXPR || code == TRUTH_ORIF_EXPR)
+ && TREE_CODE (TREE_TYPE(arg2)) == VOID_TYPE)
+ {
+ if (pedantic)
+ pedwarn ("ANSI C forbids right-hand operand to `%s' of type void",
+ (code == TRUTH_ANDIF_EXPR ? "&&" : "||"));
+ return (code == TRUTH_ANDIF_EXPR
+ ? build_conditional_expr(arg1, arg2, integer_zero_node)
+ : build_conditional_expr(arg1, integer_one_node, arg2));
+ }
+
return build_binary_op (code, arg1, arg2, 1);
}
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Oleg Krivosheev <kriol@fnal.gov>
Date: 1996/12/21 Raw View
Hi,
fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
> b91926@fsui02.fnal.gov (David Sachs) writes:
>
> >Of course in c++ (or c for that manner), you could write the statement as:
> >
> >open(FILE, file) || die(); // C++ is not Pascal
>
> In K&R C it worked fine, but unfortunately this particular idiom
> died in ANSI C and C++.
>
> void die() { die(); die(); } /* die a nasty death */
> int doit() { return 1; }
> int main() {
> doit() || die();
> return 0;
> }
if you change first line in main to
doit() || (die(), 1); // or doit() || (die(), true);
it works just fine under gcc (ansi, predantic, Wall) and
SUN cc/CC (strict ANSI mode).
IMHO, it's just good enough not to introduce changes
in the language.
YMMV
merry xmas
OK
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Chelly Green <chelly@eden.com>
Date: 1996/12/22 Raw View
Oleg Krivosheev wrote:
>
> Hi,
>
> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
> > b91926@fsui02.fnal.gov (David Sachs) writes:
> >
> > >Of course in c++ (or c for that manner), you could write the statement as:
> > >
> > >open(FILE, file) || die(); // C++ is not Pascal
> >
> > In K&R C it worked fine, but unfortunately this particular idiom
> > died in ANSI C and C++.
> >
> > void die() { die(); die(); } /* die a nasty death */
> > int doit() { return 1; }
> > int main() {
> > doit() || die();
> > return 0;
> > }
>
> if you change first line in main to
>
> doit() || (die(), 1); // or doit() || (die(), true);
>
> it works just fine under gcc (ansi, predantic, Wall) and
> SUN cc/CC (strict ANSI mode).
>
> IMHO, it's just good enough not to introduce changes
> in the language.
No, I think we need an even "better" solution:
template<class T>
inline void pass_or_call( T const& ret, void (*func)() )
{
if ( !ret ) func();
}
Oh, wait, if we want to give arguments to die()... Hmmm
template<class T,class A1>
inline void pass_or_call( T const& ret, void (*func)( A1 ), A1 a1 )
{
if ( !ret ) func( a1 );
}
// using A2, etc.
Hmmm, maybe we could introduce a callback mechanism. Yeah, it would only
add a few hundred lines. But darn it, it would be even cooler!
<sarcasm off>
Why is this thread still alive? Is there something wrong with the
OBVIOUS
if ( !doit() ) die();
Is it too hard to say what you mean?
--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]