-
Quote
I think these are a couple of cases where c got it wrong.
Not sure about that. The C syntax allows the combination of assignment + logic test into one statement.
-
Quote
The C syntax allows the combination of assignment + logic test into one statement.
That's what I mean, they made a mistake by allowing it. Obviously this is my point of view, but I doubt I am the only person who thinks this.
It has led to lots of confusion and I am sure lots of errors, for the sake of what? To save a bit of typing, are there any other reasons why you want this? -
No, the compiler will warn you that unreachable code was detected. The whitespace is irrelevant to the token parser. The last line in that example can never be reached, and modern compilers can detect this. And some environments will even do this within the editor before you ever try to compile (for example Resharper addon for Visual Studio).
It's unreachable because of that return. The compiler wouldn't complain if I put 'ERROR_LED = 1' instead of return. Or a function call to perform a software reset. -
Quote
The C syntax allows the combination of assignment + logic test into one statement.
That's what I mean, they made a mistake by allowing it. Obviously this is my point of view, but I doubt I am the only person who thinks this.
It's not a mistake , it's a consistent syntax. If we allow the usage of some expressions just in a specific context we would limit the syntax and we would have to learn about those exceptions. Another one would then complain why he doesn't may use a specific expression in a specific context and call that a mistake.QuoteIt has led to lots of confusion and I am sure lots of errors, for the sake of what? To save a bit of typing, are there any other reasons why you want this?
How many people are still using a knife after injuring themselfes with it?
-
That's what I mean, they made a mistake by allowing it.
The whole design of C revolves around allowing you to make mistakes and leaving it to the programmer to decide.
What sense would it make to disallow inline assignment - an elementary error that I have never made in 25 years - given that one can mess up far more spectacularly by, e.g., not taking care of one's pointers?
If you want your language to make reasonable choices for you - and one often does, of course - then the simple solution is to not use C. Crippling C for those who do in fact want the dangerous features on offer would be foolish.
-
Quote
It has led to lots of confusion and I am sure lots of errors, for the sake of what?
Like they say: language doesn't make mistakes; stupid programmers do.
There are definitely a place for a "safer" language (PASCAL for example) but C is where it is today because it is C.
-
Quote
Like they say: language doesn't make mistakes; stupid programmers do.
Conveniently ignore the question and resort to abuse.
Look I would love not to use C but it is not practical. I don't even dislike C but how many times to you see a crock of shit written by some of these very clever C programmers, with 5 layers of macros and 100s of warnings. Cant be bothered typing decent names for variables.
Stupid code from a not stupid programmer. Look I realise it is hard to write widely used libraries, but trying to find debug in this sort of stuff is hard.Code: [Select]/* Create SFN in directory form */At least Madires gave me an answer to a question that I was wondering.
mem_set(dj->fn, ' ', 11);
for (si = 0; lfn[si] == ' ' || lfn[si] == '.'; si++) ; /* Strip leading spaces and dots */
if (si) cf |= NS_LOSS | NS_LFN;
while (di && lfn[di - 1] != '.') di--; /* Find extension (di<=si: no extension) */
b = i = 0; ni = 8;
for (;;) {
w = lfn[si++]; /* Get an LFN char */
if (!w) break; /* Break on end of the LFN */
if (w == ' ' || (w == '.' && si != di)) { /* Remove spaces and dots */
cf |= NS_LOSS | NS_LFN; continue;
}
if (i >= ni || si == di) { /* Extension or end of SFN */
if (ni == 11) { /* Long extension */
cf |= NS_LOSS | NS_LFN; break;
}
if (si != di) cf |= NS_LOSS | NS_LFN; /* Out of 8.3 format */
if (si > di) break; /* No extension */
si = di; i = 8; ni = 11; /* Enter extension section */
b <<= 2; continue;
}
if (w >= 0x80) { /* Non ASCII char */
#ifdef _EXCVT
w = ff_convert(w, 0); /* Unicode -> OEM code */
if (w) w = cvt[w - 0x80]; /* Convert extended char to upper (SBCS) */
#else
w = ff_convert(ff_wtoupper(w), 0); /* Upper converted Unicode -> OEM code */
#endif
cf |= NS_LFN; /* Force create LFN entry */
}
if (_DF1S && w >= 0x100) { /* Double byte char */
if (i >= ni - 1) {
cf |= NS_LOSS | NS_LFN; i = ni; continue;
}
dj->fn[i++] = (BYTE)(w >> 8);
} else { /* Single byte char */
if (!w || chk_chr("+,;[=]", w)) { /* Replace illegal chars for SFN */
w = '_'; cf |= NS_LOSS | NS_LFN; /* Lossy conversion */
} else {
if (IsUpper(w)) { /* ASCII large capital */
b |= 2;
} else {
if (IsLower(w)) { /* ASCII small capital */
b |= 1; w -= 0x20;
}
}
}
}
dj->fn[i++] = (BYTE)w;
}
if (dj->fn[0] == 0xE5) dj->fn[0] = 0x05; /* If the first char collides with deleted mark, replace it with 0x05 */
if (ni == 8) b <<= 2;
if ((b & 0x0C) == 0x0C || (b & 0x03) == 0x03) /* Create LFN entry when there are composite capitals */
cf |= NS_LFN;
if (!(cf & NS_LFN)) { /* When LFN is in 8.3 format without extended char, NT flags are created */
if ((b & 0x03) == 0x01) cf |= NS_EXT; /* NT flag (Extension has only small capital) */
if ((b & 0x0C) == 0x04) cf |= NS_BODY; /* NT flag (Filename has only small capital) */
}
dj->fn[NS] = cf; /* SFN is created */
return FR_OK;QuoteIt's not a mistake , it's a consistent syntax. If we allow the usage of some expressions just in a specific context we would limit the syntax and we would have to learn about those exceptions. Another one would then complain why he doesn't may use a specific expression in a specific context and call that a mistake.
But I when I weigh up consistent syntax vs what make sense. I prefer statements that make sense.
I don't really know what is consistent about a single assignment statement within parenthesis for a conditional, is somehow consistent with the 'for' statement?
-
Quote
Like they say: language doesn't make mistakes; stupid programmers do.
Conveniently ignore the question and resort to abuse.
Look I would love not to use C but it is not practical. I don't even dislike C but how many times to you see a crock of shit written by some of these very clever C programmers, with 5 layers of macros and 100s of warnings. Cant be bothered typing decent names for variables.
Stupid code from a not stupid programmer.
Oh dear, Elm Chan's FAT library. Known to be faulty and itchy. The guy itself is certainly not stupid but he is not a good programmer when it comes to stuff like maintainability. And that is my first point.
My second point would be that one could create the same mess in any language, it doesn't require C at all.
My third point would be that this is the kind of code where you need additional documentation.Because, even if well written, the task as such defeats self-documenting code. (most stuff does, self-documenting code is largely a myth). So what is missing in that particular case? The Windows FAT file system specification. You can't squeeze that into a few comments in the code.
My forth point would be, while one actually needs the FAT specification to write this properly, Elm Chan probably didn't have it. And what you see is the result of (incomplete) reverse engineering or using dubious web sources. Garbage in - garbage out.
Non of this has anything to do with the language. It is all about the competence of the programmer and the available documentation.Quotebut trying to find debug in this sort of stuff is hard.
Well, I have a suspicion here. There is a generation of coders (I refuse to call them programmers), who think the only way to debug is plastering code with printf's. Debugging code like the one shown becomes at least twice as hard when using printf's instead of learning how to use proper debugging techniques, like ICE, a simulator and/or a hardware logic analyzer together with a proper SW debugger.
Still, you need the specification to debug that code, which no debugger can provide. -
Quote
Oh dear, Elm Chan's FAT library
lol
I like to put in links to documents or specs or whatever I ported from.
I agree with just about all of what Bored@Work said.
except the forth point, where I would say c programmers seem to have a mentality that if you can do 5 things in one line and name your variables in the most abbreviated form possible then the code will run faster.
-
except the forth point, where I would say c programmers seem to have a mentality that if you can do 5 things in one line and name your variables in the most abbreviated form possible then the code will run faster.
People doing that aren't programmers, they are just hacking code together. But you'll see that done using other languages also. -
Quote
with 5 layers of macros and 100s of warnings.
That kind of programming style makes lots of sense to me. One friend used to tell me that an easy way to tell if a piece of code is properly done is to count the number of ASSERT() used. Superficial but true.
I think you may be in a situation where you insist that others slow down so you can catch up with them. A happier approach might be to run with like people.
-
Quote
where I would say c programmers seem to have a mentality that if you can do 5 things in one line and name your variables in the most abbreviated form possible then the code will run faster.
I think you find that people do that tend to program for fun, rather than program for a living: that kind of code has no chance of passing QA in any respectable shop.
-
Stupid code from a not stupid programmer. Look I realise it is hard to write widely used libraries, but trying to find debug in this sort of stuff is hard.
I guess it's mostly subjective as I deal with code like that all the time and don't find it any harder to understand... the use of SI and DI there suggest either this was ported to C from x86, or the programmer came from an x86 background, or it was RE'd from x86 code (the MS filesystem driver?) Although I think the indenting is a bit excessive. -
Not really understanding the Python hate, just set your editor to insert spaces as tabs @ 4 spaces and I've never had any issues. I actually like the whitespace because it forces consistency which is more important to me than whatever coding standards you are using.
For me you answered your own question: The editor can do it. Almost any programming editor can indent automatically, so you're never more than a couple of keystrokes away from the way you like to have it indented. Unless, of course, you're using a language where indentation is significant. Then the editor can't indent correctly without your input. By making indentation part of the syntax, they "fixed" a problem that didn't exist, and in doing so they annoyed many people -- myself included. -
That's what I mean, they made a mistake by allowing it.
The whole design of C revolves around allowing you to make mistakes and leaving it to the programmer to decide.
.....
This what language is better is getting to be like reading the political section of the news paper.
This is a little like the Democrat Republican/Libertarian thing. One prefers minimal government and let individuals decide, another prefers government sets the value and you live within it, and yet another will care for you craddle to grave, as long as you don't assign too many variables on the same line, and your program generates the exact same output as all the other programs written by high school kids from any background, and PhD candidates of any fields alike. Equality of outcome is only fair.
Yes, I am tolerant as long as I agree with you. So shut up and use the language I choose for you mere mortals.
You programmers has an easy job, so stop grumping about the language. You spend the whole day setting things into just ones and zeros. Just ones, and zeros. How hard can that be.
Tax time - Now pay up for the 65536 bits of one you set just in the first 4 minutes this morning at $1/bit, and the next 65536 bits of ones at $2/bit, and $4/bit the next 65536, and.... Bits set exceeding the average will be tax at twice your annual income. That should teach you not to unfairly set more bits than your fellow programmers. It is not democrats who can't count, it is the citizen because after tax, they are left with nothing to count.
I think I am a liberterian, (edit: clicked too soon, missing these)
I think I am a liberterian, I like C. I program in C. I program for myself. I am the sole judge of my output. I choose the risk, the mistake, the reward and I live with the consequences of my decision. -
I have found this "nimrod-return-of-pascal" review
-
Quote
I live with the consequences of my decision.
PASCAL: I am the government, and I am here to help.
-
Quote
I live with the consequences of my decision.
PASCAL: I am the government, and I am here to help.
But you can't find me... I have no new knee, no new pace-maker, no new hip, so no RFID in my body. So there.
This note will self destruct in 10 seconds and you will have even one less clue. Excuse me, I am heading back into my "cone of silence"... -
I liked D when I looked at it last (about a year ago), but as for compilers, it was in a sorry state. The GCC plugin was massively out of date (IIRC only compatible with D 1.0) and the other compiler only ran on a few platforms and was closed-source.
Looks like some of that has changed now. I just downloaded the source for the main compiler, but the license terms are ambiguous. (The main license.txt says "this is not open source" and all of the individual files I've opened claim to be GPL / "Artistic license", and even some under the Boost Software License
) The compiler comes in a 64-bit binary version now, but I'm not sure if it will actually compile a 64- bit binary.
It looks like a lot of progress has been made since then, though. I think I may take another look at this.
I tried it a while back but struggled to make much progress, but now they seem to have got the libraries sorted; I created a little console app for work using it and I was nicely surprised.