There is no good reason why that is undefined, if perl has one source code and C has no eval type function.
--
Steve Marvell | [reply] |
| [reply] |
Wow! how do you keep straight which one is which?
And do any of them handle $i = $i++; in any way other than the way I described?
| [reply]
[d/l] |
192, Wow!
There is a good reason for leaving things undefined if there is some benefit in implementing the process in different ways. It seems to me that that was what happened in C.
The thing about C, and C++ today, is that the compilers branched off implementing the same standard (including its undefined components) individually.
Perl, onm the other hand is a unidirectional implementation, as far as I can tell. I don't think there are people out there defining their own aspects of perl and releaseing their own version, are there?
Perl is implemented in C, not by C, so perl does not suffer from the same "undefined" qualities that C does, unless there is a specific branched version of perl.
It may be the case that some past versions of perl exhibit different behaviour, in context, but is that bug or feature?
C specifically states this as undeifned. I think if perl did the same, your point would be valid. Otherwise, if the behaviour is differnt, then that means people are doing their own thing.
--
Steve Marvell
| [reply] |