Why is C still here when C++ has come?
Pages: 12
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Is C nowadays actually used to make big software? If yes, why is C still there when C++ has come and it is almost backward compatible with C++?
With C++11, C11 also came. Why is so much effort being put into C?
Is C nowadays actually used to make big software? If yes, why is C still there when C++ has come and it is almost backward compatible with C++?
With C++11, C11 also came. Why is so much effort being put into C?
For the same reason why so much effort is being put into C++, even after Java, C# and D entered the game.
C and C++ are just not dead yet, although they should be. Especially C++.
Edit: bad mood.
Edit: bad mood.
Last edited on
closed account (z05DSL3A)
| eklavya sharma 2 wrote: |
|---|
| Why is so much effort being put into C? |
Because it is probably the best system programming language out there.[IMHO]
1. Because C++, contrary to C, is a huge pain to interface with, especially at the binary level. That's why most other languages out there have natural bindings to C, but not C++, even languages which claim to be better C++, like D.
2. C is much more portable. Good C++ compilers exist only for the most popular platforms, while C compilers exist for just everything, even the most exotic hardware / OSes.
3. C++ is not programmer-portable. When two programmers tell you "I can code C++", they might both know 20% of the language, however a different 20%, so they would not be compatible with each other. C is so simple, that when you know C, you just know C and can start coding right away.
4. C APIs are more alike and easy to grasp, while C++ APIs to some libraries are often created in completely different styles. E.g. compare Boost and Qt. Two different worlds.
2. C is much more portable. Good C++ compilers exist only for the most popular platforms, while C compilers exist for just everything, even the most exotic hardware / OSes.
3. C++ is not programmer-portable. When two programmers tell you "I can code C++", they might both know 20% of the language, however a different 20%, so they would not be compatible with each other. C is so simple, that when you know C, you just know C and can start coding right away.
4. C APIs are more alike and easy to grasp, while C++ APIs to some libraries are often created in completely different styles. E.g. compare Boost and Qt. Two different worlds.
Last edited on
There are lots of domains where C is just more convenient than C++ or anything else. Particularly embedded programming, systems programming (OS and bootloader development, although in both of those you generally have to use assembly as well) and for building libraries as well, since C++ mangles symbol names to allow overloading and C doesn't (because it doesn't have overloading).
Thanks for your replies.
I earlier thought that C code compiled with a C++ compiler and a C compiler would produce the same binary code.
I don't know what symbols or name mangling are, so I wasn't aware of this difference.
I earlier thought that C code compiled with a C++ compiler and a C compiler would produce the same binary code.
I don't know what symbols or name mangling are, so I wasn't aware of this difference.
C code may not compile with a C++ compiler at all, or it may compile, but produce different results.
Last job I used C a lot was in OS development, where both POSIX and tradition rely on C
Last job I used C a lot was in OS development, where both POSIX and tradition rely on C
| rapidcoder wrote: |
|---|
| C++ is not programmer-portable. When two programmers tell you "I can code C++", they might both know 20% of the language, however a different 20%, so they would not be compatible with each other |
Can you elaborate on this? On first reading, it sounds really ridiculous. Yes, C is a lot simpler, but C++ isn't that much bigger. Someone who only knows 20% of the language won't be able to program anything in C++, and if you know C then you already know much more than 20% of C++ as is. What does C++ add to C? Namespaces, classes, templates, some new casts and some other new keywords. That's all the significant stuff. How are we even measuring an "amount of a language", anyway? Also, why would people know different parts of a language? Extending your logic to natural languages, let's imagine two people who only know 20% of the English language. There are millions of words in a given natural language, generally one or more for every concept the people who speak the language need to express, so this is a much more likely situation than a programming language that has about twenty words and a few symbols. Have you ever met someone who spoke the same language as you, but with whom you could not communicate as they knew a different 20% of the language to you? Of course not, everyone learns the same things. Everyone learns their greetings, the names of all the objects around them, and usually thousands more words. Some people may have a wider vocabulary than others, but there's no way two people who know the same language can be unable to communicate because their vocabularies don't overlap What a ridiculous concept.
| Some people may have a wider vocabulary than others, but there's no way two people who know the same language can be unable to communicate because their vocabularies don't overlap |
As you get to the more esoteric parts of the language (specially some subsets of the standard library, and templates), the amount of overlap between different people drops.
I believe 20% is a bit of an exaggeration, though.
Last edited on
closed account (N36fSL3A)
I actually have been coding in C for a while before I actually used C++ as a language (As a beginner, I thought I was some badass C++ programmer when the truth was I only knew C.) I really like C. I use it whenever I try to create failed libraries and such.
| Why is so much effort being put into C? |
While C++ is a superset of C, they both have tasks they are better suited for, plain and simple. Though, Bjarne said he wanted for them to just combine C and C++ into one language, but says he doubts that will ever happen.
| Though, Bjarne said he wanted for them to just combine C and C++ into one language, but says he doubts that will ever happen. |
... and wasn't that in the context of C being obsolete? Which, coming from the inventor of C++ is extremely hypocritical, in my opinion.
@helios
Sure, but we're talking about two people who both program in C++. Also, generally people learn programming languages in a fairly similar, fairly linear fashion. I've never heard of anyone who had a good understanding of templates, but couldn't handle I/O streams or STL containers. I don't think a situation where one person knows that 20% meets a person who knows a totally different 20% is likely to arise. More likely, IMO, is a situation where someone who knows templates and I/O streams and STL containers meets someone who only understands the latter two, in which case the first person's knowledge encompasses the second person's.
And 20% is a huge exaggeration; the C++ language is about 150 keywords and operators all-included, and the standard library isn't exactly huge: http://en.wikipedia.org/wiki/C%2B%2B_Standard_Library. When we start talking about external libraries, then I can see there being no overlap, but not if we're talking about just the language itself and the standard library (technically we were only speaking of the language, but since the library is declared in the same standard, it in some sense counts as part of the language). The only parts of the C++ standard library that I can see an experienced programmer not knowing are the parts that are some of the less-commonly used STL containers (I've only ever used array, vector and stack), things introduced in C++11, a few other headers that aren't often used, and headers from the C standard library that have been superseded by C++ classes and functions (like cstdio and cstring).
Sure, but we're talking about two people who both program in C++. Also, generally people learn programming languages in a fairly similar, fairly linear fashion. I've never heard of anyone who had a good understanding of templates, but couldn't handle I/O streams or STL containers. I don't think a situation where one person knows that 20% meets a person who knows a totally different 20% is likely to arise. More likely, IMO, is a situation where someone who knows templates and I/O streams and STL containers meets someone who only understands the latter two, in which case the first person's knowledge encompasses the second person's.
And 20% is a huge exaggeration; the C++ language is about 150 keywords and operators all-included, and the standard library isn't exactly huge: http://en.wikipedia.org/wiki/C%2B%2B_Standard_Library. When we start talking about external libraries, then I can see there being no overlap, but not if we're talking about just the language itself and the standard library (technically we were only speaking of the language, but since the library is declared in the same standard, it in some sense counts as part of the language). The only parts of the C++ standard library that I can see an experienced programmer not knowing are the parts that are some of the less-commonly used STL containers (I've only ever used array, vector and stack), things introduced in C++11, a few other headers that aren't often used, and headers from the C standard library that have been superseded by C++ classes and functions (like cstdio and cstring).
Last edited on
@Catfish3
Yeah, but if other programmers are starting to ask if it is obsolete then it can't be that hypocritical. His argument is that C is a subset of C++ and they should be merged because of the fact that you have to remember which language you are using as each have different IO functions and such and it shouldn't be that way anymore. Or that was my understanding of that segment.
Link to the interview segment in case anyone wanted to watch.
http://bigthink.com/ideas/why-the-programming-language-c-is-obsolete
Yeah, but if other programmers are starting to ask if it is obsolete then it can't be that hypocritical. His argument is that C is a subset of C++ and they should be merged because of the fact that you have to remember which language you are using as each have different IO functions and such and it shouldn't be that way anymore. Or that was my understanding of that segment.
Link to the interview segment in case anyone wanted to watch.
http://bigthink.com/ideas/why-the-programming-language-c-is-obsolete
Last edited on by closed account z6A9GNh0
1. Name mangling (a compiler specific feature) prevents absolute portability in c++. A lack of name mangling and low-level programming abstractions puts C in a unique position of being highly portable and easily mixed in with other languages.
2. A C compiler is a lot simpler than a c++ compiler, so C compilers are highly accessible for almost any architecture or operating system.
3. In C void* can be converted to any pointer type where in C++ casting is less flexible (though the use of a union in c++ is a loophole).
4. Lastly with the c++ standard library you are getting overhead b/c you are declaring bulky classes (that come with methods and variables you may not need). C allows you to declare only the functions and variables you actually need so it lends itself more to embedded devices where memory comes at a premium. Embedded devices are everywhere and only increasing, so C maintains it's practical purpose in the world.
5. Legacy code. Going back to point 3, a c++ compiler does not always compile C code. Some modifications may be needed to pass it's type checking. So it's easier just sticking to C.
2. A C compiler is a lot simpler than a c++ compiler, so C compilers are highly accessible for almost any architecture or operating system.
3. In C void* can be converted to any pointer type where in C++ casting is less flexible (though the use of a union in c++ is a loophole).
4. Lastly with the c++ standard library you are getting overhead b/c you are declaring bulky classes (that come with methods and variables you may not need). C allows you to declare only the functions and variables you actually need so it lends itself more to embedded devices where memory comes at a premium. Embedded devices are everywhere and only increasing, so C maintains it's practical purpose in the world.
5. Legacy code. Going back to point 3, a c++ compiler does not always compile C code. Some modifications may be needed to pass it's type checking. So it's easier just sticking to C.
the C++ language is about 150 keywords and operators all-included |
Without operators:
C has 32 keywords
C++ has about 75 keywords
But this is actually not about the size. This is about how you use it. In C++ you can write both a Qt - style (aka Java style) code with classes/objects and virtual methods, as well as go very hardcore-templates and do Boost style. And you can also use C++ as a better C, mostly using RAII to free up resources, but still staying at the very low-level. Or you can even mix all those things with C preprocessor macros and end up with something ugly like wxWidgets.
http://www.johndcook.com/blog/2011/06/14/why-do-c-folks-make-things-so-complicated/
I looked, there's 84 keywords and two special (but not reserved) words in C++. But I was including operators.
Anyway, this is not what you said before. You said they might know a "different 20% of C++", which has nothing to do with style. If you know classes and templates, you must know how to write C-style code because the OOP and metaprogramming parts of C++ extend the procedural parts. The knowledge of the programmer who knows how to use OOP encompasses the knowledge of the programmer who doesn't. And someone who doesn't know how to use OOP in C++ hasn't learned even the base language yet, and thus doesn't deserve the title of "C++ programmer".
Anyway, this is not what you said before. You said they might know a "different 20% of C++", which has nothing to do with style. If you know classes and templates, you must know how to write C-style code because the OOP and metaprogramming parts of C++ extend the procedural parts. The knowledge of the programmer who knows how to use OOP encompasses the knowledge of the programmer who doesn't. And someone who doesn't know how to use OOP in C++ hasn't learned even the base language yet, and thus doesn't deserve the title of "C++ programmer".
Ok, 84 compared to 32 is a *lot*. Scala which is often described as "Scala is to Java what C++ is to C" i.e. too complex, has only 40 keywords, and no operators at all (all operators are just methods). Which is funny, because it is less than Java, and grammar is also simpler, yet people claim it is more complex than Java (well, actually it is not that complex, but it is *hard* because there are lots of new concepts unknown to programmers coming from Java or especially C++ world).
Again, this is not about keywords. It is about what you can do with them. Maybe I wasn't clear in my previous post - code style was a wrong word. There are lots of idioms/concepts in C++. Lots of those concepts are C++ specific, they do not exist in other languages. Even a relatively simple thing - field of pointer type in a class, requires to actually grasp a whole lot of concepts and to know how to mix them in order not to hurt yourself. So instead of just learning a few keywords and basic syntax and immediately being productive like it is in C or Java, you have to then learn how to use all of it efficiently to avoid all the sharp edges (read all the Exceptional C++, More Exceptional C++, etc.). And when you finally wrap your head around it, you meet another C++ dev, and it turns out he picked a slightly different set of guidelines incompatible with your own guidelines. This is what I meant by programmer-non-portable.
Again, this is not about keywords. It is about what you can do with them. Maybe I wasn't clear in my previous post - code style was a wrong word. There are lots of idioms/concepts in C++. Lots of those concepts are C++ specific, they do not exist in other languages. Even a relatively simple thing - field of pointer type in a class, requires to actually grasp a whole lot of concepts and to know how to mix them in order not to hurt yourself. So instead of just learning a few keywords and basic syntax and immediately being productive like it is in C or Java, you have to then learn how to use all of it efficiently to avoid all the sharp edges (read all the Exceptional C++, More Exceptional C++, etc.). And when you finally wrap your head around it, you meet another C++ dev, and it turns out he picked a slightly different set of guidelines incompatible with your own guidelines. This is what I meant by programmer-non-portable.
Last edited on
| learning a few keywords and basic syntax and immediately being productive like it is in C |
You can't be serious!
Pages: 12