Quote: Original post by MaulingMonkey

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.

If you know pascal and you learn the C syntax you can program fluently in it in a day (you may maybe confuse = and == for a while...). I know because I did that 10 years ago. If I know English I can't just learn the syllables and talk fluent Spanish. Btw, I checked Duff's device now and I did see such code before more than once, but never knew the name for it. *phew*

Please don't focus on the timeline I gave for learning C, that was not ever my point and it is not my opinion that one can be called expert after a day, just bad wording. I would gladly edit it to a better phrase, it would make the thread less clear ;)

Quote: Original post by Iftah
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.

1) Principle of Least Surprise.
2) I fail to see how knowing "if a function is virtual or not" is relevant to "maintaining" the code.

Iftah > Maybe a good analogy would be that knowing how chess pieces move does not make you an expert chess player?

Quote: Original post by Zahlman

Quote: Original post by Iftah
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.

1) Principle of Least Surprise.
2) I fail to see how knowing "if a function is virtual or not" is relevant to "maintaining" the code.

Knowing if a function is virtual is NOT relevant to maintaining the code.
heck I wasn't the one who mentioned maintaining, I only mentioned following the code. If you know something by looking at it then its easier to follow. That is all.
That was the whole point of Joel, that is the whole point of my weakly replies.
I don't know why you guys are bashing me so much for it... as we clearly agree on the facts, I think you just hate to admit the simpler C means easier to follow code.
Maintainability is another issue, which is what I explained at that post exactly...

Quote: Original post by janta
Iftah > Maybe a good analogy would be that knowing how chess pieces move does not make you an expert chess player?

thank you janta,

I meant to say you can learn entire C in a day (as you can chess), which I phrased badly. Of course you can also learn entire C++ in a day to that extent which means I shouldn't have mentioned it at all. I was trying to explain C is simpler and thus it is easier to be competent in it, and it came out very badly phrased, and people focused on that line jumping on chance to find me wrong... sigh oh well.

So to summarize the "competent programmer" point- it is easier to be competent in C than in C++.

Quote: Original post by Zahlman

Quote:

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;}

Owned.

Really, Zahlman never ceases to give me reasons to leave him the hell alone when it comes to coding argumentsdiscussions.

Quote: Original post by jpetrie
And besides, what does it matter? Okay, so a function call is virtual. And? Do you think that's a performance bottleneck? Did you profile it? The features in question are higher level language features design to increase productivity of the developer. Yes, they may from time to time have a performance impact. That does not make them wrong. Using them incorrectly makes them wrong, and any feature in any language can be abused in such a fashion. Prematurely worrying about expensive copies and all that other early, unguided optimization is frequently a productivity killer.

And let's not even get into all the tools available in modern development environments to detect and track most of these issues, to navigate and profile and sanity check code, et cetera.

I agree with you on every word. I think you misunderstood me, I did not say using such and such features is wrong. I only that on such and such feature when consider only parameter of "code clarity" then the feature may have negative impact (on that parameter alone...).

Quote:

Quote:
the less hidden code the better. And on that parameter alone C wins.

Tell me which is slower, I dare you:

a = b;//ormemcpy(&x,&y,z);

Go ahead, I'll wait.

I have no idea what you want to show by this, as it proves my point. On the second line you clearly see a memcpy, on the first line you have no idea what you see. It is not possible to know that without exploring the types of "a", "b" and their possibly their entire inheritance. That is my point exactly, not performance - just the clarity of code. I really think you misunderstood me.

Quote: Original post by Iftah
I meant to say you can learn entire C in a day (as you can chess), which I phrased badly.

Bullshit.

Quote:
I have no idea what you want to show by this, as it proves my point. On the second line you clearly see a memcpy, on the first line you have no idea what you see. It is not possible to know that without exploring the types of "a", "b" and their possibly their entire inheritance. That is my point exactly, not performance - just the clarity of code. I really think you misunderstood me.

Nope, you missed my point. Remember that this question was originally posed following your assertion that

Quote:
And its not an issue of accidentally formatting the harddrive, its an issue of invisibly putting a slow copy constructor to a temporary variable somewhere in a performance critical code. Yes, you could find it easily being an experienced C++ programmer, but wouldn't it be easier to find if it was a function call with visible memcpy?

That's the context of the question; while you may have mutated your argument since, the point still stands that your original statement here was (to quote SiCrane), bullshit. And you're still not seeing it -- you're assuming the first example (C++) lacks context about a and b. You're assuming the second example has context about x, y and z.

But my example has no context for either statement, intentionally. The point is that you must examine the code for the context anyway. Just because the first example is an operator= and the second a memcpy doesn't make any damn difference. Scroll up to the top of the function to find some context, then you'll discover:

int a = 0;int b = 0;char *x = /* ... */char *y;int z = 9000;

Whoops. The memcpy was the hidden expensive copy call.

Quote: Original post by jpetrie

Quote:
And its not an issue of accidentally formatting the harddrive, its an issue of invisibly putting a slow copy constructor to a temporary variable somewhere in a performance critical code. Yes, you could find it easily being an experienced C++ programmer, but wouldn't it be easier to find if it was a function call with visible memcpy?

That's the context of the question; while you may have mutated your argument since, the point still stands that your original statement here was (to quote SiCrane), bullshit. And you're still not seeing it -- you're assuming the first example (C++) lacks context about a and b. You're assuming the second example has context about x, y and z.

But my example has no context for either statement, intentionally. The point is that you must examine the code for the context anyway. Just because the first example is an operator= and the second a memcpy doesn't make any damn difference. Scroll up to the top of the function to find some context, then you'll discover:

int a = 0;int b = 0;char *x = /* ... */char *y;int z = 9000;

Whoops. The memcpy was the hidden expensive copy call.

Again no idea what you are trying to say, my text you quoted talks about temporary variable and copy constructor where the focus is that they are invisible.
memcpy is much more visible. The entire point of code clarity is it is harder to miss mistakes, it is easier to search for context.
And yes, it is easier to spot memcpy than it is to spot temporary variable. It is easier to search the size of the memcpy and harder to search for overloaded functions.
Not that one is slower or faster, that would take more specific context, just that one is more visible and for that no context is needed to notice it. Read my original text (which you quoted) I talked about easier to find, not about slow/fast. Again, it is harder to find a temporary variable than a visible variable. It is usually harder to notice a copy constructor than a memcpy.


p.s. I know very well about virtual memory and cache and such if thats what you refer by pointing to the other thread (barely read it yet), I don't think C code is equivalent to the CPU work, but usually you don't have to debug virtual memory so I have no problem with it being completely hidden, and its hardly comparable to hard to follow invisible logic of a program.

I am going to sleep. I should have taken my own advice and quit a long time ago. good night.