Date: Sun, 12 Aug 2001 15:24:44 -0700 From: John Merryweather Cooper <jmcoopr@webmail.bmi.net> To: obrien@FreeBSD.ORG Cc: tlambert2@mindspring.com, "hackers @ FreeBSD . ORG" <hackers@FreeBSD.ORG> Subject: Re: the =+ operator Message-ID: <20010812152443.C39719@johncoop> In-Reply-To: <20010812150226.A5074@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sun, Aug 12, 2001 at 15:02:27 -0700 References: <3B73F0BC.548D40B3@home.com> <3B757D14.B344931@mindspring.com> <20010811121857.A41578@johncoop> <20010812150226.A5074@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001.08.12 15:02 David O'Brien wrote: > On Sat, Aug 11, 2001 at 12:18:57PM -0700, John Merryweather Cooper wrote: > > > > Since when does any self-respecting compiler dictate object format? > It's > > brain-damage for a compiler to screw with the object format--so much > for > > If you have ever programmed in Ada, you would understand. Since I assume > you have not due to your comment, you should learn something more about > languages and implementation than just "C" -- it makes one very myopic. > I have programmed alot in Ada--and I understand about meta-deta and it's uses. But that's not what I took the original claim to be--I took it to be advocacy for private object formats for every compiler. Clearly I stepped on a "troll-mine" . . . > Also, to put the in formation in the object format does not require > changing it. Do you think all debugging metadata is standardized? One > can put optional data in object files. > No, I'm well aware that meta-data is not standardized by any means. Obviously, the original comment that started this whole discussion was a little vague, and I got trapped. > > > Prototypes are an overwhelmingly "Good Thing(tm)" > > as behind-your-back implicit parameter conversion is death to serious > > numerical work. At least now, some control can be exercised over > parameter > > conversions . . . > > Who ever said anything about not being able to do that in Terry's view? > You are taking one statement and running wildly with it. > In my view, he was advocating chucking ANSI-89 and returning to the wild days of K&R. I think that would be very bad. Clearly, you disagree with my understanding. > > > Two-pass lexing is also brain-damage. How to easily double compile > time is > > a single step. If applied to C++, we'd wait night and day for the > compile > > of just one port. > > *sigh* Do you really, really think most of the time you spend in > compiling a C++ file is in the lexing step?? > In benchmarking IBM's VisualAge C++ (Version 4.0), this seems to be the case, at least for me. I chose this compiler because it is easy, with the tools available for me to monitor the stages of compilation since each stage has a separate DLL. Using SciTech's MGL 5.0 Beta 2 Library, it is clear that Lexing/pre-processing take up the lion's share of the time. Obviously, your mileage differs. I would like to have your understanding of what's happening--and not this "troll-mine." > BTW, what do you think happens in C with the preprocessor? You are > lexing things twice -- once by the preprocessor and once by the compiler > proper. Quite often they share common lexer code. > Not always. Provided you out-law macros with side-effects, it is perfectly possible to preprocess and lex simultaneously. > > > Also, languages that are deliberately ambiguous are > > maintenance nightmeres--maintenance perfers a language that is 100% > > deterministic. > > You think C++ isn't ambiguous, and that new features haven't been added > to it knowing that it blows ambiguity out of the water? > I know it's ambiguous. In fact, I think it's the most poorly standardized/described language to date. However, since C++ is quite popular, apparently my opinion doesn't carry much weight. :) > > > Seriously, my > > understanding from K & R is that the C designers just thought it would > be a > > "nice feature" to allow both versions of the operators. "Nice feature" > is > > usually a synonymn for brain-damage in a compiler. :) > > *sigh*... little knowledge, great stretching leaps... > From the reading I've done, I believe this conclusion is justified. Doubtless there are other opinions though . . . > > > And that is as it should be . . . Lexing to be fast needs to be > > single-pass. The same could be said for parsing. The agony over > designing > > a truly "standard" C++ compiler (not a single example of which exists) > > should lay this out clearly . . . > > WTF are you talking about? I don't see the required connection between > the two. Please tell me the compilers have detailed knowledge of their > innerworkings. Now you swear at me. Hardly constructive. Like I said, a "troll-mine." I'll step more carefully in the future. I'm nothing compared to you, but your resort to ad hom's instead of illumination indicates that further discussion would be irritating and pointless. jmc > > -- > -- David (obrien@FreeBSD.org) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010812152443.C39719>