From: Marin David Condic <condicma@bogon.pwfl.com>
Subject: Re: Assertions
Date: 1999/05/12
Date: 1999-05-12T00:00:00+00:00 [thread overview]
Message-ID: <3739E888.2DC68FC0@pwfl.com> (raw)
In-Reply-To: 3739CECA.6A49865B@averstar.com
Tucker Taft wrote:
>
> In any case, here is a strawman:
>
> pragma Assert(boolean_expression [, string_expression]);
>
<snip for brevity>
>
I can imagine that there are any number of issues which might make it
difficult to write a rigorous definition for the pragma. That said, I
still don't think this is sufficient reason to leave it out of a future
standard. If a large number of compilers are including the pragma
anyway, then inclusion in the standard will at least mean *some* level
of safety as to what the feature means/does.
(Wait a minute! That sounds suspiciously like the argument for
legalizing drugs: "Well kids are going to do it anyway, so at least this
way we can make sure they are getting 'healthy' drugs!" I'm not so sure
I like being on this side of the argument! :-)
Where there are going to be difficult issues, there are always the
weasel words "Implementation Defined". Side effects of the boolean
expression? Implementation Defined! At least you'll have common syntax
and chances are that whatever semantic differences exist in theory, in
practice they will likely be "corner cases" or simply uncommon. (I've
seen endless discussion of parameter passing rules, for example, yet
never once encountered a situation in real-world code where it caused a
problem. Either the code never got ported to a different compiler where
behavior was different or, if it did get ported, the code was structured
in such a way as to not rely on the obscure side-effects. Is the
expression "a tempest in a teapot" relevant here?)
Anyway - I think your definition is fine, as long as the appropriate
"Implementation Defined" weasel words are thrown in when the objections
come up.
MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***
Visit my web page at: http://www.flipag.net/mcondic
next prev parent reply other threads:[~1999-05-12 0:00 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-05-10 0:00 Assertions J & A Richardson
1999-05-10 0:00 ` Assertions Marin David Condic
1999-05-11 0:00 ` Assertions Robert Dewar
1999-05-11 0:00 ` Assertions Nick Roberts
1999-05-11 0:00 ` Assertions Robert Dewar
1999-05-12 0:00 ` Assertions Dale Stanbrough
1999-05-12 0:00 ` Assertions Robert Dewar
1999-05-12 0:00 ` Assertions Tucker Taft
1999-05-12 0:00 ` Assertions Larry Kilgallen
1999-05-12 0:00 ` Assertions Tucker Taft
1999-05-13 0:00 ` Assertions Nick Roberts
1999-05-17 0:00 ` Assertions Dale Stanbrough
1999-05-19 0:00 ` Assertions Nick Roberts
1999-05-22 0:00 ` Assertions Dale Stanbrough
1999-05-22 0:00 ` Assertions Robert Dewar
1999-05-22 0:00 ` Assertions Ray Blaak
1999-05-22 0:00 ` Assertions Robert Dewar
1999-05-23 0:00 ` Assertions Nick Roberts
1999-05-24 0:00 ` Assertions Dale Stanbrough
1999-05-24 0:00 ` Assertions Ray Blaak
1999-05-23 0:00 ` Assertions Nick Roberts
1999-05-12 0:00 ` Marin David Condic [this message]
1999-05-18 0:00 ` Assertions Richard D Riehle
1999-05-19 0:00 ` Assertions Nick Roberts
1999-05-19 0:00 ` Assertions Richard D Riehle
1999-05-20 0:00 ` Assertions stimuli
1999-05-21 0:00 ` Assertions Richard D Riehle
1999-05-21 0:00 ` Assertions Robert Dewar
1999-05-20 0:00 ` Assertions Ehud Lamm
1999-05-21 0:00 ` Assertions Robert Dewar
1999-05-21 0:00 ` Assertions Ehud Lamm
1999-05-21 0:00 ` Assertions Tucker Taft
1999-05-20 0:00 ` Assertions stimuli
1999-05-12 0:00 ` Assertions Peter Amey
1999-05-12 0:00 ` Assertions Robert Dewar
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox