Content deleted Content added
another section |
don't be doing OpenSSL brain damage |
||
Line 15:
In many programming languages a function, and hence an expression containing a function, may have [[Side effect (computer science)|side effects]]. An expression with side effects does not normally have the property of [[referential transparency (computer science)|referential transparency]]. In many languages (e.g. C++), expressions may be ended with a semicolon (<code>;</code>) to turn the expression into an expression [[Statement (programming)|statement]]. This asks the implementation to evaluate the expression for its side-effects only and to disregard the result of the expression (e.g. "x+1;") unless it is a part of an expression statement that induces side-effects (e.g. "y=x+1;" or "func1(func2());").
===Caveats===
Note that the formal notion of a side effect is a change to the abstract state of the running program. Another class of side effects are changes to the concrete state of the computational system, such as loading data into cache memories. Languages which are often described as "side effect–free" will generally still have concrete side effects which can be exploited, for example, in [[side-channel attack]]s.
Furthermore, the elapsed time evaluating an expression (even one with no other apparent side effects), is sometimes essential to the correct operation of a system, as behaviour in time is easily visible from outside the system by other parts of the system with which it interacts, and might even be regarded as the ''primary'' effect such as when performing [[Benchmark (computing)|benchmark testing]].
It depends on the particular programming language specification whether an expression with no apparent side effects can [[Program optimization|legally be eliminated]] from the execution path by the processing environment in which the expression is evaluated.
==See also==
| |||