What's To Love About C? 793
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."
because (Score:4, Funny)
char *post = "first";
Re:because (Score:5, Insightful)
Using a string literal as not const is very bad form.
Re:because (Score:4, Funny)
Back to C++ Land with you, rascal!
Re:because (Score:5, Informative)
Re:because (Score:5, Funny)
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 (Score:5, Insightful)
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 (Score:4, Interesting)
Re:because (Score:5, Insightful)
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 (Score:5, Informative)
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 - (Score:5, Informative)
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.
Re:because - (Score:5, Informative)
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.
Re:because - (Score:5, Funny)
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 - (Score:5, Insightful)
Re:because - (Score:5, Interesting)
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).
Re:because - (Score:5, Insightful)
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.
Re:because - (Score:4, Interesting)
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)
Re:because - (Score:5, Informative)
One good reason... (Score:5, Insightful)
It's not the bloated obscenity that is C++.
Re: (Score:3, Insightful)
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... (Score:5, Interesting)
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... (Score:4, Insightful)
*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... (Score:5, Insightful)
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... (Score:4, Interesting)
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... (Score:4, Insightful)
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: (Score:3)
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... (Score:4, Interesting)
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:MultiBoot binaries for GBA (Score:4, Insightful)
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.
Re:One good reason... (Score:5, Insightful)
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... (Score:5, Insightful)
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... (Score:5, Interesting)
Compare C++ to Objective-C. You might dislike the syntax of Objective-C some, but it has clear advantages:
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: (Score:3)
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
Re: (Score:3, Insightful)
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
Re: (Score:3)
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... (Score:4, Informative)
Re:One good reason... (Score:5, Interesting)
* 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: (Score:3)
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 o
Re:One good reason... (Score:4, Interesting)
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:
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: (Score:3)
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 prob
Re: (Score:3)
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
Re: (Score:3)
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... (Score:4, Interesting)
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.
Maybe because it compiles down to the metal... (Score:5, Insightful)
I mean, unless you want to, you know, use pascal or fortran or something.
Re:Maybe because it compiles down to the metal... (Score:5, Insightful)
Re:Maybe because it compiles down to the metal... (Score:4, Interesting)
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... (Score:4, Insightful)
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... (Score:5, Insightful)
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... (Score:5, Informative)
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: (Score:3)
+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
Re: (Score:3)
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 pret
Re:Maybe because it compiles down to the metal... (Score:5, Insightful)
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.
Subset holy wars; STL without exceptions (Score:4, Insightful)
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?
Re:Maybe because it compiles down to the metal... (Score:4, Informative)
> 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: (Score:3, Funny)
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... (Score:4, Insightful)
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... (Score:5, Insightful)
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.
Good habits (Score:5, Insightful)
Re:Good habits (Score:5, Informative)
Re:Good habits (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:3)
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
Re: (Score:3)
of course, programing in C is experience while programming in Java is idle waste.
Re:Good habits (Score:5, Insightful)
OMG! There. That's where all the hate comes from.
--
(Programming in C since 1984)
Re:Good habits (Score:5, Interesting)
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: (Score:3)
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.
Who made that question? (Score:4, Insightful)
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: (Score:3)
I'm a web developer and the question was equally stupid to me. Hell, I know OkCupid [okcupid.com] 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 (Score:5, Insightful)
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 (Score:5, Insightful)
Re: (Score:3)
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 (Score:4, Interesting)
C, predictable? Would you mind taking this http://blog.regehr.org/archives/721 [regehr.org] quiz? It's about the predictability of integers in C.
Bad quiz: "implementation defined" not an option (Score:3)
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
Re: (Score:3)
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, b
The portable assembler (Score:5, Insightful)
Sesame Street already covered this (Score:5, Funny)
It's for cookie.
That's good enough for me.
Shorthand for Assembler (Score:5, Interesting)
Think of it as standardized assembly programming (Score:5, Insightful)
Re:Think of it as standardized assembly programmin (Score:4, Insightful)
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.
Where'd the Unix go? (Score:4, Interesting)
Simple. (Score:5, Insightful)
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] ... just wait. Someone will eventually come along and get modded +2 Funny when they reply to you.
[2] For whoever asks "what's the right job for Brainfuck?"
[3] I see what you'll do there, Mr. Connor.
Re: (Score:3)
Repeat after me: C++ is not equal to C
Wait. Did you mean equal "=", or equal "==" ?
Re: (Score:3)
assert(C == C++);
Beautiful. Someone needs to prep an April Fools joke for next year for renaming C++ to ++C.
simplicity (Score:5, Insightful)
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.
Negative opinions, says who? (Score:5, Insightful)
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.
right tool for the job (Score:5, Insightful)
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. (Score:5, Funny)
Go ahead. Argue. I dare you.
v same sig since 2002. v
Re:Fortran is better. (Score:4, Informative)
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.
Use the right tool for the right job (Score:4, Insightful)
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 (Score:5, Insightful)
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: (Score:3)
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 co
Litmus test. (Score:5, Insightful)
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.
C - The language of Patriots (Score:5, Funny)
After all, in our National Anthem, we ask, "Jose, can you C?"
Re:C - The language of Patriots (Score:5, Funny)
Because it WORKS (Score:5, Interesting)
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.
What's To Love? (Score:3)
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.
C is great (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Re:Useless submission. (Score:5, Insightful)
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.
Re:Useless submission. (Score:5, Funny)
Curiosity is real. Unless declared integer.
Re:Useless submission. (Score:4, Insightful)
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. :)
Re:news for n00bs (Score:5, Funny)
Move along, nothing left to C