Who here doesn't use C and why?

[Solar]

Language bashing can be fun and actually educational, but only when done with style. This didn't happen here, so I'll just throw in four remarks:

1) If you do stuff like #define begin {, you are using a C compiler, but you aren't using C. "Using" a language means using its native constructs.

I've seen many a former Java programmer who wrote, in a C++ context, stuff like next() and hasMoreElements(). Such people have not understood what it means to use a language.

2) "C is unreadable - Compare { vs. begin." You could say it's a matter of habit. You could say that begin is more like native language while { is more technical. You could, on the other hand, even argue (as MessiahAndrw did) that it actually adds to readability when the grouping of statements is done by brackets instead of special statements.

But simply throwing up a blanket statement like the above without backing it up with anything beyond your personal opinion is pretty stupid. By the way, I much prefer the bracket style over either begin / end or having whitespaces carrying meaning Python-style.

3) Anyone suggesting redefinitions of brackets, or suggesting digraphs / trigraphs merely because they are "more comfortable to type" should never step near any development team I have any say in, or hope the office is on ground level, because I'll toss him out of the next window.

4) If you want to point out defencies in a language, you should at least know it well enough to correctly know its syntax, the rationale behind it, and the current version of its standard library.

A lot of the statements made about "shortcomings" in C, most especially the posting by Craze Frog on page #1 of this thread, are simply wrong and / or malinformed.

----

That being said, C has its uses where ASM is too low-level and stuff like Basic, Java, Python et al. are too high level. As any language, it fares poorly when used for something it wasn't designed for (like for big applications, string processing etc. etc.).

[DeletedAccount]

Ooops ...Yes ... #defines etc are a part of the C Macro Processor not the part of the C Language .. Anways i never recomended using Begin instead { ... But it does serve as a work around for those who cant live without Begin and End ... I just wanted to show that C is so flexible .....

[Solar]

I think you misunderstood my first point. If you redefine begin / end, you're writing Basic using a C toolchain. Same with hasMoreElements() - that's taking Java and using it with a C++ toolchain.

Only when you really use a language you can judge its relative merits. Someone who complains that he can't do begin / end in C is simply making a fool of himself. I'm not complaining that ASM doesn't support protected inheritance, either.

[DeletedAccount]

C is a good language and a time tested one .. .But it indeed has its quirks ... Let me demonstrate

Code: Select all

i = i++;

The above code fragment looks very innoccent .. But it is actually ambiguous ..coz when same object is modified twice between 2 sequence points .. The result is undefined .....Different compilers give different results .. So for maximum portability one should not use constructs like the one given above ....

Code: Select all

int v = ( 4 , 5, 9 , 10 );

v should contain the value 10 ...Associvity rules .... But consider this

Code: Select all

int i = 2;
int j = (i++,++i,i);

Different compilers give different results .....
There are also many errors that can come from the incorrect use of macros and pointers ... ie you need to be a bit careful when using c

[JamesM]

Same with hasMoreElements() - that's taking Java and using it with a C++ toolchain.

I feel here that you are blurring the distinction too much between "language" and "conventions used by programmers of that language".

I don't even know what you're complaining about - the use of camelCase or the implementation of a nondetachable iterator...

[Candy]

C is a good language and a time tested one .. .But it indeed has its quirks ... Let me demonstrate

Code: Select all

i = i++;

The above code fragment looks very innoccent .. But it is actually ambiguous ..coz when same object is modified twice between 2 sequence points .. The result is undefined .....Different compilers give different results .. So for maximum portability one should not use constructs like the one given above ....

Code: Select all

int v = ( 4 , 5, 9 , 10 );

v should contain the value 10 ...Associvity rules .... But consider this

Code: Select all

int i = 2;
int j = (i++,++i,i);

Different compilers give different results .....
There are also many errors that can come from the incorrect use of macros and pointers ... ie you need to be a bit careful when using c

Actually, the comma operator is the sequence operator... so the second example should make j equal to 4. The first example can be synthesized in two ways - that unfortunately for your example, have the same result.

If you redefine begin / end, you're writing Basic using a C toolchain.

Please don't insult basic. It's pascal using the begin/end constructs.

... should never step near any development team I have any say in, or hope the office is on ground level, because I'll toss him out of the next window.

There's a word for that: defenestrate.

[Combuster]

Since many of the comments here deals with taste, I think most of the complaining is actually about the compilers rather than the language. Specifically, how the compiler prints warnings and errors.

I doubt anybody has tried the difference between Helium and GHC/Hugs (= haskell compilers). The latter simply prints the exact error that occurs, while Helium analyses the source of the problem and apart from the error, describes why it is an error and probable causes/fixes that come with it. While the first only supports a subset of the language features and other things compared to the big riddle-talking beasts, the helpfulness of the compiler is a very strong reason to choose it over the others.

My guess would be that C is disliked since gcc (and msvc) likes to use geekspeak rather than plain english to tell the user what's going on. That makes it difficult (and less efficient) to write in that language. Especially when you have something more appealing to use.

While gcc is doing a good job for C standards, there is lots of room for improvement. The same holds for compilers of any other language. I'd make a bet that among people with the same amount of experience, the average error message given by visual basic leads to a fix much sooner than the average message given by GCC. It does not imply that basic is therefore superior.

That'd be my $.02

[Craze Frog]

And what is style but another overuse of the italic tag?

2) "C is unreadable - Compare { vs. begin." You could say it's a matter of habit. You could say that begin is more like native language while { is more technical. You could, on the other hand, even argue (as MessiahAndrw did) that it actually adds to readability when the grouping of statements is done by brackets instead of special statements.

Or you could, like Solar, argue that saying "Opening curly bracket" feels more simple than saying "begin". Simply because it's shorter (oups, that was 21 characters to 5, not that much shorter).

Of course, when you argue with sound arguments like that, that's style.
But...

By the way, I much prefer the bracket style over either begin / end or having whitespaces carrying meaning Python-style.

... simply throwing up a blanket statement like the above without backing it up with anything beyond your personal opinion is pretty stupid.

3) Anyone suggesting redefinitions of brackets, or suggesting digraphs / trigraphs merely because they are "more comfortable to type" should never step near any development team I have any say in, or hope the office is on ground level, because I'll toss him out of the next window.

Great. Let's turn { into '*1539o&3+t69õöfjalasdfk474 while we're at it, since ease of typing doesn't matter, right? Half of the things you do with language symbols is typing them (the other half is reading them), so typing better be easy. There is a very good reason why hieroglyphs didn't catch on. Must your programming team be doomed to writing APL with a normal keyboard (sort of like writing C with my keyboard) for eternity.

A lot of the statements made about "shortcomings" in C, most especially the posting by Craze Frog on page #1 of this thread, are simply wrong and / or malinformed.

- C is untypable
{ requires AltGr+7, which means stretching or moving the hands a lot

Not wrong on my keyboard.

- C is illogical
An empty parameter list does not mean no parameters, but any number of parameters.

Correct according to here: http://david.tribble.com/text/cdiffs.htm#C99-empty-parm

In "int unsigned* ptr, notptr;" notptr does not become a pointer, but it becomes unsigned.

Everyone knows this is correct.

- The de facto free C compiler, gcc, is very slow (I'm talking about the compilation time)

Calling "gcc main.c -O0" takes about 400 ms here, and main.c is about 12 lines with almost no code (no includes as well).
Calling "timer fpc kernel.pp" takes only 120 ms, and compiles over 300 lines of code over several files.
Free Pascal is also horribly slow compared to the Delphi compiler. I can't see how this is wrong.

* in declarations means you want a pointer.
* in normal lvalues means you don't want the pointer, but the value it points to.

Everyone who knows basic C knows that this correct.

- C's preprocessor features are very basic and too error-prone compared to the things you can do with it

If you ever used another macro system you know what I mean.

- C requires makefiles or similar
Lots of typing and thinking for what can easily be done automatically by the compiler

If you spread your sources over different object files, you need to actively do something to compile and link the extra files. The C compiler simply doesn't know what you want. I can't see how this can possibly be false.

- C requires header files
Lots of typing for what can easily be done automatically by the compiler.

Of course, you can put everything in one file, but if you want to separate compilation, you need header files. I can't see how this can possibly be false.

- C uses escape characters in character strings, thus molesting path names in some operating systems
You can say it's no big deal as C is for UNIX, but on the other hand, they made the type system unusable under the cover of cross platform-ness, so why did they suddenly stop caring?

Everyone knows C uses escape characters, I can't see how I can be wrong. Having to write \\\\ just to do a regular expression match on one \ is overkill.

- C doesn't know basic math
If a has the value 6385921 and you do "a += 1;" then a may well have the value 6385925 if a was declared as int *.

People later explained why it was like this, if it's false, why didn't they say? Simple: This is correct.

- C doesn't know basic logic
There is no non-bitwise XOR operator in C.

Not wrong either. Gcc has one, but it's not standard.

- The last good thing written in C was Händel's recorder sonata

This was wrong. It's of course Bach's prelude.

Please tell me what's wrong with it.

I think you misunderstood my first point. If you redefine begin / end, you're writing Basic using a C toolchain. Same with hasMoreElements() - that's taking Java and using it with a C++ toolchain.

Only when you really use a language you can judge its relative merits. Someone who complains that he can't do begin / end in C is simply making a fool of himself. I'm not complaining that ASM doesn't support protected inheritance, either.

Here I totally agree with you. I'm not saying I don't use C because I can't use begin and end it. Because I can, with defines. I'm saying that as long as I can't type it comfortably, I won't use it. I'm not saying that it should be changed, I'm saying that I'm not using it. That was also the original question.

[01000101]

I have always been a C programmer. The first language I dabbled with was PERL in the Slackware 3.3 shell, then I went straight into C/C++ and later I realized how much i hated programming in C++ so i just focused everything on C. Once I furthered my skills, I decided to pick up x86 ASM as well.

in comparison with one of the beginning posts, I score extremely high on the math portion of tests and only OK on the verbal peices.

[Alboin]

I think the problem with C is that it is *very* difficult to write good code in.

Newcomers to the language think they know the language, write programs in it, and find that their software is trash. Instead of blaming their failure on themselves, they blame the language. "There's no array boundaries! ", "Pointers are icky!", etc.

IMHO, it takes *many* years to even begin to write semi-decent code in C. For example, a few months ago, I haphazardly wrote a smallish (~4000 lines) program in C. After dozens of segmentation fault bugs (Some that I never fixed.), I rewrote the entire thing in C++. It's now only 2500 lines, and works wonderfully.

It's just easier to write good software in <Insert HLL here> than in C.

[JamesM]

Troll: noun. One who lives under a bridge, ready to strike at an unsuspecting forum poster whenever the language "C" is mentioned. Personified by the user "Craze Frog" (please also note the (deliberate?) misspelling) on the forum "OSDev.org".

[AJ]

As with all language flamewars, people seem to be missing the point that you must use whichever language you can be most productive in for a particular task.

I prefer too, begin,end,procedure,function,... in pascal. Its just better for your eyes to see words instead of bloated symbols like {,},();,void _main(*char @args);...

Fine, I prefer {,},() et. al.

Rather than making the blanket statement "It's better for your eyes...", It would, perhaps, be better to say things like "I find it more readable...". I know that quote was fairly early in the conversation and I'm not trying to pick on the 'quotee', but if you make statements like the above, those who use C feel that they need to jump to its defense. You can then predictably sit back and watch the ensuing 4 page argument.

As Solar says, language arguments can be fun and educational - but only if you can empathise with other people and don't take things too personally.

Cheers,
Adam

[Craze Frog]

Troll: noun. One who lives under a bridge, ready to strike at an unsuspecting forum poster whenever the language "C" is mentioned. Personified by the user "Craze Frog" (please also note the (deliberate?) misspelling) on the forum "OSDev.org".

The question was who doesn't use C and why. I answered. I guess that was wrong. The original poster probably wanted a rush of "I love C, it's so geeky"-posts. I'll do that in the future.

Everyone who repeatedly defends and uses C in this thread is not answering the question of the poster, and that is called spamming.

spamming is an inappropriate attempt to use email, or another networked communications facility by sending the same message to numerous people who didn't ask for it.

[binutils]

or he want some kind of answer.

[Laksen]

Things I enjoy about Object Pascal that I seem to lack in C:
-case insensitivity. Really... Is there a need for something like case sensitivity? To me it is a complete annoyance
-The header/source thing. I just don't like it. The UCSD pascal unit convention goes much better to my taste of code/interface seperation
(The following is probably more of a compiler problem)
-basic error checking(overflow, bounds, range, etc). I understand why some people, me included, would like to have them disabled sometimes, but I can disable them easily. Having this feature allows me to code alot faster without having to worry about small problems that might result in bugs later on

I could keep complaining but those were the major points, that didn't have very much with syntax to do