From 1997537489421000659 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,93fcf12b6d1f9f33 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-11-28 16:01:16 PST Newsgroups: comp.std.c++ Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!rfg From: rfg@netcom.com (Ronald F. Guilmette) Subject: Re: Finding the right operator new()/delete() Message-ID: Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: Date: Sun, 28 Nov 1993 23:46:03 GMT Lines: 111 In article jamshid@ses.com (Jamshid Afshar) writes: >In article , >Ronald F. Guilmette wrote: >>Note that the ARM say EXPLICITLY at the end of 12.5 that "A destructor >>finds the operator delete()...". That statement is in a NON-COMMENTARY >>part of the ARM, so it constitutes an actual "semantic requirement" >>(using your terminology) and not merely a statement of one possible >>implementation technique. (And I note that the 9/28/93 X3J16 working >>paper contains essentially similar wording.) > >What does "find" mean? That certainly is *the* question. >Given that you usually demand very explicit, >precise language and refuse to allow "common sense" interpretation of >the ARM, I am surprised that you are interpreting "find" as "calls, >adhering to usual access rules". As I tried to point out earlier, it isn't hardly just me whose is making this interpretation. It is really various *implementors* (including the implementors of cfront) who have decided to use this interpretation. As a matter of fact, I have been arguing rather vigorously that this interpretation SHOULD NOT BE USED, and that new wording should replace the old wording which would have the net effect of preventing any and all implementors from EVER mistakenly trying to use this rather awful interpretation again. >Anyway, a language definition can only demand user-observable >behavior. I agree. That's why I provided an example of a piece of code which, when compiled, elicits very different kinds of "user-observable behavior" from different existing implementations. >> #include >> struct B1 { void *operator new (size_t); }; >> struct B2 { void *operator new (size_t); }; >> struct D : public B1, public B2 { D(); }; >> D::D () { } >>More than a few existing C++ compilers actually *fail* to compile this >>example, claiming that `operator new' is ambiguous. >>But why? > >How should I know? Ask the compiler writers where the ARM allows this >behavior. I have. They cite the passage at the end of 12.5 which I mentioned earlier. >I'm really not sure why ANY compiler would choose to implement the >call to `operator new()' inside of the constructor (which then takes a >hidden flag) instead of calling `operator new()' inline at the `new' >expression. Me neither, but some do. >Is this a leftover from "assignment to this", or is there >something funky about virtual bases? Does it somehow reduce overall >code size? As I mentioned previously (in this thread) the reduction in code size was perhaps the original rationale for implementing things this way, but such savings are, at best, very minor, and this implementation approach may in fact *increase* object code size for certain programs. >>Now you may claim that all of these implementors have merely botched the >>job, and (as I do) you may claim that there is no excuse for compilers >>to reject the above code, but given the nearly universal extent to which >>this particular implementation botch has been mimicked (by implementors) > >"Nearly universal"? Certainly not on the PC. Borland and Watcom >compile your code... Sorry. I stand corrected. I'm glad to see that some implementors (at least) have done this "right". >Especially if MS allows your code, I'd be extremely surprised if USL >and GNU could bully the rest of the implementors into breaking their >compilers. It isn't a question of "breaking" anyone's compiler. Judging from the end-product of the X3J11 ANSI C standardization efforts, it appears that what often happens in these standardization committees is that when different existing implementations do different things, EVEN WHEN WHAT SOME OF THEM ARE DOING IS OBVIOUSLY SILLY, the standardization committee, rather than making any attempt to get wayward implementors to clean up their acts, will instead pursue the path of least resistance and form a bland consensus around leaving the case in question in the nebulous realm of "undefined behavior". Of course whenever this happens, portability of code (between "conforming" implementations) becomes a harder thing to achieve, and end-users are therefore ill-served. (As a trivial example of what I'm talking about, readers may wish to take note of the fact that according to the letter of the ANSI/ISO C standard no diagnostic is strictly required for a declaration like `void a[10];'. As far as I'm concerned, that tends to illustrate the triumph of compromize over common sense.) >Btw, what percentage of voting committee members are compiler writers? A very high percentage. More importantly however, as a group, they tend to be more vocal (and to have more clout) than the folks who represent end-user constituencies. -- -- Ronald F. Guilmette, Sunnyvale, California ------------------------------- ------ domain address: rfg@netcom.com --------------------------------------- ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------