What makes C and C++ a "good" language?
-
Again you didn't understand. C language compilation is relatively fast. C++ language compilation, on the other hand is slow, I am aware of it. Anyway you cannot achieve the same performance of a (well) written C++ application with a (well) written application using your favourite programming language (try it). LLVM? Do you mean: "An aggressive open-source compiler for C and C++ and Stacker, a forth-like language"? :)
Veni, vidi, vici.
llvm was started to kill off gcc, so its first frontends are C and C++. Its a nice clean compiler infrastructure that already has other frontends and you can integrate any other languages relatively easy compared to the same work with for example gcc. Its a beam of hope to get rid of the "C++ is good because its the optimal" reasoning because that is simply ridiculous and still doesn't change the fact that both C and C++ are defective. And yes, compiling C is much faster, but on the other hand a C project is also much harder to maintain and the language features don't give much support to arrange huge codebases. The biggest C codebase was around 100.000 loc and it was already hard to navigate. The lack of type safety and typeless linking, lack of namespaces (and the list goes on) give way too much space for human errors. Yes, C code compiles faster but it misses lots of nice features that wouldn't require you to sacrifice compile speed.
-
llvm was started to kill off gcc, so its first frontends are C and C++. Its a nice clean compiler infrastructure that already has other frontends and you can integrate any other languages relatively easy compared to the same work with for example gcc. Its a beam of hope to get rid of the "C++ is good because its the optimal" reasoning because that is simply ridiculous and still doesn't change the fact that both C and C++ are defective. And yes, compiling C is much faster, but on the other hand a C project is also much harder to maintain and the language features don't give much support to arrange huge codebases. The biggest C codebase was around 100.000 loc and it was already hard to navigate. The lack of type safety and typeless linking, lack of namespaces (and the list goes on) give way too much space for human errors. Yes, C code compiles faster but it misses lots of nice features that wouldn't require you to sacrifice compile speed.
-
pasztorpisti wrote:
"C++ is good because its the optimal" reasoning because that is simply ridiculous
Your point is ridiculous. You have nothing to bear out it.
Veni, vidi, vici.
CPallini wrote:
Your point is ridiculous. You have nothing to bear out it.
Which point from the many listed in my posts?
-
CPallini wrote:
Your point is ridiculous. You have nothing to bear out it.
Which point from the many listed in my posts?
-
I will tell it to my mom! :-)
-
I will tell it to my mom! :-)
-
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.
pasztorpisti wrote:
have other design failures (like header files that terribly slow down the compile time)
That's not a design failure. Something other woudln't be possible at that time. First Header-Files were made for easy reading classes. There was no Syntax-Highlighting or code-analysis while editing. You had jsut the VI. Second Point: It was easier to compile that with 16kb or less many machines had in those days, instead of building crossreferences at compiletime.
pasztorpisti wrote:
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
I think Oberon can do all three levels. But who programms in Oberon at all?! :-\ C/C++ is fast, lean but it's not designed for everything. It's good to be backend for complex algorithms but not for frontend. There are tools which close all memory leaks, but they are very expensive.
------------------------------ Author of Primary ROleplaying SysTem How do I take my coffee? Black as midnight on a moonless night. War doesn't determine who's right. War determines who's left.
-
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:
The less mistakes a language lets to make, the better the language is.
Wrong. If you spend even 10% of your time fixing "language" mistakes versus logic/design/requirements mistakes in your code then at best you are an atypical developer.
pasztorpisti wrote:
If you work in a big team its more likely that someone will be unable to "design".
If you work on a big team then it is almost 100% guaranteed that complexity issues will become the most serious development impediment.
pasztorpisti wrote:
Every other normal language uses some kind of "units" that contain data preprocessed for the compile to make things faster and easier....
As I already said, if you think this is a a significant problem in C/C++ then it is because there is a problem in the design. And the SAME exact problem can show up in Java/C# projects.
-
The sources of win2k have been leaked. Download them and look at the code. It contains tons of legacy code even from win31. Not to mention the backward compatibility between windows versions. Windows has never been rewritten.
pasztorpisti wrote:
It contains tons of legacy code even from win31.
Which would be relevant if I had claimed that they had written a newer version of windows from scratch using a black box development effort. But I am pretty sure that the vast majority of code is some command like 'type' has essentially remained the same since pre-win95. On the other hand I know for a fact what is required to move a code base that was originally written for 32 bits when that was new to what it takes to use a 64 bit system. How exactly do you think that windows handles VMing? Did you ever attempt the same thing in Windows 95? I can tell you that I did in fact run two OSes on a Win95 box and it was not easy.
-
I think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases. Better alternatives exist, the nearest to C++ is the D language. Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
pasztorpisti wrote:
think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases.
And as I already said history is SPECIFICALLY full of cases where exactly that has happened. So obviously it can happen.
pasztorpisti wrote:
Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
Wrong. It isn't used because developers have not found an advantage to using it. You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
-
Today there are shit loads of OSes, why would you want to write a new one? Anyway, 99% of the ongoing projects is not an operating system so you can pick from lots of other popular languages. In one of my previous posts I mentioned that there is no other similar low level language however by fixing some issues with C could result in a good one to write driver level stuff.
-
CPallini wrote:
Have you any proof supporting this sentence, regarding the C language?
Yes, in the last years we had many times when we had to rearrange the header includes and optimize for compile times for our CI system. We compiled the codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in all machines in the grid and the compile time was still 20 minutes. By rearranging some header files we could decrease the build time to around 5 minutes. Thats what I'm talking about not some few file hobby projects that make no sense to measure such things.
CPallini wrote:
This is an opinion (mine, for instance, is completely different).
And could you make a list of language features and compare that to some other languages that have better support for that? I see significant deficiencies in C++ comparred to some other languages, and its syntax because more-and-more complex with every new draft. A language that has redundant features and backward compatiblity with a thousand years old other language simply can't be "optimal".
pasztorpisti wrote:
Yes, in the last years we had many times when we had to rearrange the header includes and optimize for compile times for our CI system. We compiled the codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in all machines in the grid and the compile time was still 20 minutes. By rearranging some header files we could decrease the build time to around 5 minutes. Thats what I'm talking about ...
And what I am talking about is that is a poor design. Let us just suppose that there is absolutely no way that you can divide that into independent deliverables (each with a defined public interface.) It certainly wouldn't stop a well design code base in which one could still work effectively on a piece without using the entire code base. If it was designed correctly.
pasztorpisti wrote:
And could you make a list of language features
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
-
ah_ga_ah wrote:
for many purposes being real professionals you will find yourself forced to chose c++
Agree with the whole paragraph. Oh my god! Finally someone gets it!!! :-) Thank you!!!
ah_ga_ah wrote:
Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself.
This is at least a decade old legacy code, how the hell could we grow out 2 million lines of code? :-D :-D :-D Anyway an include hell can be rearranged in 1-2 days even in such a big project if you did it a few times. Just mentioned this to show that headers are bad in general because they give you one more unnecessary problem to look at. Such big codebase is usually grown by big companies who replace their people relatively often and not all of them are good or able to maintain some aspects of such a codebase. I'm also making mistakes. As a result more and more mistakes are made if the language allows that because noone is superman. Its sad but this is not the first big codebase I'm working with and most of them suffers from some problems that could be avoided with a good language that doesn't have the deficiencies of C/C++. C/C++ is way too allowing language.
ah_ga_ah wrote:
You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus.
Agree, I haven't mentioned a solution because "everyone knows" that there is no true alternative currently. I didn't want to do that, my post had a totally different purpose. I wanted to point out that having no alternative still doesn't mean that C/C++ stands it ground well in every aspect but you understood this.
ah_ga_ah wrote:
The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of.
Here comes the reason for my post: I think not every people are dreaming of that language. Lot of people know only C and/or C++ thinking that its the best language of the world for everything and they are just lying in the matrix without seeing the C/C++ defects. My post just wanted to open some eyes, but most of them is OK with their lives in the matrix. I guess you are the only poster in this discussion having some understanding of my cries. :-) The sum
pasztorpisti wrote:
Such big codebase is usually grown by big companies who replace their people relatively often and not all of them are good or able to maintain some aspects of such a codebase.
And of course none of that has anything to do with a specific language.
pasztorpisti wrote:
Its sad but this is not the first big codebase I'm working with
Perhaps you will get to work with a well designed system some day.
pasztorpisti wrote:
Lot of people know only C and/or C++ thinking that its the best language of the world for everything
Many people think that the language that the primarily use is the "best" language for any of a variety of things. Some even refuse to consider the possibility that any other language might be better for anything else. That however has nothing to do with a specific language.
pasztorpisti wrote:
but as a general purpose programming language it has way too many defects accumulated over the decades.
Of which you cite your personal observation of nothing more than slow compile times. And apparently at least one of which the 'best' choice was made to fix it by throwing hardware at it. I can assure you that any number of people have attempted to throw hardware at systems to fix performance problems which only produce marginal improvements. Looking at requirements, architecture and design however can lead to orders of magnitudes improvement. And that has nothing to do with language.
-
pasztorpisti wrote:
Yes, in the last years we had many times when we had to rearrange the header includes and optimize for compile times for our CI system. We compiled the codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in all machines in the grid and the compile time was still 20 minutes. By rearranging some header files we could decrease the build time to around 5 minutes. Thats what I'm talking about ...
And what I am talking about is that is a poor design. Let us just suppose that there is absolutely no way that you can divide that into independent deliverables (each with a defined public interface.) It certainly wouldn't stop a well design code base in which one could still work effectively on a piece without using the entire code base. If it was designed correctly.
pasztorpisti wrote:
And could you make a list of language features
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
jschell wrote:
And what I am talking about is that is a poor design.
Thanks for your advices, it had always been cut into about 10 DLLs. Still the CI system sometimes performed full clean build intentionally and that iteration time was important for us before relase days. Relatively rarely when some central system headers needed modification a grid came very-very handy. Of course I was talking about the full clean build time. I have to admit that the legacy codebase we are speaking about was full of lava code/flow and refactorization and/or partial rewrites in such a huge codebase is not always an option, its cheap neither in time nor in money. Still the owner wants to see it running and extending with new features. :P
jschell wrote:
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
A well chosen language and its development environment can cut the development/debugging (and maintenance!!!) time and the money spent considerably, so it has to do with the success of a project. Of course this isn't true if your company has infinite amount of time and money (I've already worked for one that seemingly had these traits... :-D).
-
pasztorpisti wrote:
Today there are sh*t loads of OSes,...
None of which answered the question.
I answered the question, you just forget to quote the end of my post. My posts are not advertising that we have true alternatives in every areas where C/C++ is used. I just mentioned that even in the areas where C/C++ has monopoly better alternatives could be forged with todays knowledge.
-
pasztorpisti wrote:
think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases.
And as I already said history is SPECIFICALLY full of cases where exactly that has happened. So obviously it can happen.
pasztorpisti wrote:
Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
Wrong. It isn't used because developers have not found an advantage to using it. You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
jschell wrote:
And as I already said history is SPECIFICALLY full of cases where exactly that has happened.
So obviously it can happen.There is something in your statement. I guess languages are gone when they roots die. C/C++ have currently strong roots (at least Windows/*nix systems).
jschell wrote:
Wrong. It isn't used because developers have not found an advantage to using it.
I still think this is partly because of library support and development environment support. Its also a high risk to start a commercial project with something new that can blow. Lets imagine a fatal D compiler crash (without the support of the authors) in the middle of your project! Startups are very slow for these simple reasons.
jschell wrote:
You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++. C# can became widespread (relatively quickly) because its supported by a huge rich company. Its library support is good, its IDE is superb. These give the base of one of your reasonings in a previous post: This language gave something. It made development easier and less risky because of the MS support. Noone makes you so nice IDE for D like the one you have for C#, same is true about support. Its not only the "coolness" and efficiency of the language that makes it widespread, money and/or time is also needed. As I mentioned previously I like the simplicity of C, by modifying it a bit (without keeping the ugly backward compatibility) I think it could be a very nice language for low level coding where C++ and its friends were too high.
-
pasztorpisti wrote:
It contains tons of legacy code even from win31.
Which would be relevant if I had claimed that they had written a newer version of windows from scratch using a black box development effort. But I am pretty sure that the vast majority of code is some command like 'type' has essentially remained the same since pre-win95. On the other hand I know for a fact what is required to move a code base that was originally written for 32 bits when that was new to what it takes to use a 64 bit system. How exactly do you think that windows handles VMing? Did you ever attempt the same thing in Windows 95? I can tell you that I did in fact run two OSes on a Win95 box and it was not easy.
Win95 is "just a nice DOS program". :-) Even if they have replaced and extended parts in the OS they always stayed backward compatible on api and source level and thats alone is a good reason for not switching the language even if all they do is wrapping new kernel. You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system. I think this backward compatibility drains a lot of their energy and it implies some practical restrictions (like language).
-
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
Why shouldn't the industry still use it? If it worked for them in the past, and they already have the programmers experienced in its use, why take the risk and switch to something else? And besides, in many areas it still makes sense to use C/C++ rather than presumably more advanced languages: 1. Existing low level drivers are mostly written in C, and when adding a new driver it would needlessly complicate the interfaces and introduce additional sources of errors. 2. Similarly, Unix and Linux related OSs are written in C/C++, and writing any OS extension in another language would just complicate matters needlessly. 3. Embedded devices usually have much less resources available (processor, memory capacity), and there may only be a limited amount of compilers available for the OS being used. This makes languages like C/C++ a more attractive choice, as they can better deal with these conditions than some modern languages that were designed with the resources and OS-functionality of a full-fledged workstation in mind. E. g. you won't usually find .NET on embedded devices. ;) 4. Real time applications often require full control of algorithms for time critical functions. Modern languages that rely on libraries or provide their own implementation of certain functions don't easily allow that kind of low-level control. Pretty much any language that provides garbage collection is a big no-no for real time, as you cannot sufficiently control when garbage collection occurs. Also, any language that does not use pointers can not be as efficient as a language that does. (or at least I wouldn't know how that's possible) 5. Any application that does an amount of local processing sufficient to make the users wait for more than a couple of seconds, can benefit from a language that allows for better performance. As pointed out in 4., languages not using pointers, or implementing garbage collection, may be inferior choices. There are lots of examples where the benfits of C/C++ don't shine, e. g. a browser, or just about any web application benefits much more from libraries and even basic functionality that other languages like Java, PHP, Ruby etc. provide, and don't have any real restrictions regarding resources or performance. This is not my area of expertise though. Personally I believe that beyond the above reasons, companies may stick with C/C++ simply because it works, and they are reluctant to switch to something new when all (or most) their programmers are used to C/C++.
-
Win95 is "just a nice DOS program". :-) Even if they have replaced and extended parts in the OS they always stayed backward compatible on api and source level and thats alone is a good reason for not switching the language even if all they do is wrapping new kernel. You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system. I think this backward compatibility drains a lot of their energy and it implies some practical restrictions (like language).
pasztorpisti wrote:
Win95 is "just a nice DOS program"
The point however is that windows has been re-written.
pasztorpisti wrote:
You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system
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.
-
jschell wrote:
And as I already said history is SPECIFICALLY full of cases where exactly that has happened.
So obviously it can happen.There is something in your statement. I guess languages are gone when they roots die. C/C++ have currently strong roots (at least Windows/*nix systems).
jschell wrote:
Wrong. It isn't used because developers have not found an advantage to using it.
I still think this is partly because of library support and development environment support. Its also a high risk to start a commercial project with something new that can blow. Lets imagine a fatal D compiler crash (without the support of the authors) in the middle of your project! Startups are very slow for these simple reasons.
jschell wrote:
You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++. C# can became widespread (relatively quickly) because its supported by a huge rich company. Its library support is good, its IDE is superb. These give the base of one of your reasonings in a previous post: This language gave something. It made development easier and less risky because of the MS support. Noone makes you so nice IDE for D like the one you have for C#, same is true about support. Its not only the "coolness" and efficiency of the language that makes it widespread, money and/or time is also needed. As I mentioned previously I like the simplicity of C, by modifying it a bit (without keeping the ugly backward compatibility) I think it could be a very nice language for low level coding where C++ and its friends were too high.
pasztorpisti wrote:
C/C++ have currently strong roots (at least Windows/*nix systems).
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.
pasztorpisti wrote:
I still think this is partly because of library support and development environment support.
Nope. If that was the case then Java/C# would have taken over.
pasztorpisti wrote:
Lets imagine a fatal D compiler crash
I can't speak specifically about D but these days any marginally significant new language will not "crash" when it is released into the public in such a way that it would endanger a product. If it crashes at all then it is probably due to a language construct which can be worked around.
pasztorpisti wrote:
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++.
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.