Just out of curiosity, did somebody actually "cvs annotate" (or whatever the equivalent in whatever version control they use) is to see if Torvalds actually checked in the lines in question?

Quote:Original post by WanMaster
Posted for historical awareness: the origin of the goto discussion.

Quote:
In parting, I can't resist giving one last example of goto statements. I came across this code in an LR parser library I used as part of a larger compiler project (circa 1988). It is a marvelous little gem of programming succintness and simplicity.

Last Example - Nontrivial Gotos

int parse(){    Token   tok;reading:    tok = gettoken();    if (tok == END)        return ACCEPT;shifting:    if (shift(tok))        goto reading;reducing:    if (reduce(tok))        goto shifting;    return ERROR;}

I leave it as an exercise for the reader to rewrite this without using goto statements.

...

int parse() {  while ((Token tok = gettoken()) != END) {    while (!shift(tok)) {      if (!reduce(tok)) { return ERROR; }    }  }  return ACCEPT;}

... :/

A few notes:
1. I should have said from the beginning I think Linus is jerk and his responses on the subject are a sad joke.

2. About being a "competent" programmer:
You can argue that a programmer who is competent with using #define macros or goto statements will not cause buggy software. But these features are often misused and abused, and often result in unreadable code and hidden bugs. Bottom line is when considering the trade off involved, you are generally better off using alternatives to goto's and macros.

In a similar fashion, you can argue that someone who is competent using exceptions, multiple inheritance, multi-threading etc etc will not cause bugs. But the truth is these features are not simple and not everyone is a competent user of them. That is why when the trade-off is calculated, you may decide to leave these features out of your project.

About single-inheritance and other C++ goodness, I think the trade-off speaks clearly in favor of using these features, even for a team of beginner programmers.


3. Again to emphasize, being a competent programmer is a major point both jpetrie and Linus touched. To be a competent C programmer you need to understand pointers, and function pointers. <edit: bad phrasing follows, please do not take literally... see posts below>You can learn entire C to expert level in a day or two. To be a competent C++ programmer you need, well, more brainpower, and I am not sure how many days (years?) it takes.


4. Virtual methods are much clearer than their C counterparts (which are function pointers). This is an example where C++ is clearer than C, and it is not the only example. But there are several features such as exceptions and operator overloading and hidden temporary variables that are less clear than the C counterparts (here I compare exceptions to checking return code of functions). It is clearer to follow code which doesn't use exceptions, it is clearer to follow code which doesn't use operator overloading, it is clearer to follow code which has every variable visible.

Same way it is clearer to follow code which uses only single threading, only non-virtual methods and no pointers, but that is not the difference of C and C++. All these features which result in somewhat less clear code have other benefits which make them worth including, I am just stating they make code less clear.


My ratings drop every time I defend C's simplicity as an advantage to some degree, so I think I'll stop now before I drop below 1000 :(

Iftah.

[Edited by - Iftah on January 3, 2008 4:56:32 PM]

Quote:Original post by Iftah
You can learn entire C to expert level in a day or two.

Bullshit.

Quote:Original post by Gage64

Quote:What I meant is if you interface with someone and you encounter a problem (bug or performance problem for example) and the other person is away sick, then you have to search and explore his code yourself and then you are better off exploring simpler more visible code.

Of course, this simplicity comes at a heavy price of development costs and much harder maintainability

So C code is harder to maintain but easier to find bugs in? One of the main activities done during maintenance is reading code, so I'd say those two arguments are at odds with each other.

Of course asking which program is easier to maintain without an actual example is meaningless, but in general-

Maintainability is easier if the code is properly modulized and encapsulated, which is more natural in C++ than in C. So on that aspect C++ code is usually much much easier to maintain, because usually C code is more of a mess.
By the way, maintainability to me is not only bug fixing but also extending to new requests, and here again the better design is the winner and C++ supports tools for better design.

But consider looking at a single function from the large project, for example take a single function from the code of firefox.
If the entire code of firefox is written in C, you only need to explore the code of the function and the functions it activates (recursively). You can for the most part very easily follow the code line after line as if you are the CPU itself. The only exception is function pointers which at that point will make it somewhat hard to follow the code, but you will know very well a function pointer is used.

If the entire code of firefox is written in C++, you will have harder time to know if a function is virtual or not, because they look the same. You will also have to make sure operators are what they seem, and worry about overloaded functions and more. You will also have to consider the possibility of exceptions (which are not trivial at all). You will be able to follow the code line after line, but maybe somewhat slower because there are more possible things to explore.

This is similar to exploring a single large switch-case versus a polymorphic function (either virtual method or function pointer). The switch case is much easier to follow, because you see all the possibilities together, but it is harder to maintain because it promotes bad design.

So following the code is (generally) easier in C, but maintaining the code is (generally) much easier in C++.

Iftah.

Quote:Original post by Iftah
To be a competent C programmer you need to understand pointers, and function pointers. You can learn entire C to expert level in a day or two.

Erm, no. Expertise in a given language is more than just understanding the syntax and basic usage thereof. If you don't know things like the rationale behind limiting yourself to a single exit point, or what a Duff's Device is, you're no expert C programmer -- and I find it difficult to expect that from a day or two of learning, even from someone who's coded in other languages before.

Quote:Original post by SiCrane

Quote:Original post by Iftah
You can learn entire C to expert level in a day or two.

Bullshit.

Agreed, sorry, expert level was a wild exaggeration.

but if you consider C as only the language, that is only syntax (no libraries, no proper programming techniques, etc...) then maybe one can learn it in a day.

MaulingMonkey: Again, sorry for the exaggeration, I originally wrote competent and then thought only of syntax knowledge and changed to "expert" which was really a bad wording. But anyway, I program in Pascal/C/C++ for 12 years now and never heard of Duff's Device... gulp, maybe I should quit my job before my boss finds out.

Quote:
My ratings drop every time I defend C's simplicity as an advantage to some degree, so I think I'll stop now before I drop below 1000 :(

I think it's more about how you do it. C is clearly simpler than C++, since C++ is a rough "superset" of C. But when you make completely uninformed, incorrect statements like

Quote:
You can learn entire C to expert level in a day or two. To be a competent C++ programmer you need, well, more brainpower, and I am not sure how many days (years?) it takes.

well... you're asking for it. Much of what makes C++ a nasty little tricky language came from C. You're not one of those people who think C++ is "close to what the processor" does, are you? Read the second half of this, then, particularly ToohrVyk's post.

Quote:
2. About being a "competent" programmer:

Are these points arguing with me, or with somebody else? I never made any claim to the effect of somebody's bug production rate, only that your claims about operator overloading, et cetera, was flaccid. I note you've not yet answered my question about which of the two statements was faster, and performance seemed to be a major driving point of your arguments.

Quote:
but if you consider C as only the language, that is only syntax (no libraries, no proper programming techniques, etc...) then maybe one can learn it in a day.

Oh, please. I can learn the syntax of nearly any language in a day -- C++ included. The following are all legal C (and C++) syntax, and also all incorrect code:

int i = 0;i = i++;int a[10];int *b = a + 12;int *p = 0;int *q;memset(&q,0,sizeof(int*)); //calloc works for this too.if(p == q) { printf("Hello, world!"); }

Quote:Original post by jpetrie
Much of what makes C++ a nasty little tricky language came from C. You're not one of those people who think C++ is "close to what the processor" does, are you? Read the second half of this, then, particularly ToohVyk's post.

Damn! He wrote a book as a reply.

hehe

Quote:Original post by Iftah
but if you consider C as only the language, that is only syntax (no libraries, no proper programming techniques, etc...) then maybe one can learn it in a day.

Okay. By this logic, I argue you can learn Spanish in a day. If you consider Spanish as only the syllables.

I figure you'll be able to do just about as much with that level of Spanish knowledge as you could with that level of C knowledge.