Concerning subobjects of absent optional arguments used for actual
arguments corresponding to optional dummy arguments, Richard Shapiro
wrote:
> 1) At each call site reference, check if the actual argument is PRESENT,
> and pass NULL if it's not. This means that each call now needs to execute a
> conditional operation, increasing caller overhead, slowing down the code.
The picture isn't nearly so grim. The compiler only needs to do something
different/additional when a subobject of an optional dummy argument is used
as an actual argument. This has no different/additional effect on the case
when an optional dummy argument (all of it, not a subobject of it) is used
for an actual argument.
As has been pointed out, this is exactly what the programmer would be
required to do, but in an "exponentially tedious and error prone" way,
since the programmer doesn't have access to direct manipulation of the
representation of the actual arguments, and so can't construct an
absent actual argument except by leaving it out textually. One has
therefore a combinatorial explosion -- with k optional arguments, one
needs to test for and write 2**k calls.
Every path through this mess is of length k. A compiler-implemented
solution would also have run-time cost O(k), but most likely with a
smaller coefficient than would a source-level solution.
The benefits of the compiler doing it are
(1) The compiler can do it with O(k) _code_size_, which the Fortran
programmer can't.
(2) The compuler can do it with O(k) run time cost, which the Fortran
programmer can do too, but the compiler would most likely produce
faster code.
(3) The programmer doesn't need to write anything special, which is
one less opportunity to get it wrong.
Many studies have shown that lifetime costs of programs are roughly
proportional to their source code bulk. Language structures that reduce
source code bulk, without compromising other virtues, reduce lifetime costs.
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|