reinhard@samsung.com (Steven Reinhardt) (03/28/91)
In article <4693@osc.COM> jgk@osc.COM (Joe Keane) writes: >One thing i like about C is that when you type something you know what it's >going to do. There are some catches, like operator precedence isn't what it >should be in some cases. But in general when you say `a = b', you're pretty >sure what the compiler's going to do with this. > >I wish i could say the same thing about C++, but i'm afraid this is one of the >big differences between the two languages. There are a number of causes, >including inline functions, virtual inheritance, invisible copy constructors, >and i'm sure there are more. The end result is that when you say `a = b', you >have no idea what the compiler is actually going to put there. > >So you type a one-line C++ function, but when you look at the assembly version >it's 100 lines. (Long ago i gave up reading the cfront output. Compiling it >to assembler improves the readability.) This is a little distressing at >first, but finally you just have to accept that C++ is far from a WYSIWYG >language. >-- >Joe Keane, C++ hacker A hearty "amen" to that. Having just completed a serious project in C++, and having been fortunate enough to learn object-oriented programming before learning C++, I found the language frustrating for exactly this reason. In C, if you can conceive it, you can do it, with few exceptions. It can get ugly, but C is so close to machine language that when you type something, you know exactly what it's going to do. The first time I looked at the output of "g++ -S" I was amazed at how much was going on behind my back. If C++ had the power of, e.g., Smalltalk, that would be expected; you wouldn't even try to figure out what was going on at the machine level unless you were debugging the system. But it doesn't, and that's my complaint: either give me enough power in the language that I don't care exactly what instructions the CPU is executing, or give me C where I can get a pretty accurate idea from looking at the source. (And I mean looking at, say, three adjacent lines of source, not browsing header files to see what inherits form what and which functions are inline and/or virtual.) Steve
sabbagh@acf5.NYU.EDU (sabbagh) (03/28/91)
reinhard@samsung.com (Steven Reinhardt) writes: >In article <4693@osc.COM> jgk@osc.COM (Joe Keane) writes: >>One thing i like about C is that when you type something you know what it's >>going to do. There are some catches, like operator precedence isn't what it >>should be in some cases. But in general when you say `a = b', you're pretty >>sure what the compiler's going to do with this. >> >>I wish i could say the same thing about C++, but i'm afraid this is one of the >>big differences between the two languages. There are a number of causes, >>including inline functions, virtual inheritance, invisible copy constructors, >>and i'm sure there are more. The end result is that when you say `a = b', you >>have no idea what the compiler is actually going to put there. >> >A hearty "amen" to that. Having just completed a serious project >in C++, and having been fortunate enough to learn object-oriented >programming before learning C++, I found the language frustrating >for exactly this reason. In C, if you can conceive it, you can >do it, with few exceptions. It can get ugly, but C is so close to >machine language that when you type something, you know exactly >what it's going to do. Really? Aren't we confusing complexity with experience? I bet both Mr. Reihardt and Mr. Keane have several _years_ experience with C; I have about 10 and I'm below average in this respect. That amount of experience means that I can "think" in C. I know the computer model by heart. OTOH, I bet that most people have less than 5 years experience with C++. Learning a computer language is similar to learning a human language. There comes a time when you stop thinking about all the underlying semantics becuase you understand it well. This will happen with C++ as well. In a way, it was a mistake to make C++ look so much like C because 1) it is nothing like C and 2) this will steepen the learning curve. Also, I like to imagine the mind-set of the creators of any language. I envision Dr. Stroustrup sitting in his office saying: "gee whiz, to really create nice, maintainable code in C, I write lots and lots of lines that look like THIS ..." -- and that's how C++ is born. Sure, a lot is going on, but YOU WOULD HAVE TO WRITE ALL THAT STUFF IN C ANYWAY TO ACHIEVE THE SAME EFFECT. Well, maybe not all but that's the price of using compiled languages in general. Let me elaborate. A line-by-line comparison between C and C++ is moot; C++ is at a higher stage of evolution than C, just as C is at a higher stage than assembler. It is best to make program by program comparisons, i.e., "I have to write a program to do so-and-so" then comparing line counts in C and C++. Other things should be compared as well: implementation time (from analysis to executing code), ease of explanation to other programmers, maintainability, and so on. Learning object-oriented programming principles in any language does not really help learn the nitty-gritty details of another language. Each has its quirks, idioms, and model of the underlying computer. This part of learning a language is extremely frustrating, as there is only one way to learn it, namely, by writing lots of code. Finally, I advocate knowing several languages and picking the best one for the task. I have greatest experience with C, FORTRAN, Forth and C++ (in that order). For my thesis, I am using the last three, each for different parts. Yes, Virginia, there is a time when one prefers FORTRAN to C++. Hadil G. Sabbagh E-mail: sabbagh@cs.nyu.edu Voice: (212) 998-3125 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 "Injustice anywhere is a threat to justice everywhere." - Martin Luther King, Jr. Disclaimer: This is not a disclaimer.
jls@rutabaga.Rational.COM (Jim Showalter) (03/29/91)
>, but C is so close to >machine language that when you type something, you know exactly >what it's going to do. And the BEST part is: I varies from machine to machine! -- ***** DISCLAIMER: The opinions expressed herein are my own, except in the realm of software engineering, in which case I've borrowed them from incredibly smart people.