What makes C and C++ a "good" language?
-
I think this is one of the reasons its popular: http://www.codeproject.com/Lounge.aspx?msg=4378061#xx4378061xx[^]
I thought there is something like this goin' on. That's okay. :-)
-
I thought there is something like this goin' on. That's okay. :-)
Just though you should know :)
-
Just though you should know :)
Thank you! :-)
-
Can someone tell me why C++ and C programming languages are used than any other programming languages, what can these languages do that others can't. I do know that C can create drivers or system files, which is very important when you become serious about your projects. But why is the industry still use it? And will C or C++ ever die, even though it's a non-stop updating language everyday, and what other languages update just like C/C++. EDIT: While also asking this question, will C++/CLI take over or kill out Standard/Win32 C++? Cause I'm on a website called Codejock Software, looking for a ribbon control to work for Standard/Win32 C++ only, and I can't find it. Most of the controls are only made for C++/CLI.
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
1. Compatibility. If you want code to run on different architectures (X86, ARM, PIC, etc) and different operating systems, C (and sometimes C++) is the only way to go. 2. Performance. Predictable, excelent performance. Unrestricted use of memory and system resources. 3. Libraries (GLib, STL, etc). 4. Huge codebases. 5. Games (most games are done in C++). 6. Flexibility. C++ for example, doesn't impose "objects" and "interfaces". You can write code "the way you want" mixing objects, procedures and templates. You can write abstract code or go directly to asm in the same project. C tops in portability. C++ tops in flexibility. In these areas they have little competition (if any). Both usually top in performance (there are exceptions, but they are that, exceptions). That said, they are complex and require discipline. They are error prone. They are difficult to master (years). They don't have "unique" GUI or libraries. They are not controlled or improved by any corporation. They move at slow pace, considering that improvements should not break existing software.
it´s the journey, not the destination that matters
-
Well, up until now we basically havent listed any useful stuff for the OP about C/C++ benefits/defects. We just continued a totally unneded flame war that started from my statement about C/C++ headers so now I'm going to give a random list of some useful stuff about defects without attempting to be comprehensive because that would be too long. Today it would be quite reasonable to use a "fixed/repaired" version of C without most of its defects - the same is true for C++. Of course no language is perfect but the number of C/C++ defects are unreasonable in a modern widely used general purpose language. There are several obvious bugs just alone in C that are directly inherited by C++. My favorite is: The Most Expensive One-byte Mistake[^] The simple C language alone allows for a lot of programming errors most of which could be eliminated just by making the language more strict. I link a list of C programming errors that can be committed easily and accidently: http://www.andromeda.com/people/ddyer/topten.html[^] Previously I mentioned header files that started a dispute. Some people would argue that headers are good because they separate the interface for reading. I think this is rather a personal preference - with todays tools you can esily extract such information on the fly for languages with better design like C# and Java as well where full runtime type information is available in the ide basically all the time. Even if you prefer header files, there are other languages that implement it in a much better way, I would compare C/C++ headers to assembly text file includes (containing full fledged C source code). (My favorite and silently compiling include related bug was when I found an anonymous namespace in a header, imagine what happens in this case...). Declarations in headers are not guaranteed to match cpp content if a mistake is made not to mention hidden dependencies. I would even question the readability of C++ header files that contain not only public/protected stuff but private and implementation details too (inlined functions -most notably templates - and data members are of course separated from actual implementation of the class methods). Headers and macros held back the development of C/C
C headers provide portability. There are LOTs of C compilers. Headers provide an easy way to build a C compiler for any PIC, ARM, X86, (name your own) architecture. It's not about the developer. It's about the CPU/Memory. About the C/C++ to machine conversion. Headers give a lot of headaches to developers, but developers pay that price to see their code run "everywhere" and not have to rewrite ALL the code every 2 years (for other architecture). Now you tell me that developers should have better tools. And they have. They have a lot of other languages that don't keep the "header" problem. The slow, very basic, error prone compiling. But that languages don't have the portability of C/C++ headers. Portability cannot be enforced. It is the result of ease of implementation of a language for an architecture. C/C++ compiler based approach is unmatched in this area.
it´s the journey, not the destination that matters
-
Well, up until now we basically havent listed any useful stuff for the OP about C/C++ benefits/defects. We just continued a totally unneded flame war that started from my statement about C/C++ headers so now I'm going to give a random list of some useful stuff about defects without attempting to be comprehensive because that would be too long. Today it would be quite reasonable to use a "fixed/repaired" version of C without most of its defects - the same is true for C++. Of course no language is perfect but the number of C/C++ defects are unreasonable in a modern widely used general purpose language. There are several obvious bugs just alone in C that are directly inherited by C++. My favorite is: The Most Expensive One-byte Mistake[^] The simple C language alone allows for a lot of programming errors most of which could be eliminated just by making the language more strict. I link a list of C programming errors that can be committed easily and accidently: http://www.andromeda.com/people/ddyer/topten.html[^] Previously I mentioned header files that started a dispute. Some people would argue that headers are good because they separate the interface for reading. I think this is rather a personal preference - with todays tools you can esily extract such information on the fly for languages with better design like C# and Java as well where full runtime type information is available in the ide basically all the time. Even if you prefer header files, there are other languages that implement it in a much better way, I would compare C/C++ headers to assembly text file includes (containing full fledged C source code). (My favorite and silently compiling include related bug was when I found an anonymous namespace in a header, imagine what happens in this case...). Declarations in headers are not guaranteed to match cpp content if a mistake is made not to mention hidden dependencies. I would even question the readability of C++ header files that contain not only public/protected stuff but private and implementation details too (inlined functions -most notably templates - and data members are of course separated from actual implementation of the class methods). Headers and macros held back the development of C/C
pasztorpisti wrote:
I'm open to any reasoning against the above list
In terms of the errors - those are not errors that show up for me. The errors that I must find involve logic errors. Whether those errors are made by me or others. And if you spend significant amounts of time day to day on errors like those then at best that I can judge you have a problem that can only be solved with a change in process.
pasztorpisti wrote:
In my opinion tools (including dev envs and languages) are very important.
I can and I have achieve orders of magnitude increase in performance by changing requirements. The only way I have ever achieved anything close to that at the implementation level is because the design itself that lead to the implementation was wrong. Other than that implementation improvements can only lead to small increases when everything else is held steady. The following is what impacts performance and even project success. 1. Requirements - most impact 2. Architecture 3. Design 4. Implementation - the least impact. 1/2 are not impacted by language although 2 might be impact by technology. 3 can be impacted by technology but only minimally by language. 4 is impacted by language. So the reason language as less impact is because it does.
pasztorpisti wrote:
I think every company that continues other than garage development has some kind of dev process,
Every company has a process. Some companies have a formalized process. The only measured and significant improvements in development have come from formalizing the process and improving that. Far as I can remember improvement measures consisted of fewer bugs (detected at various points in life cycle), short delivery time, reduced cost and reduced maintenance cost.
pasztorpisti wrote:
but that is another dimension of the problem of cutting development time and providing quality on a completely different level: management
No it isn't. Again the only impact from the studies that I read was based on process improvements. Tools of any sort had nothing to do with it.
-
C headers provide portability. There are LOTs of C compilers. Headers provide an easy way to build a C compiler for any PIC, ARM, X86, (name your own) architecture. It's not about the developer. It's about the CPU/Memory. About the C/C++ to machine conversion. Headers give a lot of headaches to developers, but developers pay that price to see their code run "everywhere" and not have to rewrite ALL the code every 2 years (for other architecture). Now you tell me that developers should have better tools. And they have. They have a lot of other languages that don't keep the "header" problem. The slow, very basic, error prone compiling. But that languages don't have the portability of C/C++ headers. Portability cannot be enforced. It is the result of ease of implementation of a language for an architecture. C/C++ compiler based approach is unmatched in this area.
it´s the journey, not the destination that matters
ErnestoNet wrote:
C headers provide portability.
Not exactly sure what you are claiming but as stated it is wrong. C, the language (not just headers) provides some portability but it is not guaranteed nor even easy and most of that is achieved through the standard libraries.
ErnestoNet wrote:
C/C++ compiler based approach is unmatched in this area.
No idea what you are talking about. Line for line, Java is more portable than C/C++. C/C++ both have features that are specifically not portable in comparison to Java.
-
C headers provide portability. There are LOTs of C compilers. Headers provide an easy way to build a C compiler for any PIC, ARM, X86, (name your own) architecture. It's not about the developer. It's about the CPU/Memory. About the C/C++ to machine conversion. Headers give a lot of headaches to developers, but developers pay that price to see their code run "everywhere" and not have to rewrite ALL the code every 2 years (for other architecture). Now you tell me that developers should have better tools. And they have. They have a lot of other languages that don't keep the "header" problem. The slow, very basic, error prone compiling. But that languages don't have the portability of C/C++ headers. Portability cannot be enforced. It is the result of ease of implementation of a language for an architecture. C/C++ compiler based approach is unmatched in this area.
it´s the journey, not the destination that matters
It's not the C headers that provide portability. Nothing proves that better than the existence of crossplatform languages without headers.
-
It's not the C headers that provide portability. Nothing proves that better than the existence of crossplatform languages without headers.
Text based compilers are easier to write that binary based compilers. The headers approach is easy to build a compiler from. C is a very simple language to write a compiler. There are LOTS of C compilers. More compilers provide better portability. Portability is also usually the result of compatibility. So the reason why the headers approach doesn't change... There are not many cross platform/architecture languages. Name a crossplatform language and I'll compare that to C in terms of portability....
it´s the journey, not the destination that matters
-
ErnestoNet wrote:
C headers provide portability.
Not exactly sure what you are claiming but as stated it is wrong. C, the language (not just headers) provides some portability but it is not guaranteed nor even easy and most of that is achieved through the standard libraries.
ErnestoNet wrote:
C/C++ compiler based approach is unmatched in this area.
No idea what you are talking about. Line for line, Java is more portable than C/C++. C/C++ both have features that are specifically not portable in comparison to Java.
Headers provide an easy "standard" to build a compiler from. If there are more compilers, there is more portability. Java is not more portable than C. Java is (that I know) very portable, just not more portable than C. C has compilers built from a lot of companies for a variety of products (PIC, PIC32, ARM, X86, etc). Java mostly from Sun for X86.
it´s the journey, not the destination that matters
-
pasztorpisti wrote:
enough to say that C/C++ is a bad choice.
When it was chosen, it was the only choice.
pasztorpisti wrote:
In theory it would be easy to design a language that is suitable for writing operating system code without several defects
I worked for a company (Sperry) that did just that. They spent thousands developing a language that had no practical use except for writing their operating system, which was fast reaching the end of its useful life.
pasztorpisti wrote:
I think my statement isn't unfair at all.
I meant it was unfair in that you were judging a language developed in the 80s by the standards of today's knowledge and technology.
One of these days I'm going to think of a really clever signature.
Richard MacCutchan wrote:
When it was chosen, it was the only choice.
Really? The Multics operating system was being programmed in PL/1. The Burroughs B-5000 and subsequent machines had their operating systems coded in Algol with extensions. And a damn fine operating system it was. My alma mater, Case Western Reserve University, implemented an operating system with an Algol-like language called Chili. All of this while C was just beginning to happen and Unix was not yet born.
Richard MacCutchan wrote:
I meant it was unfair in that you were judging a language developed in the 80s by the standards of today's knowledge and technology.
Oh! Does that mean you will be saying nice things about Fortran and COBOL? Or, at least, refrain from saying nasty things about them? ;P
-
Text based compilers are easier to write that binary based compilers. The headers approach is easy to build a compiler from. C is a very simple language to write a compiler. There are LOTS of C compilers. More compilers provide better portability. Portability is also usually the result of compatibility. So the reason why the headers approach doesn't change... There are not many cross platform/architecture languages. Name a crossplatform language and I'll compare that to C in terms of portability....
it´s the journey, not the destination that matters
If we speak of writing a compiler that will be used to compile thousands of other programs, then its worth investing time to make the compiler as good as possible otherwise you will pay the price as many times as you compile/develop a program or more importantly a useful ide for the language. I've never argued against the portability of ansi C, lets consider that as a positive trait of the language but that has really nothing to do with the header files. For example freepascal is crossplatform and it has no header files, the same is true for java+jvm and .net mono + its languages that have quite extensive and unified crossplatform library compared to that of ansi C.
-
If we speak of writing a compiler that will be used to compile thousands of other programs, then its worth investing time to make the compiler as good as possible otherwise you will pay the price as many times as you compile/develop a program or more importantly a useful ide for the language. I've never argued against the portability of ansi C, lets consider that as a positive trait of the language but that has really nothing to do with the header files. For example freepascal is crossplatform and it has no header files, the same is true for java+jvm and .net mono + its languages that have quite extensive and unified crossplatform library compared to that of ansi C.
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set (for example http://www.microchip.com/[^]). Java and .NET are very different that C. They are "platforms", not languages. Java and .NET runtime is in the 20Mb+ size libraries. Latest versions don't support old operating systems. rt.jar is 42.6Mb (compressed!!). Java and .NET strings are inmutable, etc. I'm not defending C, but most modern languages aren't languages, they are frameworks. And C/C++ are few of the languages out there not owned by a corporation (.NET-Microsoft, Java-Oracle). C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers. I guess thats why C tops TIOBE (and C++ is 4º).
it´s the journey, not the destination that matters
-
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set (for example http://www.microchip.com/[^]). Java and .NET are very different that C. They are "platforms", not languages. Java and .NET runtime is in the 20Mb+ size libraries. Latest versions don't support old operating systems. rt.jar is 42.6Mb (compressed!!). Java and .NET strings are inmutable, etc. I'm not defending C, but most modern languages aren't languages, they are frameworks. And C/C++ are few of the languages out there not owned by a corporation (.NET-Microsoft, Java-Oracle). C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers. I guess thats why C tops TIOBE (and C++ is 4º).
it´s the journey, not the destination that matters
Thats true, I'm still sad about how much better could C be (including the related devenvs) without losing its current power. I also treat both java and C# as fully fledged languages, they are just higher level (that is quite ok in the context they are used) and they aim a different target. Those languages provide very good development environment and incorporated very good ideas related to language design.
-
pasztorpisti wrote:
I'm open to any reasoning against the above list
In terms of the errors - those are not errors that show up for me. The errors that I must find involve logic errors. Whether those errors are made by me or others. And if you spend significant amounts of time day to day on errors like those then at best that I can judge you have a problem that can only be solved with a change in process.
pasztorpisti wrote:
In my opinion tools (including dev envs and languages) are very important.
I can and I have achieve orders of magnitude increase in performance by changing requirements. The only way I have ever achieved anything close to that at the implementation level is because the design itself that lead to the implementation was wrong. Other than that implementation improvements can only lead to small increases when everything else is held steady. The following is what impacts performance and even project success. 1. Requirements - most impact 2. Architecture 3. Design 4. Implementation - the least impact. 1/2 are not impacted by language although 2 might be impact by technology. 3 can be impacted by technology but only minimally by language. 4 is impacted by language. So the reason language as less impact is because it does.
pasztorpisti wrote:
I think every company that continues other than garage development has some kind of dev process,
Every company has a process. Some companies have a formalized process. The only measured and significant improvements in development have come from formalizing the process and improving that. Far as I can remember improvement measures consisted of fewer bugs (detected at various points in life cycle), short delivery time, reduced cost and reduced maintenance cost.
pasztorpisti wrote:
but that is another dimension of the problem of cutting development time and providing quality on a completely different level: management
No it isn't. Again the only impact from the studies that I read was based on process improvements. Tools of any sort had nothing to do with it.
Please understand that I never questioned the importance of a development process and the same is true for architectural decisions and design. Indeed, the biggest mistakes I have ever seen were architectural/design mistakes. Without good design or anything above that we have nothing to speek about. My answers assume good architectural conditions and this time focus on the beautification of the least important 4th step. Perhaps some day I will work just with the first 3 steps and I will probably be less concerned about the language and toolset the coders have hard time with... :-) Seriously! :-)
-
Thats true, I'm still sad about how much better could C be (including the related devenvs) without losing its current power. I also treat both java and C# as fully fledged languages, they are just higher level (that is quite ok in the context they are used) and they aim a different target. Those languages provide very good development environment and incorporated very good ideas related to language design.
The problem with C (and C++) is that they have to be compatible with older code. And they are too flexible (too much for my taste). Don't think of high or low level. Templates in C++ are higher level than C# and Java generics (for sure). Think it this way. C/C++ is compatible with new and old stuff. ansi AND Unicode. Asm, procedures, objects and templates. Don't be sad for C/C++. They will outlast C#, Objective-C and Java (Java has started to decline and C again tops the tiobe index). You ask what makes C/C++ "good". Speed, portability, flexibility, huge codebases and an absense of an owner. But, most of all, a compromise of compatibility, no matter how complex the language becomes, how outdated the structure is. New features will be added, old features will not be replaced. To be "better", C/C++ should be incompatible with older code or fork. Luckily that won't happen. It will sacrifice simplicity and ease of use for compatibility. Oh, and C/C++, in certain cases, can be MUCH faster than C#/Java. I have an article where C/C++ is 10x faster that well written C#/Java.
it´s the journey, not the destination that matters
-
Richard MacCutchan wrote:
When it was chosen, it was the only choice.
Really? The Multics operating system was being programmed in PL/1. The Burroughs B-5000 and subsequent machines had their operating systems coded in Algol with extensions. And a damn fine operating system it was. My alma mater, Case Western Reserve University, implemented an operating system with an Algol-like language called Chili. All of this while C was just beginning to happen and Unix was not yet born.
Richard MacCutchan wrote:
I meant it was unfair in that you were judging a language developed in the 80s by the standards of today's knowledge and technology.
Oh! Does that mean you will be saying nice things about Fortran and COBOL? Or, at least, refrain from saying nasty things about them? ;P
Vivic wrote:
All of this while C was just beginning to happen and Unix was not yet born.
And when UNIX was born it was developed with C (and its predecessors) in mind. Of the others I only ever worked on Burroughs' Algol based OS and it was one of the most difficult I ever tried to understand.
Vivic wrote:
Does that mean you will be saying nice things about Fortran and COBOL
I often have. I worked with both languages in the 70s and 80s and found them perfectly adequate for solving specific problems. That is not the case today but it does not detract from their usefulness at the time.
One of these days I'm going to think of a really clever signature.
-
Text based compilers are easier to write that binary based compilers. The headers approach is easy to build a compiler from. C is a very simple language to write a compiler. There are LOTS of C compilers. More compilers provide better portability. Portability is also usually the result of compatibility. So the reason why the headers approach doesn't change... There are not many cross platform/architecture languages. Name a crossplatform language and I'll compare that to C in terms of portability....
it´s the journey, not the destination that matters
ErnestoNet wrote:
Text based compilers are easier to write that binary based compilers.
The headers approach is easy to build a compiler from.
C is a very simple language to write a compiler.
There are LOTS of C compilers.At this point I am rather certain that you do not know what you are talking about. C headers are part of the language. Period. C compilers implement the C language. Period. The first fact is only related to the second by the fact that headers are in the language. It has nothing to do with compilation. There is no such thing as a "binary" compiler in common usage. Best I can suppose you are talking about is what occurs in a Java Virtual Machine when it process a Java class file. That process it best described as interpretation not compilation. Your confusion about the above also has nothing to do with your confusion about what portabiity means.
ErnestoNet wrote:
More compilers provide better portability.
Wrong. You have confused availability with portability. More compilers means you can use it on more platforms. In point of fact almost all C code written for the Windows system will not work on any other platform (without extreme care but that is my point about portability in the first place.)
ErnestoNet wrote:
There are not many cross platform/architecture languages.
You are wrong. Java and Perl exist on many platforms. Excluding small unix platforms, perl exists on basically all unix systems that C does. And again availability is NOT the same as portability.
ErnestoNet wrote:
Name a crossplatform language and I'll compare that to C in terms of portability....
Your term definition for portability is wrong. http://en.wikipedia.org/wiki/Software_portability[^] By definition of programming languages I can always (within resource limits) create compiler/interpreter that originated on one platform and implement it for another. You are using that for your definition and then claiming that because C exists in many places that that makes in "portable" but instead is what it proves that it is 'popular' and '
-
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set (for example http://www.microchip.com/[^]). Java and .NET are very different that C. They are "platforms", not languages. Java and .NET runtime is in the 20Mb+ size libraries. Latest versions don't support old operating systems. rt.jar is 42.6Mb (compressed!!). Java and .NET strings are inmutable, etc. I'm not defending C, but most modern languages aren't languages, they are frameworks. And C/C++ are few of the languages out there not owned by a corporation (.NET-Microsoft, Java-Oracle). C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers. I guess thats why C tops TIOBE (and C++ is 4º).
it´s the journey, not the destination that matters
ErnestoNet wrote:
Consider that C can work in microchips with very little memory and a very reduced CPU instruction set
You are wrong. You are confusing language, compilation and executable. One uses a C compiler to create a program where the executable then runs on the chips that you cite. compiler != program != executable
ErnestoNet wrote:
Java and .NET are very different that C. They are "platforms", not languages
Wrong. Java and C# very specifically are languages. I would guess that you are unaware of real time Java which is specifically targeted at embedded devices. You are confusing language with libraries and you will NOT be able to write a C program that does anything discernable without the C libraries. And it is quite possible to write a C program on windows that would never run on the chips that you cite.
ErnestoNet wrote:
I'm not defending C, but most modern languages aren't languages, they are frameworks.
What exactly do you think that the C++ Standard Library is? Where do you think 'printf' comes from in C?
ErnestoNet wrote:
C/C++ do not target app developers. They target compiler developers, OS developers, driver developers and libraries developers.
I guess thats why C tops TIOBE (and C++ is 4º).Nonsense. The people who write compilers, drivers, OSes and libraries are a small, small fraction of the developer base. If those were the only people using it then it would be far down the TIOBE list. Developers creating business applications use it. That is why it shows up there. You would be better off citing embedded development but there is also C++ and Java development in that domain.
-
The problem with C (and C++) is that they have to be compatible with older code. And they are too flexible (too much for my taste). Don't think of high or low level. Templates in C++ are higher level than C# and Java generics (for sure). Think it this way. C/C++ is compatible with new and old stuff. ansi AND Unicode. Asm, procedures, objects and templates. Don't be sad for C/C++. They will outlast C#, Objective-C and Java (Java has started to decline and C again tops the tiobe index). You ask what makes C/C++ "good". Speed, portability, flexibility, huge codebases and an absense of an owner. But, most of all, a compromise of compatibility, no matter how complex the language becomes, how outdated the structure is. New features will be added, old features will not be replaced. To be "better", C/C++ should be incompatible with older code or fork. Luckily that won't happen. It will sacrifice simplicity and ease of use for compatibility. Oh, and C/C++, in certain cases, can be MUCH faster than C#/Java. I have an article where C/C++ is 10x faster that well written C#/Java.
it´s the journey, not the destination that matters
ErnestoNet wrote:
Oh, and C/C++, in certain cases, can be MUCH faster than C#/Java.
And in certain cases I am faster than C/C++/C#/Java and any other language that you care to name. Not to mention all of the functions that I do that no language can accomplish. But since people don't pay me to digest lunch but they do pay me to write large systems I can be safe in the knowledge that the flavor of the month language (even when it is an old flavor) will have little impact on the performance of the systems that I write and will not make me more or less productive either.