What makes C and C++ a "good" language?
-
pasztorpisti wrote:
The C and C++ languages are disastrous.
I think this is rather unfair. C was created to make the writing of operating system code much easier; C++ was an improvement but still based around the same design goals. The fact that people wrote other programs using those languages is the fault of the developers rather than the languages. Yes, there are shortcomings compared with some modern languages, but neither C nor C++ were designed to do some of the work that people expect of it these days.
One of these days I'm going to think of a really clever signature.
If we speak of a massive codebase like one that an operating system has then the build time and header hell are alone enough to say that C/C++ is a bad choice. The problem is that the accident has already happened and windows and linux are already in C. The difficulties in parsing and translating C++ just add to compile times and project complexities. In theory it would be easy to design a language that is suitable for writing operating system code without several defects that accumulated in C/C++ over the decades (because of its backward compatibility) so I think my statement isn't unfair at all. Not to mention the different C/C++ languages per compiler, this language isn't compatible even with itself in practice!
-
If we speak of a massive codebase like one that an operating system has then the build time and header hell are alone enough to say that C/C++ is a bad choice. The problem is that the accident has already happened and windows and linux are already in C. The difficulties in parsing and translating C++ just add to compile times and project complexities. In theory it would be easy to design a language that is suitable for writing operating system code without several defects that accumulated in C/C++ over the decades (because of its backward compatibility) so I think my statement isn't unfair at all. Not to mention the different C/C++ languages per compiler, this language isn't compatible even with itself in practice!
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.
-
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.
Today its not the only choice. Some people choose it because they don't know its defects, or they don't have other choices to develop low level code, and because of the big masses of legacy code.
Richard MacCutchan wrote:
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.
We don't know how good that language was. Its not sure that the language was good. Even if something is good, it doesn't mean it becomes widespread. "The rich gets richer." as the C/C++ becomes more and more widespread.
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.
If we were speaking about its application in the 80s then it would be unfair. Since we are speaking about its application today its not unfair to say that the only thing that keeps it alive is legacy code. Its just telling the cruel truth.
-
Richard MacCutchan wrote:
When it was chosen, it was the only choice.
Today its not the only choice. Some people choose it because they don't know its defects, or they don't have other choices to develop low level code, and because of the big masses of legacy code.
Richard MacCutchan wrote:
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.
We don't know how good that language was. Its not sure that the language was good. Even if something is good, it doesn't mean it becomes widespread. "The rich gets richer." as the C/C++ becomes more and more widespread.
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.
If we were speaking about its application in the 80s then it would be unfair. Since we are speaking about its application today its not unfair to say that the only thing that keeps it alive is legacy code. Its just telling the cruel truth.
pasztorpisti wrote:
Today its not the only choice.
Quite true, and I never disputed this.
pasztorpisti wrote:
We don't know how good that language was.
I do, It was OK and somewhat similar to C, but so specialised it had no chance of being used on any hardware other than the 1100/2200 range.
pasztorpisti wrote:
its not unfair to say that the only thing that keeps it alive is legacy code.
There are still lots of new developments being done with C and/or C++ because people think they are the right language for the job, despite their many shortcomings, so in that respect it probably is unfair.
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.
Today its not the only choice. Some people choose it because they don't know its defects, or they don't have other choices to develop low level code, and because of the big masses of legacy code.
Richard MacCutchan wrote:
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.
We don't know how good that language was. Its not sure that the language was good. Even if something is good, it doesn't mean it becomes widespread. "The rich gets richer." as the C/C++ becomes more and more widespread.
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.
If we were speaking about its application in the 80s then it would be unfair. Since we are speaking about its application today its not unfair to say that the only thing that keeps it alive is legacy code. Its just telling the cruel truth.
pasztorpisti wrote:
Today its not the only choice
So what language would you choose today to write a new OS in ?
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
-
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:
like header files that terribly slow down the compile time
Have you any proof supporting this sentence, regarding the C language?
pasztorpisti wrote:
Again, the only reason for the existence of C/C++ is massive amount of legacy code
This is an opinion (mine, for instance, is completely different).
Veni, vidi, vici.
-
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:
Again, the only reason for the existence of C/C++ is massive amount of legacy code.
Nonsense. At one time languages like COBOL, ALGOL and FORTRAN had massive support and massive amounts of legacy code. But programmers have moved on from those languages for various reasons which although often subjective are probably based on non-explicit objective reasons. Yet that hasn't happened with C/C++. C/C++ fills a need that other current languages do not.
pasztorpisti wrote:
(like header files that terribly slow down the compile time).
Err..the only ones that think that is a significant problem are those that don't know how to design (nothing to do with language choice) or those that can't recognize a poor design when one sees it.
-
If we speak of a massive codebase like one that an operating system has then the build time and header hell are alone enough to say that C/C++ is a bad choice. The problem is that the accident has already happened and windows and linux are already in C. The difficulties in parsing and translating C++ just add to compile times and project complexities. In theory it would be easy to design a language that is suitable for writing operating system code without several defects that accumulated in C/C++ over the decades (because of its backward compatibility) so I think my statement isn't unfair at all. Not to mention the different C/C++ languages per compiler, this language isn't compatible even with itself in practice!
-
Richard MacCutchan wrote:
When it was chosen, it was the only choice.
Today its not the only choice. Some people choose it because they don't know its defects, or they don't have other choices to develop low level code, and because of the big masses of legacy code.
Richard MacCutchan wrote:
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.
We don't know how good that language was. Its not sure that the language was good. Even if something is good, it doesn't mean it becomes widespread. "The rich gets richer." as the C/C++ becomes more and more widespread.
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.
If we were speaking about its application in the 80s then it would be unfair. Since we are speaking about its application today its not unfair to say that the only thing that keeps it alive is legacy code. Its just telling the cruel truth.
pasztorpisti wrote:
Even if something is good, it doesn't mean it becomes widespread
However the reality is that something that is in fact substantially better will become widely used. And something that isn't will be tossed away. There are all sorts of failed technology choices. And just a few winners. If C/C++ were that bad then they would not have continued to retain the market share that they do.
-
pasztorpisti wrote:
Today its not the only choice.
Quite true, and I never disputed this.
pasztorpisti wrote:
We don't know how good that language was.
I do, It was OK and somewhat similar to C, but so specialised it had no chance of being used on any hardware other than the 1100/2200 range.
pasztorpisti wrote:
its not unfair to say that the only thing that keeps it alive is legacy code.
There are still lots of new developments being done with C and/or C++ because people think they are the right language for the job, despite their many shortcomings, so in that respect it probably is unfair.
One of these days I'm going to think of a really clever signature.
Richard MacCutchan wrote:
I do, It was OK and somewhat similar to C, but so specialised it had no chance of being used on any hardware other than the 1100/2200 range.
The low level language I was dreaming about is general purpose like C. If that language was hardware specific then its death is natural when the hardware goes out of production because its not a general purpose lang, its rather a high level assembly for the target hardware. C is quite general purpose to be able to translate to any processors. By fixing some things in C++ and removing the header hell (by using units like in pascal) it could be a very nice low level language.
Richard MacCutchan wrote:
There are still lots of new developments being done with C and/or C++ because people think they are the right language for the job, despite their many shortcomings, so in that respect it probably is unfair.
One of these days I'm going to think of a really clever signature.
Many people choose this language because today this knowledge is quite useful because of the legacy codebases and because it is recommended by their friends. Because of this C/C++ is still the "native language" of many and they use this because they know this, not because they think that it is a better choice than x and y because they simple don't know about x and y as an alternative. The ugly truth is that because of the legacy codebase often C/C++ is the best choice, but this doesnt mean that its a best choice because its a nice language.
-
pasztorpisti wrote:
Even if something is good, it doesn't mean it becomes widespread
However the reality is that something that is in fact substantially better will become widely used. And something that isn't will be tossed away. There are all sorts of failed technology choices. And just a few winners. If C/C++ were that bad then they would not have continued to retain the market share that they do.
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:
Again, the only reason for the existence of C/C++ is massive amount of legacy code.
Nonsense. At one time languages like COBOL, ALGOL and FORTRAN had massive support and massive amounts of legacy code. But programmers have moved on from those languages for various reasons which although often subjective are probably based on non-explicit objective reasons. Yet that hasn't happened with C/C++. C/C++ fills a need that other current languages do not.
pasztorpisti wrote:
(like header files that terribly slow down the compile time).
Err..the only ones that think that is a significant problem are those that don't know how to design (nothing to do with language choice) or those that can't recognize a poor design when one sees it.
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:
like header files that terribly slow down the compile time
Have you any proof supporting this sentence, regarding the C language?
pasztorpisti wrote:
Again, the only reason for the existence of C/C++ is massive amount of legacy code
This is an opinion (mine, for instance, is completely different).
Veni, vidi, vici.
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:
Today its not the only choice
So what language would you choose today to write a new OS in ?
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
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.
-
pasztorpisti wrote:
The problem is that the accident has already happened and windows and linux are already in C.
Which would be relevent except for the fact that windows has been re-written several times.
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.
-
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.
I'm surprised no hackers from around the world has hacked into Microsoft(R) servers and steal every O.S. source codes or projects (or at least some of them), and them publish them on torrents. But Google, Bing, Yahoo and all those other people filter out those results and/or delete them. There probably has been private court orders of Microsoft vs. some hacker, stealing source. But I'm pretty sure Microsoft knows everything about security then any other security company out there combined, considering you have to send your driver to them to get it signed now. Basically Microsoft probably has there servers extremely hard to break through or breach, they probably have it to where if it detects a breach or unauthorized transfer of specific files, it disconnects the servers and computers and locks them down, terminating the hacking or suspicious signal. Who knows, they are probably smart and keep the internet cord unplugged, considering the fact that government leaks there "state of the art" :rolleyes: F-35 blue prints on the internet, where everyone can see (technically, cause if there's internet, there's hackers), or maybe that's bogus that the government sent out to intentionally trick hackers into thinking they got the "real stuff", but who knows what crazy stuff tech companies do these days.:suss::java:
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
-
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 not some few file hobby projects that make no sense to measure such things.
Still it is not a proof. You should compare it to the compilation time of a similar project written with your favourite language and achieving the same performance (if your favourite language could assist you on that).
pasztorpisti wrote:
And could you make a list of language features and compare that to some other languages that have better support for that?
C and C++ are performant. No other language (other than assembly) compares with them. You should know that.
pasztorpisti wrote:
I see significant deficiencies in C++ comparred to some other languages, and its syntax because more-and-more complex with every new draft.
While, for instance,
C#syntax becoming simpler?pasztorpisti wrote:
A language that has redundant features and backward compatiblity with a thousand years old other language simply can't be "optimal"
Still is compatible. I wouldn't call it 'optimal'. However I like it (this doesn't means I show apparent disgust for other languages - with the very exception of COBOL).
Veni, vidi, vici.
-
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 not some few file hobby projects that make no sense to measure such things.
Still it is not a proof. You should compare it to the compilation time of a similar project written with your favourite language and achieving the same performance (if your favourite language could assist you on that).
pasztorpisti wrote:
And could you make a list of language features and compare that to some other languages that have better support for that?
C and C++ are performant. No other language (other than assembly) compares with them. You should know that.
pasztorpisti wrote:
I see significant deficiencies in C++ comparred to some other languages, and its syntax because more-and-more complex with every new draft.
While, for instance,
C#syntax becoming simpler?pasztorpisti wrote:
A language that has redundant features and backward compatiblity with a thousand years old other language simply can't be "optimal"
Still is compatible. I wouldn't call it 'optimal'. However I like it (this doesn't means I show apparent disgust for other languages - with the very exception of COBOL).
Veni, vidi, vici.
CPallini wrote:
Still it is not a proof. You should compare it to the compilation time of a similar project written with your favourite language and achieving the same performance (if your favourite language could assist you on that).
Its already a proves that that header files suck. On the other hand I worked with similar project sizes in Delphi and java too. Both outperforms C++ in compilation many times on much weaker hardware configuration.
CPallini wrote:
C and C++ are performant. No other language (other than assembly) compares with them. You should know that.
Its not C++ that provides the performance, its the underlying compiler architecture. Lot of other languages can also produce code with good performance (like pascal/Delphi). Its often better to leave assembly generation to the compiler because of optimization. Very few cases reason the use of 'manual assembly'.
CPallini wrote:
While, for instance,
C#syntax becoming simpler?No but I never said that C# is a good language especially in this respect. Take a look at java, its older then C# still preserved its superb simplicity, even the format the sources and arrangement of projects is unified. This is something respectful and exemplary.
CPallini wrote:
Still is compatible.
I wouldn't call it 'optimal'. However I like it (this doesn't means I show apparent disgust for other languages - with the very exception of COBOL).No it isn't compatible at all. Some libraries require very heavy modifications to get it compile with your compiler. Even some new "late" language features like templates work totally different in major compilers (like VC++ and gcc) requiring you to take attention to avoid compiler specific bugs(!!!) in your project. Thats terrible.
-
I'm surprised no hackers from around the world has hacked into Microsoft(R) servers and steal every O.S. source codes or projects (or at least some of them), and them publish them on torrents. But Google, Bing, Yahoo and all those other people filter out those results and/or delete them. There probably has been private court orders of Microsoft vs. some hacker, stealing source. But I'm pretty sure Microsoft knows everything about security then any other security company out there combined, considering you have to send your driver to them to get it signed now. Basically Microsoft probably has there servers extremely hard to break through or breach, they probably have it to where if it detects a breach or unauthorized transfer of specific files, it disconnects the servers and computers and locks them down, terminating the hacking or suspicious signal. Who knows, they are probably smart and keep the internet cord unplugged, considering the fact that government leaks there "state of the art" :rolleyes: F-35 blue prints on the internet, where everyone can see (technically, cause if there's internet, there's hackers), or maybe that's bogus that the government sent out to intentionally trick hackers into thinking they got the "real stuff", but who knows what crazy stuff tech companies do these days.:suss::java:
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
Every OS contains tons of bugs, old bugs go, new ones come with the new features. Still the wast majority of security holes are caused by buggy networking applications and not by the OS itself. The more complex a networking application the more changes you have to have a security hole in your system. (For example a browser is quite a complex piece of software!!!) Anyway, several windows and internet explorer patches followed the windows source leaking, not without reason but because they had to fix a lot of discovered and (I suspect that) known but shelved (!!!) bugs that became obvious for the hackers from the sources!
-
CPallini wrote:
Still it is not a proof. You should compare it to the compilation time of a similar project written with your favourite language and achieving the same performance (if your favourite language could assist you on that).
Its already a proves that that header files suck. On the other hand I worked with similar project sizes in Delphi and java too. Both outperforms C++ in compilation many times on much weaker hardware configuration.
CPallini wrote:
C and C++ are performant. No other language (other than assembly) compares with them. You should know that.
Its not C++ that provides the performance, its the underlying compiler architecture. Lot of other languages can also produce code with good performance (like pascal/Delphi). Its often better to leave assembly generation to the compiler because of optimization. Very few cases reason the use of 'manual assembly'.
CPallini wrote:
While, for instance,
C#syntax becoming simpler?No but I never said that C# is a good language especially in this respect. Take a look at java, its older then C# still preserved its superb simplicity, even the format the sources and arrangement of projects is unified. This is something respectful and exemplary.
CPallini wrote:
Still is compatible.
I wouldn't call it 'optimal'. However I like it (this doesn't means I show apparent disgust for other languages - with the very exception of COBOL).No it isn't compatible at all. Some libraries require very heavy modifications to get it compile with your compiler. Even some new "late" language features like templates work totally different in major compilers (like VC++ and gcc) requiring you to take attention to avoid compiler specific bugs(!!!) in your project. Thats terrible.
pasztorpisti wrote:
On the other hand I worked with similar project sizes in Delphi and java too. Both outperforms C++ in compilation many times on much weaker hardware configuration
I can't believe that (comparing with C language). Anyway your quickly compiled project would suck in performance, compared to a similar C/C++ one.
pasztorpisti wrote:
Its not C++ that provides the performance, its the underlying compiler architecture. Lot of other languages can also produce code with good performance (like pascal/Delphi).
This is a nonsense. The 'underlying compiler architecture' depends on the language. Almost all other programming languages are outperformed by
C++. That's a fact.pasztorpisti wrote:
No it isn't compatible at all
We were not talking about that. We were talking instead about backward compatibility with C.
Veni, vidi, vici.