What's To Love About C?

First time accepted submitter edA-qa writes "Antiquated, clunky, and unsafe. Though beloved to some, C is a language that many choose to hate. The mass opinion is indeed so negative it's hard to believe that anybody would program anything in C. Yet they do. In fact a lot of things, even new things, are programmed in C. The standard was recently updated and the tools continue to evolve. While many are quick to dismiss the language it is in no danger of disappearing."

Comments

because

[Anonymous Coward]

char *post = "first";

Re:because

[Anonymous Coward]

Using a string literal as not const is very bad form.

Re:because

[Anonymous Coward]

Back to C++ Land with you, rascal!

Re:because

[localman57]

No, he's right. On systems where your constants exist in a different medium than your variables (such as microcontrollers where variables are in RAM but constants are in flash), declaring a string as const or not const can have a big impact on what resources you eat up. Typcially, there's often a #pragma or non-standard keyword such as ROM that goes along with this.

Re:because

[localman57]

In many cases, you're correct. In others, not so. It varies by compiler. This is one of the problems with the C language; it isn't equipped to deal well with multiple address spaces that overlap. If you're a compiler maker, and you need the ability to point to two different address spaces with the same numerical range, you're screwed. Either you infer meaning that isn't there in the standard (e.g. const means Flash, non-const means ram), you define non-standard keywords such as ROM, or you do run-time translation of addresses (I've only seen one compiler that tried to do this, and it was a disaster...).

Re:because

[Darinbob]

Quite a lot of languages have problems with this. I would say that 100% of the current popular languages can't do this in the standard. So it's not necessarily a valid criticism of C as a standardized language or as an abstract machine-independent language. Individual compilers though typically have a set of pragmas or attributes to handle machine specific details.

Re:because

[Megane]

Bullshit. Literal strings exist in the RO section and can trivially be placed into ROM. A literal string is always const char *. Here he is assigning a const char * to a char *. The latter type does nothing to affect the literal string placement in standard C.

Then don't ever try to program a Harvard address space architecture like AVR. Unless you specify otherwise, all string literals get copied at start-up from the ROM address space into the RAM address space so they can use compatible pointers. That doesn't work very well when you only have a couple kilobytes of RAM, and want to use a lot of read-only data. To work around this, you have to use a few non-standard extensions to have pointers that reference ROM address space, and pass them to routines that know they refer to ROM data.

And even without that, compilers for embedded programming know that an initialized "static const" global goes in the read-only (.text) segment, not the read-write (.data) segment.

Re:because

[Dachannien]

No, he's right. On systems where your constants exist in a different medium than your variables (such as microcontrollers where variables are in RAM but constants are in flash), declaring a string as const or not const can have a big impact on what resources you eat up. Typcially, there's often a #pragma or non-standard keyword such as ROM that goes along with this.

And this is particularly relevant in this case, because Slashdot runs on CowboyNeal's microwave oven.

Re:because

[mooingyak]

And this is particularly relevant in this case, because Slashdot runs on CowboyNeal's microwave oven.

Ovens. You really think it's not a cluster?

Re:because

[gnasher719]

I recall that the NULL pointer is not numerically 0 on some systems.

NULL is not a pointer. NULL is a macro which evaluates to a null pointer constant. And a null pointer constant is either an integer constant expression with a value of 0, or such an expression cast to void*.

What you are thinking about is probably a null pointer. Completely different thing. But a null pointer is a pointer, and pointers are not anything numerically. They are pointers. Pointers and numbers are different things.

Now just as converting from int to float will (almost always) change the bits in a value that is converted, so can converting from int to a pointer type and back. It often doesn't, but it can.

Re:because

[dmbasso]

Don't know much about C, do we? ;-)

He does, you not so much.

If I saw the above declaration, I wouldn't be at all surprised to see a later command like:

post = "second"; // Or perhaps some computed value

If the declaration had contained a const, this would be a syntax error, since the variable post has been declared a constant.

Nopz, what was declared as constant is the memory the pointer is pointing to. Example:

1: void f() {
2: const char *a="bla";
3: a = "blu";
4: a[0] = 0;
5: }
>gcc -c t.c
t.c: In function ‘f’:
t.c:4:2: error: assignment of read-only location ‘*a’

Tip: avoid using snarky comments. When you're wrong it makes you look specially stupid.

Re:because

[TheRaven64]

Your post is so full of errors it hurts to read. The const qualifier refers to the data, not the variable in this context. The following is entirely valid:

const char *post = "first";
post = "second";

The following will have the behaviour that you are claiming:

char *const post = "first";
post = "second";

This will get a compiler error, however consider this version instead:

char *const post = "first";
post[0] = 0;

This will not give a compiler error, but will abort at run time. The type of a string literal is const char * and so it is placed in the constant data section, which may be in ROM on embedded systems and will be mapped read-only (and shared between processes) on other systems. The same problem will happen if you omit the const. The correct way to write this is:

const char *post = "first";
post[0] = 0;

This will give a compiler error on the assignment, because you are attempting to modify constant data. You will also get a compiler warning if you try to implicitly cast to char*, because the code that receives the char* may attempt to modify the data.

Any competent C programmer would use the const only when it's appropriate, to tell the compiler that a symbol isn't a variable

I guess we know exactly where you fit on the C-competence spectrum then...

One good reason...

[Anonymous Coward]

It's not the bloated obscenity that is C++.

Re:One good reason...

[serviscope_minor]

It's not the bloated obscenity that is C++.

C++ is not a bloated obscenity. It is an excellent language.

I am not claiming it is a language without warts, but I challenge any one who modded the parent post up to provide a coherent argument as to why C++ is bloated and what features you could therefore remove without detracting from the effectiveness of the language.

Re:One good reason...

[AuMatar]

I like C++, but I can think of a few. Lets ignore for the moment things like macros that are outdated in C++ and kept for C compatibility. We can easily get rid of:

*Value templates.
*Diamond inheritance (just make it illegal)
*The entire algorithms part of the STL. Nobody uses it and it makes for unreadable code (keep the container classes, of course)
*Kill either structs or classes. We don 't need both, with one being syntactic sugar to change the default visibility on the other
*The iostream libraries. I don't think I've ever seen code that didn't say fuck that and just use C style stdio. They're clunky.

That's off the top of my head, without going into things we could do better. And I like C++, it's my preferred language. The real argument here is even though C++ is bloated, it's far from the worst that way. Perl takes that crown, with it's 500 special variables. And the people who complain about C++'s bloat generally like Python or Ruby, which are both just as bloated as C++, without the bonus of it's simplicity.

Re:One good reason...

[bluefoxlucid]

Compare C++ to Objective-C. You might dislike the syntax of Objective-C some, but it has clear advantages:

• It is a strict superset of C: C compiles as Objective-C (C++ doesn't, since structs have a different syntax, among other things)
• More importantly, it is runtime-resolved. That means you can expand Objective-C classes without breaking the ABI; in C++ you can't add members to classes, at all. Class members can be in different libraries, and in different header files (a "private" member is one not exposed in the API, but you COULD access it directly by defining it or including the header for it).
• The mangling in C++ is a serious pain and makes loading C++ libraries and programs retardedly slow.
• Swizzling (you can replace members of classes at runtime--not just inherit, but actually overload class members) makes the language quite a bit more flexible.
• Operator overloading and templates are an abomination, and don't exist in Objective-C.

We can all supply better languages for a purpose; Objective-C and C++ have the same purpose (an object oriented general purpose native compiled mid-level programming language), and so this comparison is relevant. Comparing to Java or Python or C#.NET would be irrelevant.

A loose argument can be made that Objective-C is better because of its much better polymorphism features--the main point of an object oriented language. Objective-C does indeed supply much more flexible, more useful polymorphism; C++ class inheritance is pretty rigid because of its rigid ABI. Objective-C's run time resolution enables this, and I would admit that run time resolution of class objects is a bit slower ... if it wasn't optimized by cache (i.e. resolve the first time on demand and build the PLT) AND if C++ class member mangling didn't make actually building the PLT at load time so god damn slow. Two points to Objective-C.

Objective-C doesn't have operator overloading. Operator overloading is often claimed as a negative feature because it makes code hard to read. The effective argument AGAINST operator overloading is is that everyone is used to the 'cout >>' and 'cin

The biggest argument for operator overloading is really that nobody uses it, so we're all familiar with the corner case syntax in the standard library. Think about that: the biggest argument for it is that it never gets used.

Also, Objective C has reference counting with cycle detectors and all. Garbage collection is a limited feature (you can create garbage collected objects intentionally).

It's actually relatively easy to argue that C++ is an abomination. It's not unexpected either: it's an old language, and an OOP shim hacked on top of a well-designed mid-level language. That C is so well designed is surprising; but then it is the legacy of assembly, PASCAL, FORTRAN, and BASIC. COBAL is circa 1959, BASIC circa 1964, C circa 1972, C++ circa 1984. C++ had only Smalltalk to learn from, really, and was trying to be C with Classes.

Re:One good reason...

[serviscope_minor]

*Value templates.

What are value templates? If you mean things templated on integers, then I respectfully disagree. I use some very nice small-vector/matrix linear algebra libraries which would be pale shadows of themselves without templating on integers.

*Diamond inheritance (just make it illegal)

Is it a big problem? I think I had a design once where it made sense, but I can't for the life of me remember even what the domain was.

The trouble with interfaces is that you often end up having to duplicate code because you can't pull in extra stuff like you can with inheritance.

*The entire algorithms part of the STL.

No way! I, for one like things like sort (and related), heap, nth_element (one of the very few language std libraries with this O(n) algorithm!), permute, random_shuffle, binary_search (and related), set_union (and related), min/max, min/max_element, equal, swap, and a few others.

for_each is pretty useless, annoying and unclear.

Many of the others are generally a bit more useful now with lambdas.

The algorithms part of the STL is one of my favourite things, and something I really miss when going to other platforms.

Kill either structs or classes.

I think that's pretty harmless as these things go. For program structure, I use class, since I want everything private by default (for encapsulation). For template programming, the public-by-default struct is useful for since one often has many tiny structs.

It's a small oddity, but it must add positively 5 or 6 lines to the compiler.

*The iostream libraries. I don't think I've ever seen code that didn't say fuck that and just use C style stdio. They're clunky.

Well, I like the type safety of the C++ library. The formatting stinks and is really painful to use. I ended up writing/finding a few helpers, e.g. ones that use printf style formatting (but with safety) where necessary.

I've actually got pretty used to it. I find having the variables inline in the positions they appear in the output now easier to follow than jumping between a format string and list of variables.

I agree that other languages are more bloated, but I think that if you removed any feature you would lose something significant.

Re:One good reason...

[betterunixthanunix]

what features you could therefore remove without detracting from the effectiveness of the language.

Exceptions -- I personally like exceptions, but exceptions in C++ are terrible and not necessary. C++ exceptions have the following problems:

1. No clearly defined exception type -- you could potentially catch something that has no descriptive string, no information about the stack, etc.
2. Double exception faults. This is a subtle problem but one that seems to be easier to trigger in C++ than other languages, and one that could be fixed by changing how exceptions are handled. For those who are not familiar, exceptions that propagate out of a destructor cause abort() to be called if the destructor was called as part of the stack unwinding process for another exception. If I wanted to call abort() when errors occurred, I would not bother with throw statements, I would just call abort().
   
   Incidentally, the problem here is the order in which things happen. Exceptions should be caught before the stack unwinding process, which guarantees that the handler will execute before another exception is called. This also allows for "restarts" i.e. the ability to resume execution from the point where an exception was thrown, which might make sense (e.g. for exceptions that indicate some non-critical function could not be performed, which should not prevent a critical function from completing).

I have also seen quite a few large C++ projects that simply ban exceptions, because they wind up creating more problems than they solve.

Re:One good reason...

[Tyler Durden]

The biggest argument for operator overloading is really that nobody uses it, so we're all familiar with the corner case syntax in the standard library. Think about that: the biggest argument for it is that it never gets used.

Also, Objective C has reference counting with cycle detectors and all

Smart pointers are used in C++ to take care of reference counting. And dereferencing a smart pointer is achieved by operator overloading "->" .

I can remember back when I was reading up on Objective-C about how at that time the counts had to be handled manually with "retain" and "release". My God did that look clunky when compared to the automatic handling of reference counts with RAII in C++. I'm not up on the new handling of Objective-C reference counting though.

Not familiar with how Objective-C does cycle detection. Can you provide a citation?

Re:One good reason...

[91degrees]

Operator overloading and templates are an abomination, and don't exist in Objective-C.

What's wrong with operator overloading? What if you happen to want a vector or matrix class, or a complex number class? Seems to be a limitation.

But, the nice thing about C++ is the RAII. Create an object on the stack, and the constructor is called. Function ends, object goes out of scope, destructor is called. Useful for locks. Can also implement timers, resource counting, and of your class is well behaved, you don't need to worry about resources.

Re:One good reason...

[stanlyb]

And don't forget, the only reason for Objective-C to have these features at run-time is also the only reason why Obj-C is 10 times slower than any other language.

Re:One good reason...

[serviscope_minor]

* It is a strict superset of C: C compiles as Objective-C (C++ doesn't, since structs have a different syntax, among other things)

I've never had trouble pulling C headers into a C++ compiler. Problems can exist, I suppose, but are very rare and easy to work around.

* More importantly, it is runtime-resolved.

Or, if you prefer, that's a huge disadvantage. It makes things very, very slow since all sorts of useful optimizations are not possible. If C++ used nothing but dynamic binding, I'd have to stick to C.

in C++ you can't add members to classes, at all.

That is a wart with C++. If you pimplify your classes properly, you don't break the ABI. Since it's such a common idiom, it would be really nice if there was compiler support to make it trivially easy.

* The mangling in C++ is a serious pain and makes loading C++ libraries and programs retardedly slow.

How so? The mangling gives functions funny long names, but they appear to the linker as just functions with long names, and behave the same way as C programs. I don't recall ever being bitten by this...

* Swizzling (you can replace members of classes at runtime--not just inherit, but actually overload class members) makes the language quite a bit more flexible.

That's a potentially useful flecibility.

* Operator overloading and templates are an abomination, and don't exist in Objective-C.

You made coherent arguments up to this point, where you basically revert to saying it's bad because you say so. If you use + to add ints and + to add floats in ObjC, then you aren't completely against overloading. Templates and overloading are two of the best features of C++.

I really don't see how compile time hackery (templates) is inferior to run-time swizzling in ObjC.

Without templates, there can be no good container libraries.

Without operator overloading, writing intuitive mathematics libraries (for example) would be impossible.

A loose argument can be made that Objective-C is better because of its much better polymorphism features--the main point of an object oriented language.

C++ isn't a objected-oriented language. It's a multi-paradigm language where object-orientation is one of the paradigms supported. You're ignoring all other facets of C++.

The biggest argument for operator overloading is really that nobody uses it, so we're all familiar with the corner case syntax in the standard library. Think about that: the biggest argument for it is that it never gets used.

On what grounds is that the biggest argument for it? I use it all the time. I use olperator> on streams. I use + to concatenate strings. I, personally use + to add all sorts of things (like ints, floats, Vectors, Matrices, automatic differentiation types, an occasionally complex numbers). I use operator= all the time to assign one container to another.

So, your point is basically wrong. I and many others use operator overloading all the time to do useful things, and make stuff clearer and simpler.

Also, Objective C has reference counting with cycle detectors and all. Garbage collection is a limited feature (you can create garbage collected objects intentionally).

C++ as they say doesn't need garbage collection as it produces very little garbage. Garbage collection is very nice when you have long lived mutable cyclic datastructures. For all other cases, the arguments for and against are much more subtle.

Personally, I fund deterministic destruction useful. I find it much easier to run out of memory in Java compared to C++ when dealing with large datasets.

It's actually relatively easy to argue that C++ is an abomination.

I beg to differ: you have been unable to argue that so far.

Re:One good reason...

[serviscope_minor]

C++ is an excellent language and a bloated obscenity at the same time.

OK, I'll accept that. It sucks, but less so than all other competing languages. Just like operating systems really.

Re:One good reason...

[AuMatar]

Value templates- yes, templating on the value, rather than the type. It's an extremely niche use case that causes difficult to read code and provides little in the way of benefits. I doubt even 5% of the user base knows it exists. Kill it.

Diamond inheritance- it isn't used much, but when it is it's a problem. Because you don't know when the common base class will be initialized, or which constructor will be called by what values. Make it illegal to solve those problems (or add it to the specification)

STL algorithms- sorry, totally disagree. The entire thing is a horrible hack based on using constructors to make quasi-first order functions. They were never meant to work like that. At best it's confusing, at worst it's unreadable and hard to debug. I bounce any code review I see using them. Worse, it encourages people to make more code like that, which tends to be done worse and be even more unreadable and frequently just wrong (generic programming has a lot of gotchas). I'd rather see the whole thing killed.

Structs vs class- it is pretty harmless, but we're talking bloat. It's bloat. There's no reason to have both. I wouldn't say this is something that has to be fixed, but it's silly to have the two of them.

Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.

Re:One good reason...

[serviscope_minor]

There are problems with C++ exceptions (there's a current thread on comp.lang.c++.moderated about double faulting.

I would agree that they're a long way from perfect, but they capture probably 99.9% of the use cases perfectly. You can always not use them for the other .1%. Most of the time they ensure that resources are freed when an error occurs without the need to write lots of tedious and error prone error checking code.

Organisations that ban exceptions are frankly being silly.

You do mention that one problem is a lack of stack information. The trouble is that keeping the stack in tact would seriously hobble the optimizer. After a few passes of inlining, code deduplication, loop unswitching, common subexpression elimination and scheduling, there is, at best a rather tenuous relationship between the generated code and what shape you think the stack ought to have.

Re:One good reason...

[serviscope_minor]

Value templates- yes, templating on the value, rather than the type. It's an extremely niche use case that causes difficult to read code and provides little in the way of benefits. I doubt even 5% of the user base knows it exists. Kill it.

I think you are underestimating the number of people who use it indirectly.

I'm in the 5% who use it directly, and it is an invaluable tool which gives C++ a massive advantage over other languages. Otherwise, it is very useful inside metaprogramming, which is the key to making easy to use (not easy to write) libraries.

Besides how is it hard to read?

STL algorithms- sorry, totally disagree. The entire thing is a horrible hack based on using constructors to make quasi-first order functions.

I'm not entirely sure I follow. How do constructors enter into it?

I bounce any code review I see using them.

What do you use to sort data? What do you do when you want a heap, or want to perform a set difference or some such operation?

Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.

So, you would have (presumably) type generic container classes?

 

Re:One good reason...

[betterunixthanunix]

Most of the time they ensure that resources are freed when an error occurs

Except that freeing resources might cause an exception to be thrown (see, for example, the fclose manpage; note the number of errors that fclose might return, and now imagine exceptions being thrown for those errors), which is seemingly innocent (after all, it is an error case) but which is practically guaranteed to create a double exception fault if any destructor fails to catch all exceptions.

Organisations that ban exceptions are frankly being silly.

Not really; I have heard several software engineering researchers say that exceptions are the completely wrong approach for high-integrity software, and that the right approach is to use return values and to mandate that something be done with the return value. Even without the problems with C++ exceptions, the entire design of exceptions is problematic -- your program basically branches to some totally unknown place, and the only way to figure out where that place is is to actually throw an exception (compare with overridden methods in objects, where you can determine what method will be invoked by checking the object type). I personally disagree and think that exceptions are a more pragmatic way to handle things, since we cannot all sit down and write proofs of correctness for all of our code, but these guys are experts in software engineering, so their opinion is at least worth considering.

The trouble is that keeping the stack in tact would seriously hobble the optimizer. After a few passes of inlining, code deduplication, loop unswitching, common subexpression elimination and scheduling, there is, at best a rather tenuous relationship between the generated code and what shape you think the stack ought to have.

Which is solved by resolving the exception handler before destroying the stack. When that happens, I can just examine the stack exactly as it was when the exception was thrown. It also allows the exception handler to make a decision about whether or not the stack should be destroyed i.e. allowing the program to continue execution from the point where the exception was thrown.

Re:One good reason...

[serviscope_minor]

The compiler neatly destructs if for you and cleans up all the resources. It's very nice, you should try it sometime.

Re:One good reason...

[Short Circuit]

Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.

So do it. You wouldn't be the first person to create a language more to his liking, believe me. I've seen dozens, if not hundreds, of programming languages which originate from a developer liking some features of another language, but disliking others.

You clearly have strong opinions; stop writing essays and start writing code! (Or write essays to form a spec, and then code. I see that, too.)

Re:One good reason...

[AndrewStephens]

Nobody uses everything in C++, I estimate that most programmers only ever use 75% of the language. The problem is that everybody uses a different 75%. For instance, diamond inheritance can be a pain, but is occasionally unavoidable and I am glad it works. STL algorithms are the best part of C++, complex problems reduce down a few lines of code.

Your one example that is actually bloated is iostreams, which is slow and overkill for almost any program. I wish more C++ text books would ignore iostreams and spend more time on STL.

Re:One good reason...

[Darinbob]

Macros aren't really outdated. Maybe 95% of their uses can be replaced with enums or inline functions, but there are also times where textual substitution can do useful things.

Templates as a whole are overused and lead to problems, and in particular tend to not co-exist with object oriented styles. Small simple templates I like, but I see them used to completely replicate a data structure which leads to bloat. And the bloat in C++ is not bloat in features as you sort of imply but bloat in the immense size of the executable. Templates really are just a style of textual substitution, except that unlike C macros this is hidden from the programmers who often don't realize how much extra space can be taken up by them if they're not careful. I don't think there are any compilers yet smart enough to determine when two template instantations only needs one copy at run time, and you end up with standard "libraries" where most of the code is in a header file and recompiled often. To be fair you can use templates that do some nice libraries (ie datastructures store void* and the templates just do the type safety checks for you before casting), except that this is contrary to the STL style. I used to like the rogue wave libraries myself.

You need structs in C++ to be compatible with C. One of C++'s goals is to compile proper C programs and keep compatibility where possible. But if you got rid of the class keyword instead you'd have a revolt. So the typical style almost everyone uses is that struct is used as a plain C struct only, and if you need anything beyond what C can do then you use a class instead. What C++ should have done I think is to enforce that style.

I agree, iostream is awful. Originally it wasn't too bad in some ways and early on it did a good job of adding some extra type safety to IO. But it always felt like a bit of a kludge. It is nice to have a more generic output destination like a stream buffer but it came saddled with the operator overloading and you needed to know implementation details to do a lot of useful stuff.

Diamond inheritance is a side effect of C++ never being able to say no. It should have just said "no multiple inheritance". Once it did have mutliple inheritance it should have not allowed the cross pollenization and stuck to a style where multiple inheritance had only mixins or interfaces. But they didn't want to say "no" and figured that they could use a keyword so that the user could do what they wanted. Which resulted in a lot of confusion.

Actually Ruby is a relatively simple language. A good job of making a textual style of Smalltalk (only with a horrible kludge of blocks). The bloated part may be the Ruby on Rails which is not the same thing at all. Ignoring libraries and looking just at the syntax/semantics of the language then Ruby is much simpler than C++.

Re:One good reason...

[UnknownSoldier]

I used to work with a team that produced a professional C/C++ compiler. We used to joke:

There are two problems with C++
1. it's design
2. it's implementation

As a programming I've come to love the sweet spot 1/2 between C and C++.
C leads to overly terse code
C++ leads to over-engineered solutions

Its too bad the preprocessor is still stuck in the '70s :-( Every year C++ is slowly turning into a clusterfuck LISP implementation by people who don't understand how to write a safe macro meta-language.

Re:One good reason...

[Anonymous Coward]

There needs to be a Godwin's Law corollary for MS Bob.

Re:One good reason...

[GauteL]

When it comes to STL algorithms, you may have been right before C++11/C++0x. Now, with lambda functions, the standard algorithms are genuinely brilliant. Modern IDEs should support debugging the lambdas as well.

I honestly don't care if you disagree. There are enough people around that use them extensively and they are not going away. I would most likely bounce your code your code for NOT using STL algorithms if they were the quickest solution.

I completely agree on struct/class and diamond inheritance though.

Re:One good reason...

[shutdown -p now]

A loose argument can be made that Objective-C is better because of its much better polymorphism features--the main point of an object oriented language. Objective-C does indeed supply much more flexible, more useful polymorphism; C++ class inheritance is pretty rigid because of its rigid ABI. Objective-C's run time resolution enables this, and I would admit that run time resolution of class objects is a bit slower ... if it wasn't optimized by cache (i.e. resolve the first time on demand and build the PLT) AND if C++ class member mangling didn't make actually building the PLT at load time so god damn slow. Two points to Objective-C.

All well and good, but increased dynamism of Obj-C also means that it is that much slower - if I remember correctly, any Obj-C message dispatch, even in the best case (i.e. directly handled by the object), is still several times slower than a C++ virtual method call - and most method calls in C++ aren't virtual, and are typically inlined.

Operator overloading and templates are an abomination, and don't exist in Objective-C.

Operator overloading is arguable. Every time you have to write something like a.add(b).multiply(c) in Java when working with, say, BigDecimal, you understand why operator overloading was invented. On its own, it's definitely a good feature - it lets you offload a bunch of language semantics to the library. The only harm comes from its misuse, but that is true of practically every language feature.

Templates aren't even arguable. Due to their lack, Obj-C still doesn't have proper typesafe collections. You could argue that templates are poorly designed in C++, and that something like C# generics would be better, but that again is an issue of convenience vs performance. C++ templates have the advantage of, ultimately, being a lot like turbocharged macros - the code that gets compiled in the end is what you'd write by hand after substituting all template parameters, and so it's just as fast. Templates are what makes C++ std::sort faster than C qsort.

Also, Objective C has reference counting with cycle detectors and all.

Obj-C with ARC does not have cycle detection. You have to use weak references to avoid cycles, or otherwise break them up manually.

C++ has all the same stuff (shared_ptr / weak_ptr), except you decide whether to opt in or not for every object you allocate, and so you don't pay the penalty for every single one. Why would I need to refcount an object that is allocated in a function, and destroyed when it returns?

That C is so well designed

Are you serious? #include, insane declarator syntax, struct/union/enum tags, the way it treats mixed signed/unsigned arithmetic, implicit cast from void*... C has so many warts it's not even funny. The only good thing about it is that it's very low level and it exists on every platform, making it a "portable assembler".

C++ had only Smalltalk to learn from, really, and was trying to be C with Classes.

C++ has practically nothing to do with Smalltalk. It's actually C with Simula-67 slapped on top (where do you think "virtual" came from?).

Re:One good reason...

[eruci]

i love C and Perl. for two opposing reasons.

Re:One good reason...

[bstamour]

Value templates can be great. Have a look at std::array. Under the hood it's just a static C-style array (take a look at the generated assembly, on a decent compiler there's zero added overhead), but it remembers it's size as it's baked into the type itself. So it gives us all the speed of a C-style stack-allocated array of N items, plus removes the hassle of having to pass the size around as an extra parameter to functions. Finally, if you really want to be safe, you can use the .at( ) member function for range-checked access. The operator [ ] is overloaded of course for direct access, in case you need that too. This functionality would be impossible without the ability to use std::size_t as a template parameter.

Re:One good reason...

[serviscope_minor]

I don't think I am. Take a survey of average C++ programmers who don't work directly with you on that type of code. See how many of them know they can do that. I actually think 5% is an overestimate. And if that small a percentage actually know about and use a feature, I question how much that feature is worth. Especially when it at best offers a miniscule speed boost over just passing in the number as a parameter.

Several points:

Expert-friendly language features enable the creation of better libraries. Library users might not even realise that they are using the advanced features. That doesn't make the advanced features worthless.

Having fixed sized linear algebra objects yields massive speed increases, not tiny, since the compiler is able to sue stack allocation (which is essentially free) which is vastly faster than malloc/free. Secondly, the optimizer seems much better able to reason about stack allocated objects, giving another large speed increase.

At best, the speed increase is well over a factor of 10, and I have verified this with benchmarks.

Functors are implemented by overriding the constructor of a class to preform an odd type of initialization and then overriding the operator () to do computation.

I think functors just (in general) overload operator(). Nothing special is necessarily done with the constrtuctor.

It's an ugly, difficult to understand hack. It completely destroys the idea of what a class is,

I don't see how: a class is an aggregation of methods and members. C++ allows you to use some OO features with classes if you like, but it isn't necessary. What would you prefer?

Can't say I've ever wanted to perform a set difference. But if I did, there's be a method difference in the class Set, and it would take the second set as a parameter and spit out the result.

OK, so how do you store elements of the set?

What I'm driving at is that in C++ set_difference, etc work on any ordered collection of things. The advantage is that you can choose the container for the collection based on the algorithmic properties you desier (array, RB-tree, linked list, etc).

Same with a sort- the class would have a sort function. I would reluctantly not bounce using the sort function of the STL since it's so useful, but it's still not the right way of doing things. And it's much more complex than it should be, since the calling code has to worry about things like passing in comparators, when that should really be the job of the sort function.

So, every container class needs to have it's own sort function? If so, then they would likely share a lot of common code. Is that whay you propose?

Re:One good reason...

[roky99]

It's clear that you don't really get a lot of this stuff. Despite that, you seem to be in some position where you can review and reject other people's code. Your remarks would be hilarious if I didn't think you were serious. For example:

Can't say I've ever wanted to perform a set difference. But if I did, there's be a method difference in the class Set, and it would take the second set as a parameter and spit out the result.

The whole point about generic algorithms is that you only have to write them once and can then use them with all sorts of containers, including ones that might not have been written yet, as long as the containers satisfy the minimal requirements of the algorithm. So for example, the 'set' in set_difference does not refer to the container type - it is a description of what the algorithm does. The algorithm does not demand a set; you can equally apply it to a sorted vector. Furthermore, the two input sequences to set_difference do not even have to be the same type as long as their elements are compatible, so I can apply it to a set of strings and a sorted vector of strings if I want to. By your argument, I would have to have a set class with a difference method, and a sorted vector class with a difference method. And then if I wanted set's difference method to work with sorted vectors and other compatible sequences, how would that work? I would have to write it as some sort of generic member function anyway.

Same with a sort- the class would have a sort function. I would reluctantly not bounce using the sort function of the STL since it's so useful, but it's still not the right way of doing things. And it's much more complex than it should be, since the calling code has to worry about things like passing in comparators, when that should really be the job of the sort function.

So what you are saying is that instead of having a sort algorithm implemented once, I need to reimplement that algorithm in every class that I might want to sort. So either I guess that I might want to sort it at the time of writing it or, if I didn't get that right, I have to go back and modify the class. Compare that with the non-intrusive sort algorithm. How is what you are proposing good software engineering practice by any stretch of the the imagination? And I don't understand your point about comparators. In most cases a type you want to sort probably defines a less than operator, which is all you need and you don't need to provide an explicit comparator. It's only when you need to do something special that you need a comparator. How would the sort member function be better?

Here's a hint: go and look up the word 'orthogonal'. It's a key concept in understanding the STL.

Re:One good reason...

[jc42]

C++ virtual method call 1.1 ns
Objective C message send 4.9 ns

4.9/1.1 ~ 4.5 times slower.

I don't know where you're getting 10 times slower from.

It's called an "order of magnitude" estimate. 4.5 differs from 10 by less than a factor or 10, so they're the same number.

It's a very popular method of estimation among people who don't care for precision. You should try it sometime; it's fun. You can get geeky types who know the numbers really upset with you, while management types are giving you approving smiles. But you do seem to have "cherry picking" down pat, so you're well on your way to a career in media/political/management abuse of statistics. You just need a few more deceptive techniques in your portfolio. If you ask nice, there are lots of people here who can help you.

Re:One good reason...

[Deorus]

It always infuriated me that most C++ compilers will happily accept printf() as valid.

Most of C's standard library is part of C++'s specification. That function in particular is defined in <cstdio>, so compilers accepting it are conforming to the standard. This is not to mention that there are actually certain manipulators that stdio accepts and iostream does not, such as the precision manipulator for character strings which limits the amount of data read from character string buffers (C99). Also don't even get me started about the real bloat that iostream actually is. If you've never implemented a custom streambuf, please by all means do it and see for yourself.

Re:One good reason...

[GauteL]

Lambdas are generally used to replace functors syntactically, but what I meant was STL algorithms, a set of standard templated methods that can be used on STL conforming data structures (either built in, or your own, as long as they you implement some basics such as iterators).

If used properly, you can achieve some things nearly as quickly in C++ as you can with higher level languages. However, before lambdas you had to use a lot of functors to use them, which limited their elegance.

Maybe because it compiles down to the metal...

[skids]

...and not some VM? Most of the popular languages these days are all dynamic. And they are very convenient and nice. But if you actually want to know what the machine is actually doing, and want to have a say in such things, C is the way to go.

I mean, unless you want to, you know, use pascal or fortran or something.

Re:Maybe because it compiles down to the metal...

[interval1066]

Although possible, and done, I have a hard time thinking of good reasons to write drivers in higher level or interpeted languages. Besides, most kernels are written in C, makes sense to write drivers in C. When some one trots out a kernel in Python then I'll jump on the systems work in python bandwagon.

Re:Maybe because it compiles down to the metal...

[slew]

...and not some VM? Most of the popular languages these days are all dynamic. And they are very convenient and nice. But if you actually want to know what the machine is actually doing, and want to have a say in such things, C is the way to go.

I mean, unless you want to, you know, use pascal or fortran or something.

Although "C" compiles down really very close to the metal, so does "C++" (and a host of other more modern languages). However, it's not that easy to take that next step to the metal. In between is a machine that virtualizes the registers (using register renaming techinques), virtualizes the memory (using difficult to predict caching, translation, and ordering operations), and reorders the instructions (speculation, branch target hiding, etc), and runs in a sandbox (under the os which is timeslicing between tasks and faulting and swapping in memory translations and maybe even simulating some instructions).

Knowing what the machine is actually doing is often a mythical quest down the rabbit hole. Although I'm a big fan of "C+" (what I call the c++ subset that doesn't have all the crapola that I don't use**), I'm under no illusion that all you are really doing with C is using a more predictable translation strategy (e.g., static compile time translation) rather than some magical "metal" commanding language.

** +objects, +const, +templates, +-stl (some are okay), -overloading, -virtual inheritance, -rtti, -boost, etc...

Re:Maybe because it compiles down to the metal...

[Penguinisto]

Even better - it allows you to actually make the results efficient. While most CS grads these days likely expect hardware tech to keep up with the bloat, there are a few folks out there who know what it's like to economize like hell when it comes to CPU or memory.

Also, when you're seriously pushing limits, it's the performance difference between a 1982 Chevy Nova with a busted head gasket (.NET, I'm looking at YOU), and compiling yourself a Porsche 911 with all the Autobahn goodies included.

Re:Maybe because it compiles down to the metal...

[c 0xFF]

+templates implies +overloading

For example: the STL iterators use the same interface as pointers, which then lets you use templated algorithms that can accept an STL iterator or pointers into an array.

Another example: your templated function needs to call fabs() on some variable of type T. Overloading lets the compiler pick the right one, even if it's a user-defined type.

Overloading doesn't deserve the bad reputation. As long as you use it as a tool for specific reasons, it's wonderful to have. The most commonly-cited problem people have is when people overload operators (although this problem extends to any overloaded function) to do weird and unexpected things. Fortunately, this problem is discussed enough that it's rare to see someone do bad things with overloading.

Re:Maybe because it compiles down to the metal...

[ByOhTek]

That, and because of that, you can easily import a C library into any language without having to worry about compiler used, or bullshit like that.

I have a C library. I can dynamically import it into C, Python, Java or C# fairly easy, on any platform, I don't even have to compile the library or have the same compiler. Want to do that with any other language (including C++)? You are in for some pain and suffering.

Re:Maybe because it compiles down to the metal...

[c 0xFF]

One of the best features about C++ is that you can define your own subset that you'll use. Don't want to use RTTI? Then don't! Worried about exception handling? Then don't use them! This is why C++ can never be slower than C -- in the end, just reduce that subset until you get to C and you're done. Beware, though, some of the features you just left out might actually improve performance over the C equivalent!

However, this subset has to be defined on a project basis, and not left for individual programmers to decide for their own code.

Re:Maybe because it compiles down to the metal...

[lgw]

These days Java runtime bugs and security issues take up a significant portion of my time. There's no real advantage to "knowinf what the code really does" to be found in a modern hugh level language, because the VM isn't perfect, and anything short of perfect means you have to care aout that layer. And you don't have soruce for that layer, or an easy way to inspect it. Whenever I was a bit uncertain what the compiler would do with oddball corner-case code in C or C++, I could fire up the debugger and check the generated object code, achieving absolute certainty what was really happening.

Wait till you have to debug your first memory leak in Java or C# - you'll be singing a different tune after that. At least in C, when a third-party API leaks memory you have all sorts of object-level tools available to get to the bottom of the problem, even without source. Bump into a JVM or CLR leak? Sucks to be you.

Re:Maybe because it compiles down to the metal...

[skids]

To make auditing easier.

Ehm... auditing dynamic languages at the level required for driver-level security is nearly impossible. No there are no dangling pointers. What there are is race conditions between the cleanup of the casually discarded memory item and it's availability for re-use. Churn in the underlying VM can change the consitency of lots of such behaviors without your code ever changing, so there's another headache. Add to that that almost all drivers for anything beyond a USB gadget are going to have to, mandatory, do some pointer arithmetic, deal with endian-swapped values, and deal with the differences between signed and unsigned fixed-width integer values, and it just makes the very idea of using a "modern" language for drivers threatens the sanity of anyone who ever wrote a production-worthy driver.

Re:Maybe because it compiles down to the metal...

[hxnwix]

> How do you add two ints? How about two floats? Why is overloading bad?

Add the string "0.5" to the string "1.0." with the '+' operator. Is the result "1.5" or "1.00.5" ?

Is there an easy way to find out based on the syntax of the language, or do you have to dig into the class libraries you're including which may contradict each other?

Always "1.00.5" unless you or one of your includes declared some extremely evil operators.

Because they can lead to surprising behavior, c++ operators are usually defined with care so that they won't be accidentally invoked and don't do strange things when they are used (such as interpret strings as floating point values).

Re:Maybe because it compiles down to the metal...

[skids]

While I agree to some point that processors do a lot of funky things these days, C is a pretty solid demarcation point for well-defined behavior that gets you close enough to the metal to do most of what you need to do down there. It's close enough that you can do some amount of optimizing for different CPU families, but not so close that you cannot write the majority of your code generically without worrying about performance.

As to C++, it isn't just a pretty C. It may not have a VM but it does some pretty messed up stuff to implement OO calling conventions. C's function calls are implemented much more directly and predictably. You can be pretty sure all that is going to happen is a few stack pushes, rather than going dawdling around hashes of function signatures looking for a candidate because somehow a virtual got mixed in there. WIth C++ you have to get pretty affectionate with your compiler to know what features you can use, and how, without the whole pile of OO bricks falling on your head.

(WRT branch prediction, It is the case today that CPUs have been optimized so much to run spaghetti code effeciently, that it has started to behoove some VM/compiler authors to write purposfully spaghetti-like code to take advantage of these accelerations. I find that rather ironic.)

Re:Maybe because it compiles down to the metal...

[skids]

I think the problem these days is an entire generation of coders who have never in their life experienced a UI that was actually so repsonsive that it was impossible to ever perceive a delay between your keystroke and its effects. They've been raised entirely on laggy windows textboxes and mouseclicks that just migt get around to doing something anytime now.

They don't even know how slow their kit is running. They've never seen one run fast. So they consider similar results satisfactory when they write code.

Re:Maybe because it compiles down to the metal...

[Khashishi]

It's not about compiling close to the metal. It's about thinking close to the metal. With c, I can usually follow what the computer is doing by scanning through the lines of code. With c++, I can't. More things happen at instantiating an object or at the closing brace of a function than in the body of the function, and I have no idea what order things are being done in. With more abstraction, it's easier to see what the programmer intended a program to do, but it's harder to see what the program really does.

Re:Maybe because it compiles down to the metal...

[lgw]

Yes, we've all heard that refrain: "mange code mens no memory leaks"; it's very last-century. Some of us on /. do this coding thing for a living, you know. That's not what I was talking about.

There are memory leaks in the JVM itself. There are memory leaks in the CLR itself. Trust me, it really sucks to be stuck with one of those! Very hard to find and work around whatever's leaking, and you have no leverage at all over the vendor to get the leak fixed.

And, you know, I never had a memory leak in my own code in nearly 20 years of assembly and C++ coding; not because I'm some rock star, but because there are reliable techniques to avoid them. It's harder in C: with the need to match acquire and release in every function, there will always be some human error creeping in. But with good coding standards it's a trivial problem with modern tools.

Re:Maybe because it compiles down to the metal...

[HarrySquatter]

Funny because Minecraft is a Java program notoriously bad at leaking memory and throwing null pointer exceptions. Maybe if he would have written it in C++ it would at least not be a slow, bloated hog?

Re:Maybe because it compiles down to the metal...

[lgw]

The C#/.NET library code that "marshalls" objects when converting to/from unmanaged code uses COM under the covers. COM is indeed the devil - if anything needs to be given the baby seal treatment ...

Otherwise, yeah, proper discipline around IDispose/using does wonders - but then, so does proper discipline around "what you acquire at the top of the function you must release at the bottom of the function" in C.

Java is worse because it doesn't have "using" block or IDispose, so you get more boilerplate code, and therefore risk of human error with handle/resource leaks (of course, they're released eventually by garbage collection, but that just makes figuring out why that file/object was locked that much harder).

Re:Maybe because it compiles down to the metal...

[cerberusti]

Diagnosing and fixing memory leaks is in fact trivial. Not only are there very good tools to tell you what is leaking, but it is extremely uncommon for someone to make this kind of mistake if they are an experienced C programmer.

If this is a real problem in your code, it probably means you have too much code dealing with memory management. This is almost always a result of being a new programmer (or at least new to having this kind of control.)

Good habits

[Bucky24]

Personally the thing I like most about C is that it's not "safe". It doesn't take care of a lot of memory management for you and you can easily eat up all the memory or introduce a buffer overload vulnerability if you're not paying attention. It forces programmers to actually look at what they're doing and consider what it will do in the long run, and causes good coding habits to form. I think the majority of people who dismiss C as "too hard" are coming from Java programming. C gives you a lot of power, but, as the well-cliched saying goes, "with great power comes great responsibility".

Re:Good habits

[localman57]

Exactly. My company does a lot of different things from embedded systems to web interfaces, and, generally speaking, the C guys write better Java code than the Java guys write C code.

Re:Good habits

[jmsp]

> It forces programmers to actually look at what they're doing

OMG! There. That's where all the hate comes from.

--
(Programming in C since 1984)

Re:Good habits

[jellomizer]

Problem is the diligence that is required. A C developer is a really good coder when they do their work in an other language. However for large projects, C doesn't make too much sense, because you need to expect your developers to be on their A Game in the course of the project. A developer is porting their proof of concept code into production, right near lunch time, and he is starving, and some of the other guys are waiting on him to finish up, because they are starving too, might mean some code got copied in, and put into the production set, without full though. Because the Proof of Concept code worked, it may pass many layers of Quality Check (and we all know most software development firms have very poor QA teams) Once it leaves and goes to the customer, it could be wide open to a security problem.

Every Developer thinks they are the best developer on earth about 50% of them are actually below average. C is a great teaching tool, I wish most colleges still used it, and didn't switch to .Net and Java. However once you go into production, unless you really need the C performance (and you can code highly optimized C) going with other Languages that are a little more protected is a safer bet.

Hire a C developer... Give him a higher level language, and you will probably get really good code.
Hire a C developer have him program C, you are setting up a time bomb, where once they miss a beat you are screwed.

Re:Good habits

[ShanghaiBill]

the C guys write better Java code than the Java guys write C code.

My experience is that the C guys (and gals) often write better Java than the Java guys write Java.
Programmers who have never written in C (and/or assembly) often have a poor understanding of how computer actually work.

Re:Good habits

[Raenex]

It forces programmers to actually look at what they're doing and consider what it will do in the long run, and causes good coding habits to form.

It forces programmers to spend a lot of time thinking about low-level issues. As an example, anybody who has done string manipulation in C versus Perl (or Python, etc.) knows what I'm talking about.

Rather than patting themselves on the back about how they manage to work with a high-level assembler, most developers want to use productive tools and can afford to sacrafice some memory in exchange.

Re:Good habits

[ArsonSmith]

of course, programing in C is experience while programming in Java is idle waste.

Re:Good habits

[ShanghaiBill]

I thought one of the major selling points of C#/Java was memory management.

Java has automatic memory management, and it works well most of the time. But it doesn't work so well if you have cyclic references (it can detect some, but not all cyclic references) and it will not free up references to unused memory that happen to be tucked away in persistent data structures. These are easy to deal with if you understand why these cases happen. Good C programmers are trained to recognize these situations. Java programmers are trained to think memory management is "magic".

Do they have tools like valgrind for Java/C#?

Some who has never learned to manage memory manually with malloc/free, is not going to see the need for these tools, nor understand how to use them.

Re:Good habits

[Alamais]

Having recently had to learn TI assembly to do things on some strangely designed DSP boards, I really do think it should be more widely taught. Memory management takes on a whole new meaning once you've had to fit your program (data acquisition and FFTs) and data into one shared 10kword RAM block which has some hardware-reserved blocks and various alignment requirements. I had plenty of conceptual understanding of how computers worked beforehand, but now things like shared busses, registers, stacks, addressing, interrupts, etc. have much more direct meaning to me, and I feel a lot more grounded even when coding in higher-level languages.

...Not to mention I feel grateful now that I don't often have to use ASM.

Re:Good habits

[Xiaran]

I've come across worse than this. I have encountered java only developers that think *everything* is managed in java. So database connections don;t need to be closed as I was told by one young developer... while trying to figure out why the Notes DB he was connected to was periodically failing due to it running out of connections.

Who made that question?

[Anonymous Coward]

A web developer?

C is the the best tool around for low level programming. It allows very high levels of abstraction and it keeps you very close to your architecture's features.

FORTH and C++ are used to the same means, but I do not hear much about other tools being used for this kind of development.

Re:Who made that question?

[TheSpoom]

I'm a web developer and the question was equally stupid to me. Hell, I know OkCupid runs just about everything in C or C++ (or did, not sure about now), mostly as they do an insane amount of mathematical calculation and need it uber-optimized.

Control

[Dan East]

C offers control. If you can't handle having that much control (over memory, how the CPU acts on that memory, etc) then your software will have many problems and you will hate C.

Re:Control

[jythie]

Not just control, but predictability. C does exactly what you tell it to do and you can see what it is doing more easily then other languages. You can tell C++ to do 'X', but it might slip in a 'Y' and 'Z' without telling you.

Re:Control

[Anonymous Coward]

That's BS. C++ isn't going to "slip anything in." Its standard has pretty much the same rules of predictability that C has.

Re:Control

[Raenex]

C does exactly what you tell it to do and you can see what it is doing more easily then other languages.

Thanks for the laugh. C is absolutely full of either undefined behavior or implementation defined behavior, by design. On top of that, it has this mantra of "trust the programmer", which in reality means don't help the programmer out, so they often end up in undefined territory by making simple mistakes.

Re:Control

[Thiez]

C, predictable? Would you mind taking this http://blog.regehr.org/archives/721 quiz? It's about the predictability of integers in C.

Re:Control

[ADRA]

C is the manual transmission of cars, its a lot harder to operate, but you have a lot more control of how it drives. More managed languages are the automatic transmission. For 99% of the time, it'll get you to where you're going just fine, but will waste a little more gas to do it. Standards are more efficient and auto's are more simple.

To further expand the analogy, the new world order of standard transmission is to move into dual-clutch manuals, where you can still twist the knobs if you really want to, but you don't need to; everything runs automatically behind the scenes. Now to put this into a programming language paradigm, its something like making the C#/Java runtime's of the world so efficient that they're (pre?) runtime optimizers become so efficient at optimizing the codepaths that they produce better results than a typical C output. The runtimes are surely not there yet (for most cases), but in 20-30 years, I doubt there will be many pure C developers left just as there are almost non-existant need for assemby programmers in today's market. Jas in cars, the dual-clutch systems will become so cheap and so convenient that you won't find pure manuals in all but the most specific niche markets in well, maybe the same 20 years.

Re:Control

[Khashishi]

Ah, but this is an advantage of c. Things are left undefined because defining them would impose a performance penalty in hardware implementation.

The portable assembler

[heson]

Close to the metal but still not specific to any machine if you do not need to. Easy to understand exactly what machinecode the compiler will produce.

Not a "Nanny State" language...

[Anonymous Coward]

You have to know what you are doing when you C and you can do anything...

Sesame Street already covered this

[Zephyn]

It's for cookie.

That's good enough for me.

Shorthand for Assembler

[codefool]

The power of C is - and always has been - that it is a shorthand for assembly. It compiles very small and runs very fast, making it ideal for embedded systems.

Think of it as standardized assembly programming

[localman57]

C is going to stay around for a long time in embedded systems. In this environment many microcontrollers still have 4k or less of RAM, and cost less than a postage stamp. In these systems there is virtually no abstraction. You write directly to hardware registers, and typically don't use any dynamically allocated memory. You use C because, assuming you understand the instruciton set, you can pretty much predict what assembly instructions it's going to generate and create very efficient code, without the hassle of writing assembly. Aditionally, your code is portable for unit testing or, to a lesser degree, other microcontrollers. This allows you to write a program that will run in 3.2 k of ram, rather than 4k, which allows a manufacturer to save 4 cents on the microcontroller they pick. This saves you $40,000 when you're making a million of something.

Re:Useless submission.

[chemicaldave]

If you're not a developer then you don't care about the nuances of C.

Where'd the Unix go?

[burdickjp]

It's not dead because all of your VMs and interpreters have to interact with SOMETHING, and that SOMETHING has to be written in a low-level language. I strongly believe in using only the lowest-level language necessary for the job, but for OS development that's C.

Simple.

[Short Circuit]

Tons of people love to have something to hate. It might be because they don't like something about it...but I think it's mostly because people like to set up communities held together by rhetoric against a tool or technology perceived and portrayed as an enemy.

"C++ sucks. We are at war with C++. We have always been at war with C++.[1]"

Swap out "C++" for whatever language you like.

Certainly there are going to be cases and scenarios where C is preferable over C++, where C++ is preferable over C, or where Brainfuck is preferable over either. Use the right tool for the right job,[2] and the right tool is whichever allows you to most effectively achieve your goals.

[1] Or, at least since its inception. Or since [insert arbitrary date here].[3]
[2] For whoever asks "what's the right job for Brainfuck?" ... just wait. Someone will eventually come along and get modded +2 Funny when they reply to you.
[3] I see what you'll do there, Mr. Connor.

Re:Simple.

[localman57]

Repeat after me: C++ is not equal to C

Wait. Did you mean equal "=", or equal "==" ?

Re:Simple.

[Short Circuit]

assert(C == C++);

Beautiful. Someone needs to prep an April Fools joke for next year for renaming C++ to ++C.

simplicity

[roman_mir]

C is a very simple language and yet it allows operating memory directly in a way similar to assembler. C is portable (well, it can be compiled for different platforms), I rather enjoyed the language a while back, but since about 98 I use Java for most of big development and I am pretty sure that if I had to do everything in C that I did in Java, it would have taken me much more time.

C is nice in another way - it allows you and in some sense it forces you to understand the machine in a more intimate way, you end up using parts of the machine, registers, memory addresses, you are more physically connected to the hardware. Java is a high level abstraction, but then again, to write so much logic, it is just better to do it at higher level, where you don't have to think about the machine.

C is great tool to control the machine, Java is a great tool to build business applications (I am mostly talking about back end, but sometimes front end too).

So I like C, I used to code in it a lot, but I just to use it nowadays. What's to love about it? Applications written in it can be closely integrated into the specific OS, you can really use the underlying architecture, talk to the CPU but also the GPU (CUDA), if I wanted to use the GPU from a Java application, I'd probably end up compiling some C code and a JNI bridge to it.

C teaches you to think about the machine, I think it gives an important understanding and it's faster to develop in than in Assembler.

Re:Useless submission.

[Anonymous Coward]

If you're not a developer then you don't care about the nuances of C.

Of course. Curiosity is a bad thing. You should stick to what you already know, and never try to expand your knowledge beyond your field.

As beginner programmer...

[bman49er]

...I'm looking into learning more C from an embedded perspective. A lot of Arduino libraries are written in plain C and I'm venturing to learn more about it to write my own libraries and/or edit libraries that come into conflict with others. And if you're wanting to go outside the usual Arduino chip sets (mega328, 168, etc) then it looks like C is the way to go.

Re:because -

[19thNervousBreakdown]

That's because there is no difference! I think you meant:

char* const foo;

for the second one. const modifies the item to the left, unless it occurs at the beginning of the line, in which case it modifies the item to the right.

Negative opinions, says who?

[fahrbot-bot]

Though beloved to some, C is a language that many choose to hate. The mass opinion is indeed so negative it's hard to believe that anybody would program anything in C.

The masses to which you refer are idiots. C is great. It lets you do what you want, how you want. True, you're afforded enough programming rope to easily hang yourself, but you learn not to, and while most things can be more easily done in higher languages (you'll have to pry Perl from my dead, cold hands), many things can only be done in languages like C or its derivatives. C is one of those languages that separates the adults from the kids, so put on your big-boy pants, stop whinging about it and step up.

What a crock....

[Anonymous Coward]

Who are these people that hate C? A tool is a tool and some are better suited to a job then others. Even COBOL has it's place. If you want something to compile to true binary code that runs very fast on the target hardware, then C is a great tool. If you want to slam out some code that will sort of run and look okay to the user, how about Visual Basic? Pascal has it's place as does C++ and even ASP.

right tool for the job

[bcrowell]

The mass opinion is indeed so negative it's hard to believe that anybody would program anything in C.

Huh? What mass opinion? Where's the evidence for this?

Pick the right tool for the job. C is the right tool for some jobs, specifically jobs like writing drivers or operating systems.

Historically, C won by having an innovative syntax for pointers, which a lot of people liked, and it also won by being a small language that was easy to implement. Because it was small and easy to implement, it ended up being widely available. Ca. 1980, the joke was that C was like masturbation: it might not be what you really want, but it's always available. A lot of people in 2012 may not realize that in the era when C was winning popularity, people didn't usually have access to free compilers, and for many types of hardware (e.g., 8-bit desktops like the TRS-80), there simply weren't any good development tools. Another big win for C was that because it was so widely available, it became easy to find programmers who could code in it; it fed on its own success in a positive feedback loop. This is why languages like java had C-like syntax -- they wanted to ride the coattails of C.

IMO the biggest problems have been when people started to use C for tasks for which it wasn't the right tool. It started creeping up into higher-level applications, where it wasn't really appropriate. This became particularly problematic with the rise of the internet. Networks used to be small and run by people with whom you had personal contact, so nobody really cared about the kind of buffer-overflow vulnerabilities that C is prone to. The attitude was that if you gave a program crazy input that caused it to crash, well, what was the big deal? You crashed the program, and you were only hurting yourself.

Fortran is better.

[Salis]

Go ahead. Argue. I dare you.

v same sig since 2002. v

Re:Fortran is better.

[maroberts]

Go ahead. Argue. I dare you.

v same sig since 2002. v

If a man shouts "Fortran is better" and no-one hears him, he is still wrong.

Re:Fortran is better.

[phagstrom]

The answer is yes in all three cases....

Re:Fortran is better.

[Rising Ape]

The main problem with Fortran is Fortran programmers. Or, more specifically, those who started off with F77 or earlier and carried on doing things the same way. For numerical stuff, I prefer F90 or later to C - far fewer ways to shoot yourself in the foot with memory management.

Re:news for n00bs

[Vlad_the_Inhaler]

Move along, nothing left to C

Because its fun

[Anonymous Coward]

I'm writing a game in C. I spent a lot of time trying to decide what language to use for the game: Java, C#, Python, C++. Ultimately I decided that I wanted to write the whole thing myself so I didn't have to rely on any releases of virtual machines.

I find it fun. I write in C++ for my job and that is where I spent most of my education. C is an interesting challenge where I don't get all of my comforts. But, it works. I tried writing the game in C++ and I kept getting lost in infrastructure: Objects or get-it-done function? I had to decide all the time. C drops that for a simple set of rules (to me, but I "grew-up" in C++ so I'm used to managing memory) that helps me get the job done. I'm still learning, and I work on infrastructure some to reduce complexity, but its fun.

Use the right tool for the right job

[Anonymous Coward]

I'm as tired of single-langujage zealots as I am about single-issue zealots in politics. It's a repetition of the old saw: "When the only tool you have is a hammer, everything starts looking like a nail." C has its applications. C++ has its applications Perl has its applications. FORTRAN (remember that language?) has its applications. And so on down the list.

The fact is, a true professional doesn't have a single tool, he has a whole toolbox full of tools from which to select one, or two, or three, or more to get a particular job done. Look at your auto mechanic: he doesn't try to use a screwdriver when a torque wrench is called for. Look at the Web developer: he doesn't try to write C code to do Web sites. And no one in their right mind would write the heart of an Internet router in C++ or PHP or (shudder) COBOL. The tool has to be matched to the job.

Sometimes you do the job multiple times, once in an easy-to-debug language to get your algorithms down and your corner cases identified, then a second pass in a language that lets you get closer to the nuts and bolts -- hey, you already have the high-level stuff debugged.

And then you have people who are more comfortable creating tools to get the job done. I don't know how many times I've written a LEXX/YACC package to generate exactly what I need from a higher-level description...or to give a customer scripting capability suited to the particular task. I call it part of layered programming, and using multiple languages in a project to get the job done right, and in a way that can be maintained.

Finally, programming style helps reduce mistakes, as do good development tools like IDEs that do syntax highlighting.

OK, every language has its shortcomings. Even specific implementations of a language will drive you up the wall with its mysteries. But that's part of matching the language to the job.

I'll grant you that string handling in C sucks. It's part of the charm, though, for some projects, because you don't have to worry about the run-time kicking in to do garbage collection at points in your code where timing is critical. But if the job is text processing without real-time constraints, C is one of the worse choices for a tool. So don't use it for that. Use Perl, or Python, or PHP, or any number of other languages where string handling is a first-class citizen. (For a price. For a price.)

That's the difference between a true professional and a one-hit wonder: the former knows his tools, how to use them, and when to use them.

Manual Transmission

[ClayDowling]

Lots of people hate manual transmissions in cars, too. That doesn't mean there isn't a place for them. I bought a manual transmission truck for the same reason I use C: it lets me get more performance out of lesser hardware, gives me more control, and it's just plain fun to work with.

Re:Manual Transmission

[ClayDowling]

It's been nearly impossible to do that for at least 40 years. I'm not trying to be faster than the machine, I'm trying to be smarter. I know when to downshift for power and control, something the machine can't do because it doesn't have information about the outside world which I do have. I've driven identical models where the only difference was the transmission, and there's a huge difference in how the vehicle handles.

The same is true with C. When I need the control and the performance, I can get it consistently and reliably from C. It takes knowledge and good habits, just like the manual transmission, but having those, the advantages are within my reach.

Litmus test.

[HornWumpus]

If you can't code in C you can't code.

That said, unless you are doing low level/embedded work if you can't find a better tool for the job, you also can't code.

C should be _every_ programmers second language at the latest.

The other thing to love about C? Pointers! Pointers to pointers! etc. Coding without pointers might be safe, so is fapping.

Re:because -

[AuMatar]

And the funny thing is that most people who write const char* foo really want char const * const foo. You don't want either the pointer or the data pointed at to change. However, almost nobody knows that, so even those who do just use the weaker const char* so people understand the code.

C - The language of Patriots

[stox]

After all, in our National Anthem, we ask, "Jose, can you C?"

Re:C - The language of Patriots

[FrankDrebin]

I guess that means we work at a higher-level here with "O Can ADA".

Re:Think of it as standardized assembly programmin

[vlm]

you can pretty much predict what assembly instructions it's going to generate

Which is really important, because sometimes you end up debugging at that level or working hand in hand with inline assembly code.

If there is no OS, or you're writing the OS, C is the way to go.

Re:because -

[DanTheStone]

Thank you. "const" modifies the thing that preceded it. Iff nothing precedes it, it modifies the first thing that follows it. It's not terribly complicated.

Re:Useless submission.

[Penguinisto]

Not necessarily.

Some of us were developers at one point in our careers, some of us deal with tech that is extremely close to having to occasionally jump into source code, and some of us are hobbyists who just do it for the hell of it.

Personally, I dabble in it once in awhile, but cannot stand to do it professionally. Why? Because I'd rather dream of naked nubile young ladies (grits optional) than to spend all my sleeping hours mentally untangling someone else's poorly-built code (or worse, my own occasional bork-ups).

That, and it's kind of nice to not have to keep a laptop near the bed any more. :)

Because it WORKS

[gman003]

C and C++ (I consider them essentially the same, if only because I write them essentially the same) have a few advantages:

They work. A language update doesn't break your actual programs. It may break your ability to compile them, but you still have a working binary compiled with the old version, which gives you time to make the code work with the new version. You never have to run around like a chicken with it's head cut off because some automatic Java or Python or PHP or __LANGUAGE__ update broke __BIG_CRITICAL_APP__.

The tools work. You have IDEs that actually work. You have debuggers that actually debug. You've got static analysis tools that actually analyze (I've seen some PHP "static analyzers" that actually just make sure you use a particular code style!). If you want, you can grab the intermediate assembly files and debug *those*.

The coders work. Sure, C[++] has some really awful language features, but the programmers know about them, know how to use them properly (which, often times, is "never"). It's a language known by any decent programmer. Maybe not used, or liked, but pretty much everyone can read C.

It does things many other languages can't. You cannot (last I checked) embed assembly snippets in any other major language. There are many libraries that only have C APIs.

It's fast. Game developers, serious ones, use C++, because even Java is still too slow. And when you have 20,000,000 vertices you need to render every 16ms, speed *matters*. That's why web servers are written in C. That's why operating systems are written in C. That's why other programming languages are written in C. Because sometimes, processor time actually *is* more expensive than programmer time.

I *like* C. That game I program in my free time? It's C++, but it acts like "C with objects and strings". Sure, I could have done it "faster" in another language, but I know C and like C, for all the reasons enumerated above.

Portability

[Anonymous Coward]

Among the many benefits of C overlooked by some apparent `mass opinion' is portability. C compilers are easy to create. Things written in C can be compiled on platforms that provides a C compiler. C has been the lingua franca of mature system software for over 40 years; it's the first thing you write after you have a working assembler.

This situation won't change until someone makes a real alternative. Lots of things purport to offer an alternative but are actually not; they are complex and require sophisticated compilers and memory management schemes. C is simple. Any alternative must be at least as simple to be considered.

It isn't hard to imagine an alternative. C is not perfect. The problem, in my opinion, is that no one has really tried; language designers seem to be interested in only higher level problems and are happy to muddle along ignoring the flaws of C.

Re:because -

[Mike Buddha]

And the funny thing is that most people who write const char* foo really want char const * const foo. You don't want either the pointer or the data pointed at to change. However, almost nobody knows that, so even those who do just use the weaker const char* so people understand the code.

Hmm. I wonder why there's so much animosity towards C? It's a mystery.

Re:because -

[TwineLogic]

Oh, no, it's not a mystery. The animosity comes from ignorance and lack of ability. Many newer programmers have never programmed in assembly language or C, and would not be able to build a computer out of logic chips. This same demographic has learned Java and believes that Hashmap is a magic O(1) thing you can just smear onto any algorithm. C was initially popular among people who were, in fact, able to build computers out of 7400-series logic, or even transistors, if need be. In other words, the animosity comes from those who aren't qualified to judge.

Re:Useless submission.

[jd]

Curiosity is real. Unless declared integer.

What's To Love?

[Greyfox]

One, it's simple and reasonably consistent. If I recall correctly, the language only has 24 keywords. Everything else is library. You may have some complaints about the library, but that's not really a language issue is it?

Two, the library. You may have some complaints about the library, but in the right hands a person really can control every aspect of a UNIX system with it. I've had to write process watchdogs at a couple of different companies. These were programs that would kick off another process and monitor its status. That is remarkably easy to do in C. It's a little harder to do correctly but it's still pretty nice. I still hand-code socket servers from time to time. That's also pretty easy with C and the standard library. Actually IPC in general is quite accessible. Handling time... easy. Checking filesystems to see how many blocks are left... easy. The list goes on.

All those utilities we take for granted are all implemented in C, and you can get at all that functionality if you need to. Once you've done some system level programming, the constraints of less mature languages become annoying very quickly. Compare the capabilities of Java's "Process" to what you can do in C, for example.

Sure it's dangerous. Sure there are corner cases you might get caught at. But really, the corporate software development model is far more dangerous, no matter what the language. If you code small, tightly focused libraries and unit test them, whatever language you use is probably pretty safe. If you code some monolithic abomination with half a million lines of tightly coupled, untested code, you're probably going to run into problems anyway. In 20 years of software development, I've never seen anyplace actually write smaller libraries and link them in. Hell most of the places I've worked either didn't have version control or were using it incorrectly. If your company puts up with bad programming, it really doesn't matter what language you're using.

Re:because -

[Anonymous Coward]

The animosity comes from ignorance and lack of ability. In other words, the animosity comes from those who aren't qualified to judge.

Exactly. Unless you guys can make device drivers in Visual Basic like me, you're not qualified to put down the language.

Subset holy wars; STL without exceptions

[tepples]

One of the best features about C++ is that you can define your own subset that you'll use.

One of the worst features about C++ fanboys is that if their subset doesn't match your subset, you get subset holy wars with "no true Scotsman" fallacies all over: "no true C++ program uses <cstdio>".

Worried about exception handling? Then don't use them!

The entire STL uses new, which throws std::bad_alloc on failure, instead of new(std::nothrow), which returns NULL like old-school std::calloc. So how would one handle out-of-memory conditions on an embedded system with no swap file without A. being unable to use the containers and algorithms of the STL or B. reimplementing the whole STL yourself to use instead of throwing std::bad_alloc?

C is great

[Erich]

• It is much more portable than assembly
• The performance overhead compared to assembly is reasonable
• Most people find it simpler to develop in than Forth
• It's not the horrible monster that C++ is

This makes it very nice for all kinds of embedded environments.

Efficiency matters. Python is great, but you don't want to use it for embedded work.

Bad quiz: "implementation defined" not an option

[tepples]

Fully one-fourth of these questions ask about aspects of a specific implementation, not the C standard, and "implementation defined" is not an option.

Questions 3 and 18 on the quiz assumes that int is 32-bit. Question 3 assumes that unsigned short automatically gets promoted to signed int because no values are lost, but that's true only if sizeof(signed int) > sizeof(unsigned short). It's not true on platforms with 16-bit int, for example. Question 18 states that the answer is correct "as long as the int type is wider than the short type", which again is not the case if sizeof(short) == sizeof(int). Question 12 does the opposite; the answer is wrong if int is 64-bit.

Questions 4 and 5 cover implementation-defined behaviors and assume familiarity with the x86 and x86-64 ABIs. I happen not to own an x86-64 machine, and I understand some widely used ARM ABIs differ by having char default to unsigned. Question 4 implicitly asks about x86 and x86-64, while question 5 dishonestly doesn't mention which implementation is used until the answer.

Re:Useless submission.

[sqldr]

I've been using D a lot recently. It markets itself as what C++ should've been. In other words, it drops backwards compatibility with C (but can import C libs, and there's tools to help convert the headers to something useful), it has templates that don't confuse the hell out of everybody, but still has operating system level essentials such as pointers, inline assembler and the dreaded goto.

It also has modern things like design by contract, syntactic sugar for mixins, efficient threads, built in variable length arrays and hashes (I've always hated STL), and you don't have to bother with header files (in fact, they don't exist), etc.

It's a shame it's not more popular, but since I'm coding stuff for a hobby here rather than a job, that doesn't really matter.

Let the flames begin!

Re:MultiBoot binaries for GBA

[serviscope_minor]

You've set up a massive straw man.

Why on earth would the vendor's compiler for that platform provide a standard library with full support for disk based files, POSIX locales, and all sorts of other obscure features when the target is a tiny micro?

The C and C++ standard library in glibc and libstdc++ are both huge to deal with a lot of odd stuff specific to general purpose POSIX class computers.

You wouldn't use the stock gcc iostreams, or the stock glibc on an atmel.

A lot of C Programmers are missing Objective-C

[QX-Mat]

Disclaimer: I'm an Objective C Programmer by day

The LLVM compiler suite is tremendously powerful with Apple's billions advancing many select features, but key to it's success from a users prospective the core use of reference counted object graphs (of type 'id') and reflection (RTTI - via 'isa' and 'Class'). Obviously this means the entire language is dynamically typed at runtime, but with express qualification in 99% of the code you'll use there's absolutely no performance hit despite the ubiquity of the core object.

I worry that many C programmers will remember RTTI was once considered an unportable disaster in C++ because of the the many differing implementations owing to a spec that left the implementation up to each compiler... Don't let this kind of talk scare you! Although objective, objc is contained to a well defined spec, single inheritance and nary a template in sight.

I consider my programming work to be relatively easy. 50% of my ease comes from the object system above. The other 50% from the fast messaging system used in place of raw ADTs: In the objc world a nil object doesn't fault when messaged (in a C world dereferencing a NULL pointer, common if a struct fetching function fails and then passes NULL on failure) leads to all manner of crashes, or as seen recently, kernel exploits. The messaging system can even push around primitive values, not just nasty objects.

If you program in C, you may have missed Automatic Reference Counting, if you have, low and behold, it's amazing: at *compile time* the compiler adds lifetime qualifiers to the IR that automatically inserts retain and release messages (retain is +1 on alloc, -1 on dealloc - release occurs at 0). In other words the lifetime of an object in objective-c is now exactly the period of acquisition to last use. Yes, last use. ARC's use of a new 'weak' reference means that dangling pointers are a thing of the past: a __weak object is automatically nil'ed after last use: in all local instances of that object (did I say nil objects don't fault on message?).

Admittedly most of what I've mentioned is thanks to the advances in LLVM's Clang compiler, in particular it's static analyser, therefore much objc analysis also benefits C (LLVM's IR is quite specular ).

I could go on: methods can be heap objects with cblocks, objc encourages abstract programming with delegates, you can method swizzle at runtime, extend existing classes and link to C/C++ code.

Re:because -

[tzanger]

No, we stick with C because it is a great middle ground between assembly and high level languages. I would not want to write Python or Java on little microcontrollers. C is a small enough language that lets you write complex code relatively easily while staying close to the hardware.

C's got its warts, it's true. It's a mature language that leaves the programmer in control of the system. It's not supposed to do the fancy things such as garbage collection, object management and so on. I'm glad it doesn't. There are other languages for that.

Reverted to C

[buserror]

I did C++ for a very, very long time (20+ years), and yes, you can take a nice subset of c++ that is not bloated, and in that case it's a nice language.

The problem is when you work with other people. They'll drag in all the bloat they can, templates, RTTI, stl (ick), and... boost (arrrgh). And you end up with code that is actually giganormous, and runs slower than Java. I'm not joking, try stuff like OpenSCAD (chokes on 2 pages of geometry) or Code::Blocks (lags like crazy when editing the smalest of file) then there is the obvious KDE desktop, and many others.

So a few years back I reverted to C99. C99 actually had some features that c++ lacks (complex struct initialisation for example) and after years of C++ you know enough about putting structure into your code that you don't /strictly/ need classes anyway. In fact, after a while, you start to realize that in many case, you /don't/ need classes -- sometime you can reduce a problem to 2 or 3 functions, you don't need the 24 accessors, 5 constructors and all that fluff.

It's very refreshing try it. I think you can pick up good habits by hacking on the linux kernel and stuff like qemu/kvm... that sort of C project uses very complex constructs, all in C, and all in a 'clean' environment, there is a LOT to learn in these projects.

The only thing I miss is references; thats the ONE thing I'd like to bring back.

Oh, and if you want slightly smarter memory management for struct-like-objects and that sort of stuff, do lookup "libtalloc" -- it's a little bit of samba that is well worth the look at..

C unsafe

[hackus]

Yes, and like firearms, you need training and instruction before use.

C like firearms, requires training and instruction before use.

I wouldn't put a firearm in the hands of a 6 year old, a politician or a banker because obviously the 6 year old will hurt themselves and the politician and banker will give it too someone else to shoot you with. (or...quite possibly the attorney general would just ship it to mexico and have drug gangs kill you....but I digress.)

Likewise, I would not give a C compiler to a asp programmer or visual basic programmer. The asp programmer would crash the server, and the visual basic programmer would unwittingly put back doors in the software they write to which they would exclaim:

"Jeepers, how did that happen?"

-Hack

Scientific Computing?

[barlevg]

500+ comments and nothing about the fact that in academia, most code that's written for speed (still waiting on that MATLAB code to finish...) is written in either C or FORTRAN? I must have missed something.

get off my lawn

[Tom]

That article could've only been written by someone who isn't a coder. If you are a coder and you can't code C then you aren't a coder. Seriously.

C is a great language. It's the AK47 of programming languages - rough, barebones, you definitely need to know how to handle one because it doesn't do all the handholding for you, but you can drop it in the mud, drive a tank over it, pick it up and fire it - and it will fire. None of that 10,000 library dependencies crap.

Learning to code in C - and I don't mean "hello world", I mean a real program with input validation, safe pointer handling and your own memory management - puts you in a great position to write good code in every other programming language.

Basically, people who don't know C are doomed to repeat the same old mistakes. The problem is that most other languages are a lot more forgiving. And thus your errors don't get noticed so easily, until they've accumulated to create a security issue. In C, if your memory handling sucks, you get a buffer overflow and often a hard crash. If you don't handle your input correctly - crash. And so on.

Back at university, when I was the assistent for the C programming course, students hated me for the 100 ways I could make their precious little programs crash. But those who got their code past me had learnt to write safe code, and I'm taking bets that they still do so today.

Re:because -

[stripes]

I think C's originators (or at least the still living one) changed his mind about some of them. From looking at the go language which targets the same programming niche some of these things have been addressed.

The semicolons are implied in most places now (as a side effect it enforces a brace style many people dislike, but happens to be my preference -- so even though I'm happy with C's semicolons this is a borderline positive change for me).

Declaration syntax has been made "more sane", which isn't surprising, and by the time K&R wrote the C book they had already started regretting it (one of the assignments was to parse C declarations into "english", look at what the authors wrote about it).

Go revamped switch (and a lot of the control flow operators).

Some of those changes might just be because computers have gotten a wee bit faster in the last 25 years or so, what constituted a great tradeoff on a computer with a 64K (split I+D) address space and maybe 512K max RAM a clock cycles measured in a few Mhz (oh, and these were multi user computers) is a wee bit different from what makes a good tradeoff now. (semicolons I think wind up here)

Some are likely to be a change they would still have made on the original system. (most of the control flow changes wind up here, likely variable decl too)

Go language

[Frogg]

I like C, and have used it a lot on and off over the years (and probably will still have to again, at some point) - but recently I've been totally loving programming in Google's Go language: it's just fricking awesome, for so many reasons! :)

I think Go is destined for Good-Things(tm) in the future

Re:because -

[Eraesr]

What a crock of shit. C is just a different tool for a different job.
When writing business software for Windows desktop platforms you don't want to mess around with pointers, memory addresses or other relatively low level stuff like that. High level languages like Java, C#, heck, even Delphi are far more useful for that and allow for far greater productivity.
Sure, there are situations where C is the better choice, just like even lower level languages are sometimes a better choice, but claiming that people choose Java, C# or Python over C because they're ignorant is ignorant in itself. If, these days, you choose to build your windows forms application in C, then you're just getting yourself in a world of hurt that could easily be avoided by choosing a different tool (programming language).