Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: Separate Decl of Private Member Fcn Message-ID: <56428@microsoft.UUCP> Date: 9 Aug 90 16:57:40 GMT References: <259400001@inmet> <32527@sparkyfs.istc.sri.com> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 23 In article 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.