What's To Love About C?

because by Anonymous Coward · 2012-07-02 05:37 · Score: 4, Funny

char *post = "first";

Re:because by Anonymous Coward · 2012-07-02 05:38 · Score: 5, Insightful

Using a string literal as not const is very bad form.
Re:because by Anonymous Coward · 2012-07-02 05:44 · Score: 4, Funny

Back to C++ Land with you, rascal!
Re:because by localman57 · 2012-07-02 05:50 · Score: 5, Informative

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 by localman57 · 2012-07-02 07:01 · Score: 3, Interesting

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 by Darinbob · 2012-07-02 07:13 · Score: 4, 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 by Dachannien · 2012-07-02 08:15 · Score: 4, 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 by mooingyak · 2012-07-02 08:38 · Score: 4, 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?

--
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
Re:because by dmbasso · 2012-07-02 19:56 · Score: 4, 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.

--
`echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com

One good reason... by Anonymous Coward · 2012-07-02 05:40 · Score: 5, Insightful

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

Re:One good reason... by serviscope_minor · 2012-07-02 06:05 · 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.

--
SJW n. One who posts facts.
Re:One good reason... by AuMatar · 2012-07-02 06:18 · 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.

--
I still have more fans than freaks. WTF is wrong with you people?
Re:One good reason... by bluefoxlucid · 2012-07-02 06:36 · Score: 5, Interesting
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.
--
Support my political activism on Patreon.
Re:One good reason... by serviscope_minor · 2012-07-02 06:45 · 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.

--
SJW n. One who posts facts.
Re:One good reason... by betterunixthanunix · 2012-07-02 06:55 · Score: 3, 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:
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.
--
Palm trees and 8
Re:One good reason... by 91degrees · 2012-07-02 07:00 · Score: 3, Insightful

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... by stanlyb · 2012-07-02 07:03 · Score: 3, Informative

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... by serviscope_minor · 2012-07-02 07:04 · Score: 4, 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.

--
SJW n. One who posts facts.
Re:One good reason... by AuMatar · 2012-07-02 07:12 · 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.

--
I still have more fans than freaks. WTF is wrong with you people?
Re:One good reason... by serviscope_minor · 2012-07-02 07:21 · Score: 3, 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?

--
SJW n. One who posts facts.
Re:One good reason... by AndrewStephens · 2012-07-02 08:02 · Score: 4, 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.

--
sheep.horse - does not contain information on sheep or horses.
Re:One good reason... by Darinbob · 2012-07-02 08:06 · Score: 4, 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... by UnknownSoldier · 2012-07-02 08:07 · Score: 3, 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.
Re:One good reason... by GauteL · 2012-07-02 08:10 · Score: 3, 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:One good reason... by serviscope_minor · 2012-07-02 09:24 · Score: 3, 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?

--
SJW n. One who posts facts.
Re:One good reason... by roky99 · 2012-07-02 10:43 · Score: 3, Insightful

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.

Maybe because it compiles down to the metal... by skids · 2012-07-02 05:42 · Score: 5, Insightful

...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.

--
Someone had to do it.

Re:Maybe because it compiles down to the metal... by interval1066 · 2012-07-02 05:53 · Score: 4, Insightful

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.

--
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Re:Maybe because it compiles down to the metal... by slew · 2012-07-02 06:01 · Score: 4, Informative

...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... by ByOhTek · 2012-07-02 06:35 · Score: 4, 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.

--
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
Re:Maybe because it compiles down to the metal... by c++0xFF · 2012-07-02 06:54 · Score: 4, 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.
Re:Maybe because it compiles down to the metal... by lgw · 2012-07-02 07:05 · Score: 3, 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.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Maybe because it compiles down to the metal... by skids · 2012-07-02 07:11 · Score: 4, 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.

--
Someone had to do it.
Re:Maybe because it compiles down to the metal... by hxnwix · 2012-07-02 07:15 · Score: 3, 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:Maybe because it compiles down to the metal... by skids · 2012-07-02 07:47 · Score: 3, 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.

--
Someone had to do it.
Re:Maybe because it compiles down to the metal... by lgw · 2012-07-02 09:16 · Score: 3, 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.

--
Socialism: a lie told by totalitarians and believed by fools.

Good habits by Bucky24 · 2012-07-02 05:43 · Score: 5, Insightful

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".

--
All the world's a CPU, and all the men and women merely AI agents

Re:Good habits by localman57 · 2012-07-02 05:53 · Score: 5, Informative

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 by jmsp · 2012-07-02 06:00 · Score: 5, Insightful

> 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 by jellomizer · 2012-07-02 06:07 · Score: 4, 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.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:Good habits by ShanghaiBill · 2012-07-02 06:20 · 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 by Alamais · 2012-07-02 09:55 · Score: 4, 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.

Who made that question? by Anonymous Coward · 2012-07-02 05:44 · 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.

Control by Dan+East · 2012-07-02 05:44 · 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.

--
Better known as 318230.

Re:Control by jythie · 2012-07-02 06:02 · Score: 5, Insightful

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 by Thiez · 2012-07-02 06:58 · Score: 3, Interesting

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

The portable assembler by heson · 2012-07-02 05:44 · Score: 5, Insightful

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.

Sesame Street already covered this by Zephyn · 2012-07-02 05:45 · Score: 5, Funny

It's for cookie.

That's good enough for me.

Shorthand for Assembler by codefool · 2012-07-02 05:47 · Score: 5, Interesting

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.

--
"Stop whining!" - Arnold, as Mr. Kimble

Think of it as standardized assembly programming by localman57 · 2012-07-02 05:47 · Score: 5, Insightful

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.

Where'd the Unix go? by burdickjp · 2012-07-02 05:49 · Score: 4, Interesting

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. by Short+Circuit · 2012-07-02 05:50 · 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]
[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.

--
tasks(723) drafts(105) languages(484) examples(29106)

simplicity by roman_mir · 2012-07-02 05:55 · Score: 4, 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.

--
You can't handle the truth.

Re:Useless submission. by Anonymous Coward · 2012-07-02 05:56 · 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:because - by 19thNervousBreakdown · 2012-07-02 06:01 · Score: 4, 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.

--
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>

Negative opinions, says who? by fahrbot-bot · 2012-07-02 06:04 · 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.

--
It must have been something you assimilated. . . .

right tool for the job by bcrowell · 2012-07-02 06:05 · Score: 5, Insightful

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.

--
Find free books.

Fortran is better. by Salis · 2012-07-02 06:05 · Score: 5, Funny

Go ahead. Argue. I dare you.

v same sig since 2002. v

--
Favorite /. tagline: "On the eighth day, God created FORTRAN." And it was good.

Re:Fortran is better. by Rising+Ape · 2012-07-02 06:31 · Score: 3, 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.

Re:news for n00bs by Vlad_the_Inhaler · 2012-07-02 06:05 · Score: 5, Funny

Move along, nothing left to C

--
Mielipiteet omiani - Opinions personal, facts suspect.

Use the right tool for the right job by Anonymous Coward · 2012-07-02 06:08 · 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 by ClayDowling · 2012-07-02 06:09 · Score: 4, 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.

--
Easy Online Role Playing Campaign Management

Litmus test. by HornWumpus · 2012-07-02 06:09 · 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.

--
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'

Re:because - by AuMatar · 2012-07-02 06:10 · Score: 4, 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.

--
I still have more fans than freaks. WTF is wrong with you people?

C - The language of Patriots by stox · 2012-07-02 06:11 · Score: 4, Funny

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

--
"To those who are overly cautious, everything is impossible. "

Re:C - The language of Patriots by FrankDrebin · 2012-07-02 08:17 · Score: 4, Funny

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

--
Anybody want a peanut?

Re:Think of it as standardized assembly programmin by vlm · 2012-07-02 06:11 · Score: 3, 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.

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger

Re:because - by DanTheStone · 2012-07-02 06:12 · Score: 4, Informative

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. by Penguinisto · 2012-07-02 06:14 · Score: 3, 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. :)

--
Quo usque tandem abutere, Nimbus, patientia nostra?

Because it WORKS by gman003 · 2012-07-02 06:31 · Score: 4, 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.

Re:because - by Mike+Buddha · 2012-07-02 06:43 · 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.

--
by Mike Buddha -- Someday the mountain might get him, but the law never will.

Re:because - by TwineLogic · 2012-07-02 07:02 · Score: 5, Insightful

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. by jd · 2012-07-02 07:02 · Score: 5, Funny

Curiosity is real. Unless declared integer.

--
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)

Subset holy wars; STL without exceptions by tepples · 2012-07-02 07:31 · Score: 3, 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?

C is great by Erich · 2012-07-02 07:57 · Score: 4, Insightful

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.

--

-- Erich

Slashdot reader since 1997

Re:MultiBoot binaries for GBA by serviscope_minor · 2012-07-02 09:27 · Score: 3, 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.

--
SJW n. One who posts facts.

Re:because - by tzanger · 2012-07-02 11:41 · Score: 4, 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 - by stripes · 2012-07-02 19:15 · Score: 3, 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 - by Eraesr · 2012-07-02 21:16 · Score: 4, Interesting

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).

79 of 793 comments (clear)