mcvoy@uwvax.UUCP (02/17/87)
[food for thought & line eaters]
Hi-
I was wondering if anyone (or any company) has any desire to
implement C++ as a true language, not just (sorry) as a preprocessor.
I really can't stand not being able to use the debugger. And it's
slower to have go through the extra pass(es?). Other than that, C++
is great, but until those are resolved, uh-uh.
Also, a question for the compiler writers out there: is the
specification in the C++ book anywhere close to being good enough to
use for writing a new compiler? I know it says it is not exact, but
I don't know what is/is not specified...
On the same note, is there a complete spec out there anywhere?
Thanks in advance,
--
Larry McVoy mcvoy@rsch.wisc.edu,
{seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy
"They're coming soon! Quad-stated guru-gates!"mikem@otc.UUCP (02/18/87)
> I was wondering if anyone (or any company) has any desire to implement > C++ as a true language, not just (sorry) as a preprocessor. Yes. But the current phase is far too important to truncate. Having it as a preprocessor makes it incredibly portable, which means that lots of experience can be gained (and perhaps the unsatisfactory features can be tidied up) before going to the effort of doing compilers for lots of machines. In any case, I doubt that the level of acceptance of C++ is yet large enough to justify properly supported compilers and all the commercial headaches that involves. My feeling is that cfront ought to be rewritten taking advantages of all the C++ features that weren't there when it was begun. There seem to be bugs coming out in strange places now, plus there are (in my opinion) still too many "sorry, not implemented" features. (But on the other hand, I've been using C++ in anger for well over 12 months now, so I can't complain too strongly since it's obviously been serving my purpose well. I've had a Pyramid almost to myself, though, so the compilation speed wasn't a problem. It's getting worse as more people come on, though.) > I really can't stand not being able to use the debugger. I use the debugger when I have to. It's quite possible. You need to add a "cb" into the pipeline within CC where the +i option is handled. However, what I've found is that proper C++ code (as opposed to C-style C++) yields less convoluted run-time errors. Normally just a 't' command to sdb (for code not even compiled with -g) is enough to pin-point the problem. It occurs to me as I'm writing this, that I've hardly ever felt the need with C++ to single-step through things to see what's happening. The structure that one can impose if one designs things properly obviates this. > And it's slower to have go through the extra pass(es?). My belief is that this is false economy. In C you really need to run lint to check that all is as it should be. And people don't always do it because it's seen as a pain in the bum and it's not enforced. C++ catches so many errors at compile-time that the overall development/maintenance time is reduced. (Not to mention the longer-term advantages of code-reusability, etc.) In any case, machines are getting faster, aren't they, so the slowness induced by the extra cc passes will become less and less important. (But of course, ultimately a C++ compiler would be nice, and I'd love to get one. It would have to be done more ruggedly, though, because then you couldn't look at the ..c files to figure out what was going wrong.) > Other than that, C++ is great, but until those are resolved, uh-uh. No. C++ is fine NOW for all important work. If a job or set of tasks is important then paying for a decent machine to do development on is justified. And if one's superiors won't come at that, then the task obviously isn't important, or one hasn't educated one's superiors on the economic advantages of using decent tools and languages. (I will admit, though, that the longer-term importance of exposing uni students to decent equipment, and tools, is often overlooked in favour of more immediate budgetary constraints.) For commercial organisations, though, there's no excuse. It's simply not very bright to continue to avoid C++. Sure, using it on an ibm pc would be apparently slow. But the fact of the matter is that speed of individual compilations is a lesser factor in overall software life cycles. (Over a period of time, using C++ and writing appropriate extensible class hierarchies will lessen the amount of compilation required, anyway, since the re-used code will be more reliable.) (And if one's task isn't important then why is it being done?) Mike Mowbray Systems Development Overseas Telecommunications Commission (Australia) UUCP: {seismo,mcvax}!otc.oz!mikem ACSnet: mikem@otc.oz