C for everyone else
wizardryandfunnyhats.com
C for everyone else
1–10 of 11 posts
Re: C for everyone else
#2This is very well-intended, but it suffers from both lots of formatting errors and pure factual ones. It makes my highly conditioned (from Stack Overflow) C lecturing mode almost auto-trigger.
It's way too long to do a rebuttal here, though.
Some problems:
- Bad terminology ("C has no object", when in fact the term really is very useful in C even though it probably doesn't mean what you expect if you come from C++ or Python)
- "Booleans don't exist", I don't understand how the author can both acknowledge C99 and say this. Booleans do exist! Their name is not so user-friendly, unless you include stdbool.h, then you get bool, true and false.
- Pure random errors, like the first structure example code ("struct point foo={x: 5, y: 4};", what are those colons and numbers doing there?!)
And so on.
Re: C for everyone else
#3This is very well-intended, but it suffers from both lots of formatting errors and pure factual ones. It makes my highly conditioned (from Stack Overflow) C lecturing mode almost auto-trigger. It's way too long to do a rebuttal here, though. Some problems: - Bad terminology ("C has no object", when in fact the term really is very useful in C even though it probably doesn't mean what you expect if you come from C++ or…
> Null terminated strings also don't allow us to use multibyte encodings such as utf-8.
This just makes me cry.
Re: C for everyone else
#4This is very well-intended, but it suffers from both lots of formatting errors and pure factual ones. It makes my highly conditioned (from Stack Overflow) C lecturing mode almost auto-trigger. It's way too long to do a rebuttal here, though. Some problems: - Bad terminology ("C has no object", when in fact the term really is very useful in C even though it probably doesn't mean what you expect if you come from C++ or…
> Null terminated strings also don't allow us to use multibyte encodings such as utf-8. This just makes me cry.
Because it is unfortunate or because it is incorrect?
Re: C for everyone else
#5This is very well-intended, but it suffers from both lots of formatting errors and pure factual ones. It makes my highly conditioned (from Stack Overflow) C lecturing mode almost auto-trigger. It's way too long to do a rebuttal here, though. Some problems: - Bad terminology ("C has no object", when in fact the term really is very useful in C even though it probably doesn't mean what you expect if you come from C++ or…
The last is not an error, it's simply outdated:
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
These days, you should spell it:
struct point foo = { .x = 5, .y = 4 };Re: C for everyone else
#6Something tells me I shouldn't have done this out of an impulse. I basically hacked it away in 1 hour with one proofread. I felt on fire and wanted to push it out that probably wasn't such a good idea.
Of course you can represent utf8 in null terminated strings but you have to escape escape the null character, or if used as a terminator implicitly assume it's there. The basic jist of that was that I wanted to say, dont use byte encodings internally if you got large registers available and keep attention to null termination and it's pitfalls.
But justification beside I'm going to give it more time and reference check against the standard, refrase my intentions so that they are clear and probably shine more light on the positive aspects of the language and put it intro relation with other languages.
Hacker News isn't a place for pre alpha done in very little time drafts.
Re: C for everyone else
#7This is very well-intended, but it suffers from both lots of formatting errors and pure factual ones. It makes my highly conditioned (from Stack Overflow) C lecturing mode almost auto-trigger. It's way too long to do a rebuttal here, though. Some problems: - Bad terminology ("C has no object", when in fact the term really is very useful in C even though it probably doesn't mean what you expect if you come from C++ or…
As for booleans I don't consider macros and further macros which are part of the library as a datatype, but yes of course they are in the core language. What I wanted to express was that booleans are nothing more than integers with sugar sprinkled over the top. You're right.
Re: C for everyone else
#8Earlier quoted context omitted.
> Null terminated strings also don't allow us to use multibyte encodings such as utf-8. This just makes me cry.
Because it is unfortunate or because it is incorrect?
I admit that it's certainly technically correct that you cannot embed a U+0000 into UTF-8. Of course, anybody who actually needed to be able to represent U+0000 in a C string would simply represent U+0000 as 0xC0 0x80 and be done with it.
Re: C for everyone else
#9Earlier quoted context omitted.
Because it is unfortunate or because it is incorrect?
I admit that it's certainly technically correct that you cannot embed a U+0000 into UTF-8. Of course, anybody who actually needed to be able to represent U+0000 in a C string would simply represent U+0000 as 0xC0 0x80 and be done with it.
Heh, I wasn't calling you out, I was curious - I've done a little work with multibyte strings in C but never UTF-8, and it's been a very long time, so I didn't remember enough of the details to be sure of which you were saying.
Re: C for everyone else
#10Earlier quoted context omitted.
Because it is unfortunate or because it is incorrect?
I admit that it's certainly technically correct that you cannot embed a U+0000 into UTF-8. Of course, anybody who actually needed to be able to represent U+0000 in a C string would simply represent U+0000 as 0xC0 0x80 and be done with it.
But ASCII null-terminated strings can't contain null either, so I don't know why he says that it's just a problem for UTF-8.
Also, if you represent U+0000 by 0xC0 0x80, then it's "Modified UTF-8", and it's not valid UTF-8.