🚀 go-pugleaf

In article <MCGRATH.90Aug7190831@homer.Berkeley.EDU> mcgrath@homer.Berkeley.EDU (Roland McGrath) writes:
>
>   This hijacking could be hidden deep inside a large, complex system and
>   be very difficult to find, especially if classes A and B had been thoroughly
>   debugged and were hence presumed innocent.
>
>This a good argument for programmers not doing this sort of thing, since it may
>make their lives more difficult down the road.  Why, however, should they be
>prohibited from doing it?  Sure sounds like a victimless crime to me....
>--
>	Roland McGrath

I disagree about this feature being victimless.  Optimizing compilers can
rely on visibility in making optimizing choices.  Hijacking and other hacks
break these optimizations.  Compiler writers are again forced to make a choice:
Do we write compilers that do a good job of optimizing the code of people who
write within the language, or do we pessimize our optimizers, because we have
to assume some people are going to write hack code?  So I claim people who
write hack code victimize people who write within the language, because 
compilers have to be pessimistic about the kinds of programming hacks people
are going to make when programming in C++.  My claim is that much better
optimizing compilers can be developed if people are willing to program within
the language, rather than playing C-like coding hacks.