There are very good reasons to let things undefined.
If you specify things, it's hard to change the behaviour.
Undefined behaviour can change (and history has shown that
it does).
Perl doesn't have one source code, I've 192 versions of Perl
installed on my computer - all with a different source code.
Abigail | [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] |
C specifically states this as undeifned. I think if perl did the same, your point would be valid.
From man perlop
"++" and "--" work as in C.
Convinced?
Abigail | [reply] |