What makes C and C++ a "good" language?
-
If I had to keep source and/or binary level compatibility then probably C. If I had total freedom then assembly and a new C-like language that has the unambiguous problems of C fixed.
-
jschell wrote:
Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
Good point. Thats why I think that llvm is a great invention and a beam of hope. Its a nice thing that can glue languages together and its already good enough to compete with gcc that is a monster codebase compared to llvm.
jschell wrote:
Nope. If that was the case then Java/C# would have taken over.
Despite the nice design and universality of the packages of these languages they far not cover as many areas as C/C++ libraries and they often don't cover native OS specific staff whose api is also in C. Fortunately they are often well suited for all kinds of enterprise problems where it would be a guilt to choose other languages.
jschell wrote:
No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share.
This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.A lot of factors are involved when you have to decide which language is the nearest to the theoritical domain specific dream language (+libs) to solve the actual problem. If you have to decide for example between C and C++ you are already in trouble because most of the problems are just in between. The libraries are shared between these languages but C++ is a messy language overwhelmed with freature redundancy while C is much simpler but misses some really nice features that make development much efficient and manageable. For this simple reason I always choose C++ because I already know which features to use and which ones to avoid but many C coders don't want to bother with learning the feature mass and the freestyle of C++. Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv, but what about library support? Thats the only thing that keeps me back from wasting my time on starting a battle I hardly win. Maybe in my older years as a hobby project when I will have less todos because its definitely
pasztorpisti wrote:
A lot of factors are involved when you have to decide which language...
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself. I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.) And I have also spent a great deal of time actually seeking real knowledge about making technical decisions. So yes I am in fact aware of what factors are involved in making technical decisions. The conclusion I have come to is that 1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to. 2. The VAST majority of time it doesn't matter. And for many cases where it it might be considered to matter the problem domain drives the decision (you can't program in C# on a system which does not have libraries, .Net, etc no matter why you think it is a good idea.)
pasztorpisti wrote:
Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv
I have written small languages including a small C (used in a commercial application.) I followed the ANSI process for C and C++ extensively when that first occurred. I followed the path of Java as it attempted to reach a consensus and corporate acceptance of a accepted standard along with following the JCP from inception and following a number of topics in there throughout their lifetime. I have even written an IDE. So I know for a fact that it is not "easy".
-
jschell wrote:
The point however is that windows has been re-written.
Well, from our point of view its not important how much they extended or replaced their codebase. Its a fact that they kept backward compatibility with their old api and that doesn't leave much space for practically changing the underlying language. Lot of parts have been tweaked and replaced in windows in the past decade, but I was shocked how much hacks have been kept in the code and win9x compatiblity layers. I'm pretty sure the level of backward compatibility they have often ties their hands pretty strong. On hack I really mean (sometimes really dirty) hack for example to avoid crashes of specific popular old programs that has bugs that don't crash the program on older systems but without special handling they would simply die on NT. And the hacks are explicitly commented with bug IDs and reasonings. This is another hidden face of windows' backward compatibility. I think what makes windows successful also holds it back in development, but I really respect the MS coder guys for what they achieved. Keeping backward compatibility on such a large scale is tremendous work. They don't rewrite everything, what I was curious in the sources is module loading, that consisted of pretty old sources with lot of win3.1 and win9x sources. They use a lot of typedefs that makes porting relatively easy even to 64 bit and thats quite OK till they go on with backward compatibility.
jschell wrote:
I suspect I can take 'cat' from a pre windows unix variant and with "minimal" modification get it to work on a windows 7.
That however doesn't mean that windows wasn't re-written.I wouldnt compare the complexity of a cat program with even the simplest windows gui program. The same is true for the winapi versus posix. The posix api doesn't contain api calls that seriously enforce windows specific compatibility restrictions internally. On the other hand if a program for example subclasses a windows common controls dialog and it expects the border size to be X pixels and hacks around with gui hooking and expects you to send unrelated window messages to avoid a crash then you have a very complex (and sometimes not too well designed) api system to simulate natively and thats near not as easy as implementing a pure simple posix api. Well, we are talking about why havent they changed the language, and the answer is clear: Source level bac
-
pasztorpisti wrote:
A lot of factors are involved when you have to decide which language...
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself. I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.) And I have also spent a great deal of time actually seeking real knowledge about making technical decisions. So yes I am in fact aware of what factors are involved in making technical decisions. The conclusion I have come to is that 1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to. 2. The VAST majority of time it doesn't matter. And for many cases where it it might be considered to matter the problem domain drives the decision (you can't program in C# on a system which does not have libraries, .Net, etc no matter why you think it is a good idea.)
pasztorpisti wrote:
Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv
I have written small languages including a small C (used in a commercial application.) I followed the ANSI process for C and C++ extensively when that first occurred. I followed the path of Java as it attempted to reach a consensus and corporate acceptance of a accepted standard along with following the JCP from inception and following a number of topics in there throughout their lifetime. I have even written an IDE. So I know for a fact that it is not "easy".
jschell wrote:
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself.
I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.)
And I have also spent a great deal of time actually seeking real knowledge about making technical decisions.
So yes I am in fact aware of what factors are involved in making technical decisions.Don't expect me to respect your technical knowledge based on the number of years you spent in the industry. Almost everybody have their areas of expertise here and noone is superman. There are some forum members here I really respect for their clear explanations and opinions despite the fact that I have no clue how old are they and how much have they worked on this and that. This is a discusson about the good and bad traits of C/C++ so please stick to that and don't drive this thread offtopic or into a personal tug of war because I wont participate in that. Please use your experience to list pros and contras about C/C++ thats what the OP is interested in.
jschell wrote:
1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to.
I wouldn't call a decesion so subjective when it is based on past experience. For example a technical meeting is quite enough to make a sum of everyones knowledge in a given area and to make a list of possible solutions and to list pros and contras for each. I think after this the subjective part of the decesion can considerably decrease. When you have to make decisions in unknown areas then its more subjective but spending 1-2 years in a given area make things more objective because you will know 1-2 definitely good solutions to more and more problems. This is however quite offtopic, its not about C/C++.
jschell wrote:
2. The VAST majority of time it doesn't matter. And for many cases w
-
So you would create a new language to create your new OS. Have you created a language like C before? And written the support libraries for that new language?
Yes I created a compiled and a dynamic languages as hobby projects but that time without much focus on design and safety. Havent created a full fledged runtime support though. Anyway, if you are about to create a new OS then its not a big deal to put together a C like low level language with the base libraries as a first step. The complexity of the compiler+lib and the OS are not comparable especially if we make use of a tool like gcc or llvm.
-
pasztorpisti wrote:
Then why have people invented languages and dev environments at all
Why did someone invent the following language? http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29[^]
pasztorpisti wrote:
It provides 10 to 100 times faster iterations for certain type of projects,
How did you measure that? What problem domains did that study apply to? How many developers were involved in it? How and what contributing factors controlled for?
jschell wrote:
Why did someone invent the following language?
http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29[^]Read the wiki page to find that out, but its quite unambiuous why. Still you havent answered the question why don't you still use assembly when the language doesn't count in your opinion.
pasztorpisti wrote:
10 to 100 times faster
Well, here I got carried away... :-) :-) :-) I worked for a company where we created customized database solutions (2 tier) usually in 2-3 month periods with multiple iterations, around 10 coders involved. We worked with C++ and some helper libraries including Qt for the frontend. Sometimes the required fronted and UI was quite complex and pain in the ass to wire together and 2 week was always a bottleneck on the frontend side. Usually 3-5 people was working on the frontend (sometimes including me) with 1-2 weeks per iteration. Then we bought Delphi and used that for frontend development - the 1-2 week iteration time was reduced to 1-2 days, development became comfortable, also the quality/usability of the whole stuff became better with much-much less critical bugs. This was a radical but definitely good step and I think this achievement is a serious difference in many aspects - for me it proved well that language and ide support counts. What delphi gave for us (before 2000) is available now for everyone in the form of .net and C#, a lot of C# coders have C++ experience and they can tell the difference between developing such frontends in C++ and C# even today - more than 10 years later. My opinion about a lot of different measurement techniques: most of them has not much of use other than showing colorful diagrams for higher leaders (if they need it at all), the only ones I find useful: estimated vs actual duration of an iteration or whole development till release (for the whole team), the number of critical bugs during development, and maybe the number of shipped bugs (that you might not know about but its important if we speak of maintenance).
-
Windows isn't written in Basic. So based on your reasoning why does Microsoft keep producing that?
Ah, sorry, I misunderstood your post so I correct my answer. I don't know the answer to that and I'm not really interested to research one because I'm not a big basic fan. I could just guess and I don't like doing that. You can however open a new topic for that and then everyone can tell their opinions or whatever they know about it. But how is this related to bad/good things in C/C++?
-
jschell wrote:
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself.
I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.)
And I have also spent a great deal of time actually seeking real knowledge about making technical decisions.
So yes I am in fact aware of what factors are involved in making technical decisions.Don't expect me to respect your technical knowledge based on the number of years you spent in the industry. Almost everybody have their areas of expertise here and noone is superman. There are some forum members here I really respect for their clear explanations and opinions despite the fact that I have no clue how old are they and how much have they worked on this and that. This is a discusson about the good and bad traits of C/C++ so please stick to that and don't drive this thread offtopic or into a personal tug of war because I wont participate in that. Please use your experience to list pros and contras about C/C++ thats what the OP is interested in.
jschell wrote:
1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to.
I wouldn't call a decesion so subjective when it is based on past experience. For example a technical meeting is quite enough to make a sum of everyones knowledge in a given area and to make a list of possible solutions and to list pros and contras for each. I think after this the subjective part of the decesion can considerably decrease. When you have to make decisions in unknown areas then its more subjective but spending 1-2 years in a given area make things more objective because you will know 1-2 definitely good solutions to more and more problems. This is however quite offtopic, its not about C/C++.
jschell wrote:
2. The VAST majority of time it doesn't matter. And for many cases w
pasztorpisti wrote:
Don't expect me to respect your technical knowledge based on the number of years you spent in the industry.
Your knowledge is based specifically on your experience with C++. My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.
pasztorpisti wrote:
This is especially true for C++ beginners who just think its cool when you use all fancy C++ feature
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
-
pasztorpisti wrote:
Don't expect me to respect your technical knowledge based on the number of years you spent in the industry.
Your knowledge is based specifically on your experience with C++. My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.
pasztorpisti wrote:
This is especially true for C++ beginners who just think its cool when you use all fancy C++ feature
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
jschell wrote:
Your knowledge is based specifically on your experience with C++.
My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.Not true, I've worked with every language you mentioned extensively except fortran, but this drives this whole thread far offtopic.
jschell wrote:
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
Then we agree that C/C++ has obvious defects that shouldn't exist with todays technology.
-
jschell wrote:
Your knowledge is based specifically on your experience with C++.
My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.Not true, I've worked with every language you mentioned extensively except fortran, but this drives this whole thread far offtopic.
jschell wrote:
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
Then we agree that C/C++ has obvious defects that shouldn't exist with todays technology.
-
pasztorpisti wrote:
Then we agree that C/C++ has obvious defects that shouldn't exist with todays technology.
I didn't say that.
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
-
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
One programming language is not better than other. Use the right tool for the right job. PS: Note that ANYTHING is better than JAVA though. This is an exception.
"Real men drive manual transmission" - Rajesh.
-
The less mistakes a language lets to make, the better the language is. Its not real knowledge to learn to deal with the idiotic features of a complex language. If you work in a big team its more likely that someone will be unable to "design". On the other hand the header include are nowhere for example compared to turbo pascal/delphi units. Every other normal language uses some kind of "units" that contain data preprocessed for the compile to make things faster and easier. On the other hand only people how don't have experience with massive codebases don't feel the significance of the slow compilation times caused by header includes.
pasztorpisti wrote:
don't feel the significance of the slow compilation times caused by header includes.
Granted I haven't programmed large scale C/C++ applications in 10 years, but I did do a lot of very large scale C and C++ applications before then, and it was common practice to use Precompiled Headers. There should be no need to be continually chopping and changing headers around, so I don't see why you would have such a massive problem. In fact, this was one of the nicer features of Visual C++ 6 - the ability not to recompile parts of code that hadn't changed.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
pasztorpisti wrote:
don't feel the significance of the slow compilation times caused by header includes.
Granted I haven't programmed large scale C/C++ applications in 10 years, but I did do a lot of very large scale C and C++ applications before then, and it was common practice to use Precompiled Headers. There should be no need to be continually chopping and changing headers around, so I don't see why you would have such a massive problem. In fact, this was one of the nicer features of Visual C++ 6 - the ability not to recompile parts of code that hadn't changed.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
Agree, precompiled headers is a nice 'hack' of modern ages, but you can not put everything into precompiled headers. As an addition I would note that using just visual studio is luxury, its one of the fastest compilers (if not the best in this regard) and the speed gain of its precompiled header feature is also the best. You can not include everything in your precompiled header because that makes iterations on your project much slower and uncomfortable. If you include something in your pch then a single unit compilation (ctrl+f7 in VS) wont detect the changes in headers that are referenced by the pch. OK, then you recompile the pch as well, but thats quite cumbersome. Instead I mostly put the headers of other referenced libraries the pch of a given library, thats often a good tradeoff in a well organized project where inter-library includes and predeclarations are used well without unnecessary header-from-header includes. I have a more comprehensive list of reasonings against headers, please see the link below instead of reading this flame war, this is just pointless spinning around a small thing I've mentioned earlier. http://www.codeproject.com/Messages/4377527/Re-What-makes-C-and-Cplusplus-a-good-language.aspx
-
One programming language is not better than other. Use the right tool for the right job. PS: Note that ANYTHING is better than JAVA though. This is an exception.
"Real men drive manual transmission" - Rajesh.
-
The C and C++ languages are disastrous. They leave so many doors open for bugs and programming mistakes and they have other design failures (like header files that terribly slow down the compile time). The only valid reason for their existence is that most of today's libraries and operating systems are written using these languages. The interface of the majority of libraries and operating system APIs are still C based. Even if you try to replace these languages I think you need 3 different languages to build a whole operating system up on top of bare hardware. A minimal amount of assembly to communicate with hardware, a thin layer of relatively high level but unsafe language that allows for manual memory management in the low-level part of the operating system, and a high level safe language that can be used to write the top level of the operating system and the user programs. C/C++ could be something like the middle from these 3 languages but it would be easier to design a much better language than C/C++ with the same capabilities. Again, the only reason for the existence of C/C++ is massive amount of legacy code. EDIT: This post of mine became quite 'popular', for this reason I would like to link one of my other posts that contains a more comprehensive (but not full) list of my reasonings at the end of this quite long debate: http://www.codeproject.com/Messages/4377527/Re-What-makes-C-and-Cplusplus-a-good-language.aspx[^] Also would like to mention that I have extensive background in low level programming including assembly, C, and C++, reverse engineering and I'm not a 'just because'-type of hater of C/C++ who used only scripts and managed languages - I don't hate C/C++ at all. I respect these languages because they have been fun for me to program in, they helped the world to become better, but we have to see their obvious defects as well. Thanks for reading.
I think this is one of the reasons its popular: http://www.codeproject.com/Lounge.aspx?msg=4378061#xx4378061xx[^]
-
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