Home > Archive > Fortran > March 2006 > C style compound assignment operators
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
C style compound assignment operators
|
|
| Bernhard Enders 2006-03-23, 7:04 pm |
| How is it possible to have C-style compound assignment operators (+=,
-=, /=, ++, --, etc...) in Fortran without having to assign them names
like .increment., .decrement., and so on? TIA,
Bernhard.
| |
| Richard E Maine 2006-03-23, 7:04 pm |
| Bernhard Enders <bgeneto@gmail.com> wrote:
> How is it possible to have C-style compound assignment operators (+=,
> -=, /=, ++, --, etc...) in Fortran without having to assign them names
> like .increment., .decrement., and so on? TIA,
The question seems to presume that it is possible. That presumption is
false. It is not possible.
Furthermore, it is not possible even if you do assign them names. The
arguments for defined operations are required to be intent(in).
I will avoid going off into the minefield of discusssing matters of
personal style or preference here. I'll just stick to the facts, which
are that you can't do that.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Bernhard Enders 2006-03-23, 7:04 pm |
| I really miss those compound operators, I'm not adjudicating their use
here, as you said it's a matter of style and (I think) it is also a
least action principle. Thanks anyway,
Bernhard.
| |
| Dan Nagle 2006-03-23, 7:04 pm |
| Hello,
Bernhard Enders wrote:
> I really miss those compound operators, I'm not adjudicating their use
> here, as you said it's a matter of style and (I think) it is also a
> least action principle. Thanks anyway,
Again, avoiding the style question, the answer seems to be:
Program your editor or use a preprocessor.
A long (100+ posts IIRC) in comp.lang.ada wasn't ended
until someone posted the emacs lisp to add += et al.
to ada-mode.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| glen herrmannsfeldt 2006-03-23, 7:04 pm |
| Bernhard Enders <bgeneto@gmail.com> wrote:
> How is it possible to have C-style compound assignment operators (+=,
> -=, /=, ++, --, etc...) in Fortran without having to assign them names
> like .increment., .decrement., and so on? TIA,
I think he means that it would be a possible addition to the
language, without running into ambiguities. Things are different
in C, which considers assignment as an expression, where an ordinary
assignment is a special case.
The /= (not equal) operator would not conflict with the /=
(divide assign) operator because they appear in different places.
(As long as you don't allow assignment inside expressions.)
i /= 2
is an assignment statement, as i.ne.2 is not a legal statement.
if(i /= 2) stop
is a comparison, as assignment isn't legal inside an IF.
Note that PL/I uses = for both assignment and comparison without
any conflict. (Other than possible confusion for C programmers.)
-- glen
| |
| glen herrmannsfeldt 2006-03-23, 7:04 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> Bernhard Enders wrote:
(snip)
[color=darkred]
> Program your editor or use a preprocessor.
Actually, yes, the Mortran preprocessor allows them,
as a fairly simple macro expansion. (All of Mortran
is implemted as macros.)
-- glen
| |
| Richard E Maine 2006-03-23, 7:04 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> I think he means that it would be a possible addition to the
> language, without running into ambiguities.
Oh. That's not how I was reading it.... and I still don't think I'd read
it that way, but to answer that question just in case...
Regardless of whether it would introduce ambiguities or not, no, there
isn't a way to have it added to the language because there is no way it
would pass (in my estimatin). People have asked before. Those proposals
don't tend to get enough support to go anywhere.
But that gets into the areas I'm not interested in debating. So,
although it is certainly my personal opinion and evaluation, consider it
to be just my opinion of the likelihood of such a thing passing -
independent of the separate question of whether I would or would not
like it to. My opinion is that the odds are negligable.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-03-23, 7:04 pm |
| Bernhard Enders wrote:
> How is it possible to have C-style compound assignment operators (+=,
> -=, /=, ++, --, etc...) in Fortran without having to assign them names
> like .increment., .decrement., and so on? TIA,
Well, I *know* I've read an article that documents the
productivity of users of these kinds of features against
the productivity of users whose language requires
assignment to be only at the statement level. The
users of expression-level assignments were less
productive. Some of the earlier such work is
summarized in "Language Design for Programming
Reliability", Gannon and Horning, IEEE Transactions
on Software Engineering, vol. se-1, no. 2, June 1975.
That's the paper I have ready to hand. Follow the
citations in the paper, and citations of it as listed
in your friendly citation reference to find more
papers on the subject.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Dick Hendrickson 2006-03-23, 7:04 pm |
|
Richard E Maine wrote:
> Bernhard Enders <bgeneto@gmail.com> wrote:
>
>
>
>
> The question seems to presume that it is possible. That presumption is
> false. It is not possible.
>
> Furthermore, it is not possible even if you do assign them names. The
> arguments for defined operations are required to be intent(in).
Sure, but the = operator can be intent inout for the left
hand side. It would be tedious, but straight-forward in a
tricky way, to use defined operators, things like
i = .plu d.(2)
as a longhand for
i = i + 2
A little bit tricky to get right with all of the possible
type conversions, and certainly a minefield for the poor
guy who gets stuck with maintaining the code.
I can't think of a way to do infix ++ operators, but this
at least lets anyone do the storage related things.
Dick Hendrickson
>
> I will avoid going off into the minefield of discusssing matters of
> personal style or preference here. I'll just stick to the facts, which
> are that you can't do that.
>
| |
| beliavsky@aol.com 2006-03-23, 7:04 pm |
| James Giles wrote:
> Bernhard Enders wrote:
>
> Well, I *know* I've read an article that documents the
> productivity of users of these kinds of features against
> the productivity of users whose language requires
> assignment to be only at the statement level. The
> users of expression-level assignments were less
> productive. Some of the earlier such work is
> summarized in "Language Design for Programming
> Reliability", Gannon and Horning, IEEE Transactions
> on Software Engineering, vol. se-1, no. 2, June 1975.
> That's the paper I have ready to hand. Follow the
> citations in the paper, and citations of it as listed
> in your friendly citation reference to find more
> papers on the subject.
I can see how the availability of the ++ and -- operators could cause
more programmer errors -- it's easy to get the precedence wrong. But +=
etc. seems safe and convenient, comparing
aaa%bbb%ccc(i) = aaa%bbb%ccc(i) + 1
with
aaa%bbb%ccc(i) += 1
Since the first version is longer, it is easier to make a typo (that
still compiles). The second version is more concise and easier to read
IMO. More complicated-looking expressions can appear before an equal
sign in Fortran 90 (derived types, arrays) than Fortran 77, and I think
that makes compound assignment more valuable.
| |
| Dan Nagle 2006-03-23, 7:04 pm |
| beliavsky@aol.com wrote:
<snip a bunch>
> aaa%bbb%ccc(i) = aaa%bbb%ccc(i) + 1
>
> with
>
> aaa%bbb%ccc(i) += 1
>
> Since the first version is longer, it is easier to make a typo (that
> still compiles). The second version is more concise and easier to read
> IMO. More complicated-looking expressions can appear before an equal
> sign in Fortran 90 (derived types, arrays) than Fortran 77, and I think
> that makes compound assignment more valuable.
Use an f03 associate block:
associate( p => long%thingo(i,j,k)%with(i,j,k)%bunch%jun
k )
p = p + 1
end associate
IIRC, NAG supports this one now.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Tom Micevski 2006-03-23, 7:04 pm |
| beliavsky@aol.com wrote:
> I can see how the availability of the ++ and -- operators could cause
> more programmer errors -- it's easy to get the precedence wrong. But +=
> etc. seems safe and convenient, comparing
>
> aaa%bbb%ccc(i) = aaa%bbb%ccc(i) + 1
>
> with
>
> aaa%bbb%ccc(i) += 1
>
> Since the first version is longer, it is easier to make a typo (that
> still compiles). The second version is more concise and easier to read
> IMO. More complicated-looking expressions can appear before an equal
> sign in Fortran 90 (derived types, arrays) than Fortran 77, and I think
> that makes compound assignment more valuable.
if you were looking for extra safety, couldn't you just create a new
function/subroutine to increment a variable? eg.
call increment (aaa%bbb%ccc(i),1)
| |
| Richard E Maine 2006-03-23, 7:04 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> Use an f03 associate block:
>
> associate( p => long%thingo(i,j,k)%with(i,j,k)%bunch%jun
k )
>
> p = p + 1
>
> end associate
>
> IIRC, NAG supports this one now.
Or, of course, the f77-ish
call increment(long_thingo, 1)
has been with us for.. well... quite a while. Ok, neither of the names
increment and long_thingo are f77 compliant, but the subroutine call is.
You have to write a subroutine anyway to do defined operations, so the
comparison isn't really in the subroutine, but just in the syntax of
invoking it.
The associate block does handily cut down a lot on the verbosity of
having to write out a separate subroutine and interface block.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Paul Van Delst 2006-03-23, 7:04 pm |
| beliavsky@aol.com wrote:
> James Giles wrote:
>
>
>
> I can see how the availability of the ++ and -- operators could cause
> more programmer errors -- it's easy to get the precedence wrong. But +=
> etc. seems safe and convenient, comparing
>
> aaa%bbb%ccc(i) = aaa%bbb%ccc(i) + 1
>
> with
>
> aaa%bbb%ccc(i) += 1
I never understood the attraction of assignment operators. From my C text I'm told that:
j *= k + 3
is equivalent to
j = j * (k + 3)
not
j = j * k + 3
Goodness ... there's no ambiguity there.[*]
cheers,
paulv
[*] Sarcasm alert for the irony impaired. :o)
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
| |
| James Giles 2006-03-23, 7:04 pm |
| beliavsky@aol.com wrote:
....
> I can see how the availability of the ++ and -- operators could cause
> more programmer errors -- it's easy to get the precedence wrong. But
> += etc. seems safe and convenient, comparing
>
> aaa%bbb%ccc(i) = aaa%bbb%ccc(i) + 1
>
> with
>
> aaa%bbb%ccc(i) += 1
>
> Since the first version is longer, it is easier to make a typo (that
> still compiles). The second version is more concise and easier to read
> IMO. More complicated-looking expressions can appear before an equal
> sign in Fortran 90 (derived types, arrays) than Fortran 77, and I
> think that makes compound assignment more valuable.
But, here you are not using the result of the assignment in the
middle of a further expression. The latter is the subject of the
experiment(s) I documented referenced earlier. I *think* that
I've read a paper on the specific use you're talking about, but
I can't find the reference. Yes, I can see that it's occasionally
convenient. I'm not sure it's worth the proliferation of
assignment operators. (And yes, this *is* a case where Fortran's
concept of operators can be made to fit: assignment operators
always *do* alter their first operand. That is, the left operand
is required to be intent(out) or intent(in out). So Maine's
objection doesn't apply here. Of course, you would have to extend
what operator symbols you allow to include more than just
ASSIGNMENT(=).)
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-03-23, 7:04 pm |
| Paul Van Delst <Paul.vanDelst@noaa.gov> wrote:
> I never understood the attraction of assignment operators.
> From my C text I'm told that:
> j *= k + 3
> is equivalent to
> j = j * (k + 3)
> not
> j = j * k + 3
Consider
#define times(x,y) x=x*y
times(j,k+3);
As someone else mentioned, they are most convenient
when the left side gets complicated, especially an array
element with many subscripts. In C, I believe it guarantees
that the subscript expressions are only evaluated once, though
optimizers should be able to do that anyway.
-- glen
| |
| Ben Hetland 2006-03-23, 7:04 pm |
| Richard E Maine wrote:
> Bernhard Enders <bgeneto@gmail.com> wrote:
>
>
> The question seems to presume that it is possible. That presumption is
> false. It is not possible.
And it's akin to the fact that it's not possible to define your own
operators like .increment. and .decrement. in either C or C++.
The language philosophies are simply different. C can allow this kind of
operators because assigment is simply defined as a kind of an expression
(special statements for doing this don't exist), while in Fortran
assigment statements are a fundamentally different thing than an expression.
A subroutine could achieve the same concept in a similar way in both
languages though:
CALL div_assign(a, 5) ! a /= 5
div_assign(a, 5); /* a = a / 5 */
--
-+-Ben-+-
| |
| Ben Hetland 2006-03-23, 7:04 pm |
| Dan Nagle wrote:
> A long (100+ posts IIRC) in comp.lang.ada wasn't ended
> until someone posted the emacs lisp to add += et al.
> to ada-mode.
Hmmm.. so how about adding a lambda operator to Fortran then? Does that
start a long thread here?
Or should I rephrase the question as (Fortran lambda op addp) ?
;-)
--
-+-Ben-+-
| |
| Ben Hetland 2006-03-23, 7:04 pm |
| Dick Hendrickson wrote:
> I can't think of a way to do infix ++ operators, but this
> at least lets anyone do the storage related things.
Infix? What would that do?
In C and C++ they are either prefix or postfix, and I guess both could
be implemented as functions in Fortran, except they couldn't be used as
statements alone.
--
-+-Ben-+-
| |
| James Giles 2006-03-23, 10:03 pm |
| Ben Hetland wrote:
> Dick Hendrickson wrote:
>
> Infix? What would that do?
> In C and C++ they are either prefix or postfix, and I guess both could
> be implemented as functions in Fortran, except they couldn't be used
> as statements alone.
I think he was talking about the syntactic issue:
I = J +++ K
Is this
I = J + (++K)
or is it
I = (J++) + K
or what?
Remember that Fortran has a source form in which spaces
are not significant.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ben Hetland 2006-03-23, 10:03 pm |
| Paul Van Delst wrote:
> Goodness ... there's no ambiguity there.[*]
No, there isn't, really! ;-)
But you probably read the assignment wrongly; remember it's not a
mathematical = (i.e., an equality).
The = in "j = j+5" should be read as "replace j by the result of the
following expression" (the expression being the "j+5" in this case).
The *= in "j *= j+5" follows the same logic: "multiply j by the result
of the following expression".
Your C text just states what it's equivalent to, NOT what it means or
actually does. For instance, I could claim that the following two
expressions also are equivalent:
j *= j + 3
j = j * (j + 5 - 2)
Just as a reminder, one must not confuse the mathematical expression
y = x + 4
with the programmatic expression that looks identical. Those simply
express different concepts!
In C, perhaps the equivalent to the _mathematical_ expression above can
be most closely expressed as
#define y (x + 4)
--
-+-Ben-+-
| |
| James Giles 2006-03-23, 10:03 pm |
| Ben Hetland wrote:
....
> The *= in "j *= j+5" follows the same logic: "multiply j by the result
> of the following expression".
In C, Isn't the statement j *= j+5 is illegal (non-conforming)? An
expression that modifies a value can't elsewhere reference that value.
Or, is there a "sequence point" I'm missing? (Guess I'll have
to drag out the C standard if I have to discuss nuances of these
things.)
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ben Hetland 2006-03-23, 10:03 pm |
| James Giles wrote:
> In C, Isn't the statement j *= j+5 is illegal (non-conforming)?
I'd think not. Actually at first I felt certain about this, but after
fine-reading your question I feel the urge to double-check the standard
too... ;-)
> An expression that modifies a value can't elsewhere reference that value.
No, that cannot be what the standard says... That would in fact render
expressions like "y = y + 1" non-conforming too, and we all know that
wouldn't be reasonable in programming (it would in math...).
> Or, is there a "sequence point" I'm missing?
I recon you must be thinking of expressions like "j = m[i++] * i" or
"++i+i", where operators such as ++(preincrement) or ++(postincrement)
modify their arguments at their previous or next sequence point
respectively. <nitpic>Actually, the expressions are not non-conforming,
just undefined... no compiler will disallow it!</nitpic>
This discussion is probably becoming a bit off-topic in this group
though, except perhaps to serve as reference experience with these
features for those designing similar stuff to suggest as extensions in a
future Fortran standard. So maybe you know what to avoid, and where to
improve... :-)
Combining assigments and expressions as in C can often be handy, but it
also has its problematic areas that have been the root of many bugs.
Combined with the somewhat unfortunate typographical similarity between
= and ==, it can for instance be hard to know for sure which one was
intended when you see something like
while (b = getdata(c)) ...
(Critics of the language of course love to point at issues like that,
but then one can usually point at an equally bad issue in their
favourite language instead...)
--
-+-Ben-+-
| |
| James Giles 2006-03-23, 10:03 pm |
| Ben Hetland wrote:
> James Giles wrote:
>
> I'd think not. Actually at first I felt certain about this, but after
> fine-reading your question I feel the urge to double-check the
> standard too... ;-)
The reason I ask is that these kinds of expressions are often very
misleading and are error traps. I have an old book where the
author, his proofreaders, and the techniacal editor all missed
the following:
color += (color+1)%16;
It's pretty clear that what he meant was:
color = (color+1)%16;
The former has some strange properties, but it doesn't cycle
through the colors.
0, 1, 3, 7, 15, 15, ...
1, 3, 7, 15, 15, ...
2, 5, 11, 7, 15, 15, ...
3, 7, 15, 15, ...
4, 9, 3, 7, 15, 15, ...
5, 11, 7, 15, 15, ...
6, 13, 11, 7, 15, 15, ...
7, 15, 15, ...
8, 1, 3, 7, 15, 15, ...
9, 3, 7 15, 15, ...
10, 5, 11, 7, 15, 15, ...
11, 7, 15, 15, ...
12, 9, 3, 7, 15, 15, ...
13, 11, 7, 15, 15, ...
14, 13, 11, 7, 15, 15, ...
15, 15, ...
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ben Hetland 2006-03-24, 8:01 am |
| James Giles wrote:
> Ben Hetland wrote:
> ...
>
> In C, Isn't the statement j *= j+5 is illegal (non-conforming)? An
> expression that modifies a value can't elsewhere reference that value.
> Or, is there a "sequence point" I'm missing?
Not precisely C, but I had the C++98 standard (2003 revision) readily
available, so I checked what it said about this. The wording (chapter 5)
says:
"Between the previous and next sequence point a scalar object shall have
its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be accessed only to
determine the value to be stored."
Sequence points roughly found at function calls, between each statement
(or "full expression"), and related to the , (comma) sequence operator.
So, yes, that would allow the variable to be referenced multiple times
in the same expression. At least as I read it...
BTW, what's the equivalent wording (if any) in the Fortran standard?
--
-+-Ben-+-
| |
| James Giles 2006-03-24, 8:01 am |
| Ben Hetland wrote:
....
> BTW, what's the equivalent wording (if any) in the Fortran standard?
The evaluation of a function reference shall neither affect nor be
affected by the evaluation of any other entity within the statement.
If a function reference causes definition or undefinition of an actual
argument of the function, that argument or any associated entities
shall not appear elsewhere in the same statement.
There's an exception, but the verbage is a complicated way of
saying that the conditonal part of an IF, WHERE, or FORALL
statement is considered separate for the purposes of this rule.
Since Fortran doesn't have expression-level assignments, a
function with side-effects is the closest analogy.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ben Hetland 2006-03-24, 8:01 am |
| James Giles wrote:
> The reason I ask is that these kinds of expressions are often very
> misleading and are error traps. I have an old book where the
> author, his proofreaders, and the techniacal editor all missed
> the following:
>
> color += (color+1)%16;
>
> It's pretty clear that what he meant was:
>
> color = (color+1)%16;
Another easy bug to appear with that operator style is to forget the =
part of it:
color + (color+1)%16;
This is legal. In fact it's not uncommon in C that it is the side effect
of an expression that is of primary interest, and not the result, like
for instance when using the printf function.
I guess a good compiler is able to detect in many cases the fact that
the expression does not have a side effect, and nor is its result
used/stored, so it can issue a warning for it.
To compare with Fortran, this problem is avoided by both distinguishing
between assignment statements and expressions, and by always requiring
that the result of a function is used.
--
-+-Ben-+-
| |
| glen herrmannsfeldt 2006-03-24, 8:01 am |
| James Giles wrote:
> Ben Hetland wrote:
[color=darkred]
> In C, Isn't the statement j *= j+5 is illegal (non-conforming)? An
> expression that modifies a value can't elsewhere reference that value.
> Or, is there a "sequence point" I'm missing? (Guess I'll have
> to drag out the C standard if I have to discuss nuances of these
> things.)
In this case j is only modified once, and obviously after it is used.
(Maybe not completely obvious, because it wouldn't work in PL/360.)
The problem comes when a variable is modified when the order of
reference and modification is undetermined, something like:
i=j++ + j++;
The two references to j can come in either order, and the modified
j values can be stored back in any order. As with Fortran rules where
anything can happen including starting WW3 that is true here, but more
likely is that an unexpected value is given to i, j, or both.
While there isn't much use for expressions like above,
i=x[j++]+x[j++];
is also non-standard.
-- glen
| |
| Joe Krahn 2006-03-24, 7:07 pm |
| glen herrmannsfeldt wrote:
> James Giles wrote:
>
>
>
>
>
I think that the need to discuss rules of assignment operators makes it
clear that they do follow simple rules, but the rules are different from
something you would see in a mathematical text. Since Fortran is aimed
at mathematical sciences, I think we can be confident that Fortran will
never include this. I personally think it is not a bad idea, but that it
is just not Fortran-like.
In fact, it seems clear that the associate statement was invented mainly
to allow clearly written mathematical-style expressions in the presence
of long variable name constructs. A mathematically oriented mind will
prefer this clear but more verbose form. Most computer scientists will
prefer the more condensed style of assignment operators.
The only possibility (I think) of a similar feature for Fortran is to
define multiply(), divide() add() subtract() functions with two
arguments. So, "J *= J + 5" becomes "multiply(J,J+5)". The problem is
that these would be most useful to have both a function form and a
statement form. Even with a subroutine form, we run into the annoying
standard that you cannot share the same generic name across subroutines
an functions. IT WOULD BE NICE TO DROP THAT RESTRICTION.
Another idea this brings to mind is that sometimes it would be nice to
ignore function return values instead of having to declare a junk
variable. Maybe there could be an EVAL keyword that works like CALL to a
function with the result ignored.
Joe
| |
| Richard E Maine 2006-03-24, 7:07 pm |
| Joe Krahn <jkrahn-at-nc.rr.com_@_> wrote:
> Another idea this brings to mind is that sometimes it would be nice to
> ignore function return values instead of having to declare a junk
> variable. Maybe there could be an EVAL keyword that works like CALL to a
> function with the result ignored.
You are unlikely to see anything like that in Fortran because it is not
in the spirit of Fortran functions. The fine details of the exact
requirements of the standard are a subject of infinite debate here. I'm
not going to get into that. But there is a general theme that the
purpose of a function is to compute its result value. Thus, if you don't
use there result value, there isn't much purpose left.
I repeat, I am *NOT* going to re-re-re-re-re-debate whether or not the
standard allows a compiler to "optimize"
junk_variable = f(x)
to a no-op if junk_variable is subsequently unreferenced.
I just note that, independent of the question of interpretation of the
current standard, you aren't likely to get even a substantial minority
of the committee to agree to adding a new feature that explicitly
encourages this style.
This is part of thee fundamental C vs Fortran philosophy difference on
functions. In C, functions are the only kind of procedures that exist.
Function side effects are pervasive. There isn't even a direct
equivalent to Fortran's subroutine. Instead you just use a function
where the side effects are the only thing you actually care about. In
Fortran, function side efffects are.... problematic and the subject of
endless debate. The debate has been going on for at least 30 years and
shows no particular sign of nearing an ennd.
Adding a feature like this would just throw extra fuel into that
particular fire. I think you'll find most people getting as far away
from it as they can.
Go ahead and make your junk variable. It will almost certainly work in
practice, and some people claim it is even standard-conforming (others
don't, but that's getting into the debate). But don't expect such a
feature in the language. Anyway, that's my prediction (which, of course,
could be wrong, but it's still what I predict).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
|
|
|
|
|