|
|
|
|
|
|
by renox
390 days ago
|
|
|
> the innovation is that formal parameters may have 3 kinds of behaviors, "in", "out" and "in out", and that the parameter behavior must be specified, but not its implementation mechanism, like in older programming languages Great on paper, not so good in real life: so what is the specification when a parameter is aliased?
That is to say passed two times to a procedure: once as an "in" parameter, the other as an "in out" parameter.
I've been able to use compiler explorer to show the behaviour may change depending on the size of the parameter with GNAT, ( https://news.ycombinator.com/item?id=43001394 ). |
|
|
In C/C++, where such parameters are passed only by reference, the chances of wrong behavior in the presence of aliasing are greater than in a language like Ada, where they may be passed by value and in lucky cases that may happen to produce the right result.
In general, the documentation of any function should specify whether the aliasing of such parameters is allowed. By default any good compiler, for any language, should give at least a warning whenever parameters that can be modified by a function are aliased, because without analyzing how they are used inside the invoked function it is unknown whether the function will produce the expected results.
The distinction between "out" and "in out" parameters that exists in Ada can only make easier the detection of suspect function invocations. It can never be worse than in C, C++ and similar languages.
On the other hand, the distinction between "out" and "in out" would have greatly simplified C++, because for an "out" parameter the compiler can use raw memory, instead of memory for which a constructor must have been invoked, like for an "in out" parameter. There would have been no constructors as a special category that must be handled differently, any function with an "out" parameter of a certain type could have been used to initialize a value of that type.
The distinction between "out" and "in out" and not specifying whether the parameters are passed by value or by reference are great in real life, because they enable the compiler to make optimizations that are otherwise impossible, as proven by the fact that nobody has succeeded to make such a compiler for the pre-2011 C++. C++ from 2011 and later has solved some of the performance issues, but only by introducing tedious and error-prone annotations for ensuring the desired behavior, i.e. the "move" semantics.
Moreover, not having to specify how the parameters are passed eliminates a huge amount of "&" and of "*" or of their equivalents from a program, also eliminating the risk of errors caused by their misuse. In my opinion, this is a great advantage in real life.