I am a long-time Redhat user, and am curious as to what might persuade me to switch to one of the other RPM-based distributions such as Mandrake. Can anyone out there list the main differences?
IMHO, Redhat do a much better job at standing behind their distribution. Updates are available, even for relatively old distributions. With Mandrake, the older releases of their distributions are often orphaned, and you end up on an upgrade treadmill. On the other hand, Redhat
expect that a lot of their users will only run.2 releases, and never install a.0 release.
Redhat are a bigger and older company, and I trust
them to stand behind their product more than I trust Mandrake.
Hmmm... I don't understand why compiling things with GCC 3.1 breaks commercial programs. Is it due to incorrect versions of the libstdc++.* libs? If that is the case why not ship the distribution with both compilers installed?
Currently I have about half the stuff on my system compiled with gcc 3.1 and have not had a problem.
The submitter doesn't have a very good grasp of the issues. The compatibility issue is that gcc 3.1 uses a different ABI to older gcc versions.
That is, C++ functions need to have their names "mangled" to handle C++ features such as function overloading, namespaces, and templates; and the name mangling scheme changes from compiler to compiler (largely because they're still trying to get it right)
This means that C++ programs compiled with older compilers will not be able to link against C++ libraries (such as libstdc++) compiled with gcc 3.1. In practice, this is not a problem-- most commerical applications don't dynamically link against any C++ libraries except libstdc++, and Linux distributions typically ship multiple libstdc++ versions. The libstdc++ that ships with gcc 3.1 has the soname (the name that the runtime linker cares about) "libstdc++.so.4" by default, so it will not collide with older versions of the same library (which are named differently)
Re:A bit *too* nice about Qt
on
Qt vs MFC
·
· Score: 1
I was trying to highlight flaws in the evangelism of the original article by citing obvious concrete examples of false claims (containers better than STL, yada yada).
I agree with the overall impression. The article
comes across as cheerleading, and not a balanced comparison. I haven't used MFC, but I find it hard to believe that it's as bad as they make it sound.
The containers
are adequate, but the design is not as clean as STL, and there are some benign warts like "current" nodes in lists, and index based access in lists (I say bening, because one can just ignore these misfeatures).
Re:Why would you use Qt?
on
Qt vs MFC
·
· Score: 1
I think your second point is valid, but your first, not always. If portability is not a requirement, the architecture is not improved by the introduction of an abstraction that doesn't model the problem.
Qt doesn't use abstraction in the same sense of
(for example) AWT. It implements its own widgets
for each target "look and feel". The down-side is that you possibly end up with something that
looks slightly different from the target platform (no emulation is perfect), but you don't suffer the same performance impact or awkwardness (for example, the logical intersection of all targets problem)
Re:A bit *too* nice about Qt
on
Qt vs MFC
·
· Score: 1
Some of the container classes there (QMap?) appear to be somewhat inferior versions of the STL equivalents, in case the C++ library
Qt is pre-STL. Also, it makes different design tradeoffs. The containers are pointer-based,
and are implement using the "inheritance from void*" container idiom which means that the "template bloat" is minimised in these classes.
It makes sense in Qt, since Qt programs use pointers and not values.
These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.
They weren't well-known at the time Qt was written. gcc still ships with a reference counted std::String today.
Why not use std::wstring
It wasn't an option when Qt was written. You're writing this as though Trolltech had full benefits of the ANSI/ISO 1998 standard at the
time they implemented it. Qt was written in 1996.
Burden of proof is on the original poster. I don't see any reason for an inverse relationship between the two. On the contrary, given the similarity between translating words to thoughts and visa versa, I'd expect them to go hand-in-hand.
There are some design choices that could lead to code being both easy to read and easy to write. These choices are easy to make, and language designers will almost always make them, because you
have nothing to lose by improving the readability and writability of the language.
The more difficult decisions are those where there
are tradeoffs- you can add in a feature that would make it easy to write code rapidly, at the expense of readability. Examples of this include weak typing, Perls "default" variable, some of perls regular expression syntax, and obscure or unconventional uses of operators.
But the biggest tradeoff is choice. Choice always improves writability (because you can
write it anyway you want) but hurts readabilty (because there are too many different ways to write it). The "there's more than one way to do it" philosophy makes perl great for the quick-and-dirty, but not so great for large scalable software.
Easy to write doesn't mean shorter, it means easy to translate your thoughts directly into code.
But having the choice of shorter always improves writability (for example, "the default" variable)
Personally, I find Python easy to write because it's nearly identical to the pseudocode I'd write when thinking about a problem.
Python is fairly easy to write by virtue of being a well designed interpreted language. For example, it's much easier to write in python that it is in C++. But there are some problems for which perl is easier to write than Python, in particular those that do a lot of text manipulation (Perls main strength)
So, which human language is inherantly the most readable, oh guru?
I don't know enough about human languages to make informed judgements. However, I can make such judgements about programming languages.
some people find all caps to be inherantly *more* readable.
The problem with
all-caps is that all the letters are the same height. People can and do use the differing heights of lower case letters as visual cues.
This makes it harder for the eye to follow text written in all-caps.
And throwing in pseudo-random sequences doesn't change anything.
Sure it does. Add enough noise to the signal and
finding the signal becomes a difficult task in itself. For example, if we added 3000 such random letters, then the language would be less readable, because the very act of finding the letters would be time consuming. Learning the language wouldn't be that hard (any one who could count to 3000 could do it), but it would be harder to learn to read the language, and reading would demand more of the reader.
As I've pointed out twice already, Russian is entirely unreadable by my standards. The alphabet is gibberish to me, the words mean nothing (except for "goodbye", which I picked up from somewhere), and I don't even know enough to start thinking about the grammar of the language. Does my inability to grasp this language mean anything at all to the native Russian speaker who has grown up with it, and thinks that English is equally incomprehensible?
You can keep repeating it, but it does not in any way contradict what I am saying.
Of course you won't be able to read a language you are not familiar with, and of course the fact that I am ignorant about the Russian language doesn't mean that Russian is unreadable, but it does not follow that all languages are equally readable.
Any language is unreadable if you don't know how to read it, regardless of how readable the code is. If you do know how to read it, then it is no longer an "unreadable" language, and any lack of readability is due to the writer, not the language.
This is all true, but it doesn't alter the fact that
one language can be more readable than another.
If you do know how to read it, then it is no longer an "unreadable" language, and any lack of readability is due to the writer, not the language.
Not necessarily. There's a common political correctness that says that all languages must be equally readable. This is a fallacy. There are factors in a language that can make it less readable. It's not a difficult exercise to contemplate language features that would hurt readability (requiring all caps is one example that would make the language less readable, for example. So would alternating every second letter with characters from a pseudo-random sequence.)
All the code I wrote that is easy to read, was code that was easy to write.
That in no way contradicts the fact that there is a readability/writability tradeoff in designing a language. All it says is that you haven't observed such a tradeoff in the process of writing code.
Perl is not just a little language for one-off scripts. It can be used for real, big, major, mission-critical applications.
Perls design tradeoffs are writable over readable, rapid development versus safety.
Wherever there's a choice to make the language
easier to write or easier to read, Perl chooses
easier to write. Wherever there's a choice between flexibility and reliability, perl chooses
flexibility.
All the tradeoffs Perl makes are an advantage for writing quick and dirty applications, and a drawback for writing large scale, robust applications.
That doesn't mean that it's not possible to write
large maintainable programs in that language, it
just means that it was not designed to the criteria that favor developing such applications.
good coders can write readable code in any language.
One important tradeoff is that between writability and readability. The two conflicting philosophies are:
Code should be easy to write
Code should be easy to read
You simply can't have it both ways, because to allow concise expressive syntax is to allow ambiguity. Perl consistently chooses writability over readability. A language that prefers readability over writability will require more effort to code in, but be more readable (Python is a good example of such a language).
How about: a good coder can write readable code in any readable language?
Well that's his point, isn't it ? That a language can be intrinsically more or less readable than another language. Once you accept the possibility of an "unreadable" language, there's a legitimate question of the degree of readability.
Any language is hard to read if you do not know it . "Readable" assumes a level of competence on the part of the programmer reading the code... e.g. if you do not know assembly, asm code looks pretty unreadable... So saying perl is "unreadable" to me says more about the programmer...
You seem to be afflicted with a certain sort of political correctness where everything has to be "equally" readable. It's simply not true. For example, a good assembly programmer might be able to read code in a hex editor, but they can't do so as quickly and easily as a python programmer can read a python program that does the same thing. There are a number of factors that can make a language intrinsically more or less readable.
The maintainability of a language seems weakly related to individual languages. Most of the maintainabilty qualities of a product will spring from the all-too-often overlooked Planning, Design, and Discipline of the developers that worked on it!
I'll allow that Perl can really let you shoot yourself in
There's another tradeoff that you don't go into, which does affect maintainability. It's essentially an effort/maintainability trade.
There are two conflicting principles:
Code should be easy to read
Code should be easy to write
Python fairly consistently chooses readability, while perl consistently chooses writability. This
makes python moderately more effort intensive than perl, which is why perl is often preferred for quick and dirty sys admin scripts.
As for design and planning-- yes, sure that's important, but it's not the only factor.
There are other languages like Eiffel that don't
have the terse flavor of languages with C
like syntax, but are more readable.
I'll allow that Perl can really let you shoot yourself in the foot as far as maintainablity goes, but what languages aren't like this? Especially beloved C++?
C++ is closer the "code should be easy to read" end of the spectrum than Perl. Perl gives you much more expressive power, and makes it much simpler to produce write-only code.
I think that's too negative. 3.0 might not have been 'redhat-approved', but it definitely was an important milestone for gcc and represented large improvements.
I am not disputing that there were some tremendous improvements. The gcc 3.0 compiler laid down the foundation for gcc 3.1 which is a very good compiler (the first gcc release I'm really happy with)
However, gcc 3.0 wasn't merely not "Redhat approved", it was unacceptable as a distribution compiler because it couldn't correctly compile KDE. I am not attacking the gcc development team,
but it is important to note that Linux distributors have tougher release criteria than the gcc project, so it's not always practical for
them to use whatever the gcc project decides to release. The gcc project had the option of releasing a compiler that couldn't compile glibc on ALPHA or KDE on anyhing, Redhat didn't.
Regarding the other gcc releases-- the 3.0 series all have the same ABI bug that I was referring to.
gcc 3.1 is the first release that is suitable for
more general use, and as I said, I don't dispute that it's a very good release.
IIRC the gcc 2.95 release couldn't compile glibc on Alpha platforms. Shipping a compiler which can't even compile the C library is a Bad Thing. Hence the need for Red Hat's 2.96 patch release.
I'd forgotten that, thanks for pointing it out. I think this is one of many examples of the why a fork
is not such a bad thing: Redhat simply has different goals and needs from the gcc project. In particular, Redhat needs the compiler to compile a lot of software on a lot of platforms.
One only needs look at the problems with gcc 3.0 to see that using the current production release
is not always an option (let alone the best option) for distributors.
No, Redhat were wrong. At the time RHL 7.0 was released, the production version of gcc was 2.95.something. That would have been the correct compiler to bundle with RHL 7.
No, Redhat were right. gcc 2.95 was released July 1999. It took the gcc project 2 years to release the ill-fated 3.0 compiler, and nearly 3 years to get out a major release that was good enough to use as a distribution compiler. One would hope for a more aggressive release schedule given that the ANSI/ISO C++ standard was released at the time of the EGCS fork, and there were major standards compliance problems with gcc 2.95.
The maintainers of gcc pointed out that development branches of gcc are not intended for production purposes and that any software which is compiled with the forthcoming, stable version of gcc (gcc 3.0) would simply not run on Red Hat 7.
What the article omits is that Redhat were right,
and the gcc developers were wrong. Sure, you couldn't run gcc 3.0 software on Redhat, but so what ? gcc 3.0 was a botched, DOA release, containing an embarrassing bug that prevented it from compiling KDE correctly, which is why it was "skipped" as a distribution compiler. Redhat havereleased an extended 7.x series waiting for an acceptable distribution compiler (gcc 3.1).
The gcc team are within their rights releasing something that isn't known to compile a package as important as gcc. Redhat, on the other hand, have
to make sure that their distribution compiler can build hundreds of packages. In hindsight, it's very
clear that Redhats move on gcc was the right one.
Actually buffer overrun bugs would be a bigger worry.
I didn't have those problems when I wrote C because I had a bunch of macros that handled it all for me. But other folk seemed to have difficulties...
Again, most buffer overruns are a result of unchecked index based access, or static buffers that turn out to be too small. Neither of these are an issue with the C++ code I write-- you use STL algorithms, and iterators, and dynamic vectors as opposed to fixed size static arrays.
If there are substantial problems with large numbers of developers using their tools poorly, you have a much bigger problem on your hands than choice of language.
The basis on which the decision would be made is programmer productivity, the quality of the end result and the cost of ongoing maintenance.
Right. I think the main thing you get moving to java is a tradeoff -- you lose quality in the end result, but increase productivity. You're right that you can speed up an application by throwing more hardware at it, but this requires all your users to do the same. Actually, the fact that *you* can throw more hardware at the problem is an argument in favor of a system with tougher compile requirements and lower runtime requirements.
It is actually quite easy to override the automatic garbage collection, you simply call the dispose method explicitly when you have finished with an object. If you forget you might end up with the garbage collection getting triggered, but that is a much smaller penalty than a memory leak.
if you're having serious problems with memory leaks
in C++ based projects, then you not only have incompetent developers, you have a project management problem. Memory leaks nearly always boil down to severe problems with coding style.
Java is not a silver bullet either, and it will not save you from incompetent project managers and developers.
C++ was from the start a language with major difficulties. C had a bunch of problems that could only be fixed by taking bad ideas out of C,
Nonsense. C was, and still is one of the most successful programming languages in existance. All programming languages make different tradeoffs, and C consistently makes tradeoffs in favor of simplicity and performance.
C++ took nothing out and added a lot more complexity in.
In practice, one can get by without using very much of the standard C library for the most part.
Java and C# both started from the premise that people wanted a good language for writing new code in and absolute backwards compatibility was not their principle concern.
Wrong. Java and C# made completely different design tradeoffs to C++. The move was towards more runtime flexibility and less compile time checking. The reason for this is that there were certain application domains where these tradeoffs were appropriate. It has nothing to do with trying to design a "better" language than C++.
As with most posters who insist that one tool is "better" than the other, you make the mistake of confusing design tradeoffs with a free lunch.
As a result C# has a switch statement that allows a compiler to catch the common programming error of forgetting the break statement, Java likewise avoids that problem (slightly differently).
switch statements are rarely necessary, and the programming error you cite is not common if you rarely use switch.
Both C# and Java eliminate buffer overrun errors which are the #1 cause of security problems and so it goes on.
C++ does not have a problem with buffer overrun errors if you use it sensibly. The main causes of errors -- out of bounds array indexing, and static arrays -- are addressed by dynamic container classes, and STL algorithms (as opposed to writing loops). The nice thing about using the STL algorithm approach is it eliminates the cause of the problem (logic errors with loop bounds) rather than just treating symptoms.
is that you don't have the tortured aaa::b.c->d.e->g (x,y) syntax
Java has its own issues with syntax, which is pretty funny given that you're claiming it wasn't burdened by backward compatibility. The syntax is as bad as C++, but at least C++ has the excuse that it's C compatible. Compared to Eiffel or python, java syntax is a bad joke.
As for the efficiency question, C# is certainly as fast as C++ if you use the compile on install option and for numeric stuff is quite a bit better as the compilers are optimised for the specific intel processors.
do you have any supporting evidence for this claim ? VM vs native code are not the only performance issues that Java and C# have.
Which is handled by garnage collection.
I would much rather pay 10% extra for faster processing hardware than 20% extra on my programming budget to have people's memory allocation bugs discovered and fixed.
If you're foolish enough to make decisions like this without knowing anything about the context, there's a good reason you aren't the one making these decisions (just a guess)
As for "memory allocation bugs", I rarely have memory allocation bugs in my C++ code. if you really think memory allocation bugs are the major issue with C++ development, you don't know C++ very well. HTH,
The rest of your comment is snipped because you did not provide "statistics" for crimes other than homicide, and so I could not comment on, say, homicide vs. robbery
In case you've forgotten, the topic of this discussion is software piracy. I claim that conviction rates for software piracy are less than 2/3. Would you like to contest that claim ?
BTW, I'm not going to chase down reference to prove that I'm right. If you're prepared to look up the facts, you'll work it out for yourself. If you're willfuly ignorant, then I can't help you.
Dude, I don't think you know nearly enough about Chinese life to make those points. In China, the military-run government murders political dissidents tens of thousands of times a year,
The government is not "military run", and "tens of thousands" is the total number of annual executions (out of a population of 1.3billion), not the number of political dissidents who are executed.
Not necessarily of the person who committed the crime however, as recent DNA testing has shown. Until we get 100% conviction of the correct person we should not be satisfied.
Your dissatisfaction, while well founded is somewhat orthogonal to my point, since I'm discussing conviction rates. I suspect that it would be
a fairly safe bet that the vast majority of convictions are of the perpetrator.
Slashdot Mirror
IMHO, Redhat do a much better job at standing behind their distribution. Updates are available, even for relatively old distributions. With Mandrake, the older releases of their distributions are often orphaned, and you end up on an upgrade treadmill. On the other hand, Redhat expect that a lot of their users will only run .2 releases, and never install a .0 release.
Redhat are a bigger and older company, and I trust them to stand behind their product more than I trust Mandrake.
Currently I have about half the stuff on my system compiled with gcc 3.1 and have not had a problem.
The submitter doesn't have a very good grasp of the issues. The compatibility issue is that gcc 3.1 uses a different ABI to older gcc versions. That is, C++ functions need to have their names "mangled" to handle C++ features such as function overloading, namespaces, and templates; and the name mangling scheme changes from compiler to compiler (largely because they're still trying to get it right) This means that C++ programs compiled with older compilers will not be able to link against C++ libraries (such as libstdc++) compiled with gcc 3.1. In practice, this is not a problem-- most commerical applications don't dynamically link against any C++ libraries except libstdc++, and Linux distributions typically ship multiple libstdc++ versions. The libstdc++ that ships with gcc 3.1 has the soname (the name that the runtime linker cares about) "libstdc++.so.4" by default, so it will not collide with older versions of the same library (which are named differently)
I agree with the overall impression. The article comes across as cheerleading, and not a balanced comparison. I haven't used MFC, but I find it hard to believe that it's as bad as they make it sound. The containers are adequate, but the design is not as clean as STL, and there are some benign warts like "current" nodes in lists, and index based access in lists (I say bening, because one can just ignore these misfeatures).
Qt doesn't use abstraction in the same sense of (for example) AWT. It implements its own widgets for each target "look and feel". The down-side is that you possibly end up with something that looks slightly different from the target platform (no emulation is perfect), but you don't suffer the same performance impact or awkwardness (for example, the logical intersection of all targets problem)
Qt is pre-STL. Also, it makes different design tradeoffs. The containers are pointer-based, and are implement using the "inheritance from void*" container idiom which means that the "template bloat" is minimised in these classes. It makes sense in Qt, since Qt programs use pointers and not values.
These are well-known design flaws with both approaches, relating to efficiency, thread safety, etc.
They weren't well-known at the time Qt was written. gcc still ships with a reference counted std::String today.
Why not use std::wstring
It wasn't an option when Qt was written. You're writing this as though Trolltech had full benefits of the ANSI/ISO 1998 standard at the time they implemented it. Qt was written in 1996.
There are some design choices that could lead to code being both easy to read and easy to write. These choices are easy to make, and language designers will almost always make them, because you have nothing to lose by improving the readability and writability of the language.
The more difficult decisions are those where there are tradeoffs- you can add in a feature that would make it easy to write code rapidly, at the expense of readability. Examples of this include weak typing, Perls "default" variable, some of perls regular expression syntax, and obscure or unconventional uses of operators.
But the biggest tradeoff is choice. Choice always improves writability (because you can write it anyway you want) but hurts readabilty (because there are too many different ways to write it). The "there's more than one way to do it" philosophy makes perl great for the quick-and-dirty, but not so great for large scalable software.
Easy to write doesn't mean shorter, it means easy to translate your thoughts directly into code.
But having the choice of shorter always improves writability (for example, "the default" variable)
Personally, I find Python easy to write because it's nearly identical to the pseudocode I'd write when thinking about a problem.
Python is fairly easy to write by virtue of being a well designed interpreted language. For example, it's much easier to write in python that it is in C++. But there are some problems for which perl is easier to write than Python, in particular those that do a lot of text manipulation (Perls main strength)
I don't know enough about human languages to make informed judgements. However, I can make such judgements about programming languages.
some people find all caps to be inherantly *more* readable.
The problem with all-caps is that all the letters are the same height. People can and do use the differing heights of lower case letters as visual cues. This makes it harder for the eye to follow text written in all-caps.
And throwing in pseudo-random sequences doesn't change anything.
Sure it does. Add enough noise to the signal and finding the signal becomes a difficult task in itself. For example, if we added 3000 such random letters, then the language would be less readable, because the very act of finding the letters would be time consuming. Learning the language wouldn't be that hard (any one who could count to 3000 could do it), but it would be harder to learn to read the language, and reading would demand more of the reader.
As I've pointed out twice already, Russian is entirely unreadable by my standards. The alphabet is gibberish to me, the words mean nothing (except for "goodbye", which I picked up from somewhere), and I don't even know enough to start thinking about the grammar of the language. Does my inability to grasp this language mean anything at all to the native Russian speaker who has grown up with it, and thinks that English is equally incomprehensible?
You can keep repeating it, but it does not in any way contradict what I am saying. Of course you won't be able to read a language you are not familiar with, and of course the fact that I am ignorant about the Russian language doesn't mean that Russian is unreadable, but it does not follow that all languages are equally readable.
This is all true, but it doesn't alter the fact that one language can be more readable than another.
If you do know how to read it, then it is no longer an "unreadable" language, and any lack of readability is due to the writer, not the language.
Not necessarily. There's a common political correctness that says that all languages must be equally readable. This is a fallacy. There are factors in a language that can make it less readable. It's not a difficult exercise to contemplate language features that would hurt readability (requiring all caps is one example that would make the language less readable, for example. So would alternating every second letter with characters from a pseudo-random sequence.)
That in no way contradicts the fact that there is a readability/writability tradeoff in designing a language. All it says is that you haven't observed such a tradeoff in the process of writing code.
Perls design tradeoffs are writable over readable, rapid development versus safety. Wherever there's a choice to make the language easier to write or easier to read, Perl chooses easier to write. Wherever there's a choice between flexibility and reliability, perl chooses flexibility. All the tradeoffs Perl makes are an advantage for writing quick and dirty applications, and a drawback for writing large scale, robust applications.
That doesn't mean that it's not possible to write large maintainable programs in that language, it just means that it was not designed to the criteria that favor developing such applications.
One important tradeoff is that between writability and readability. The two conflicting philosophies are:
You simply can't have it both ways, because to allow concise expressive syntax is to allow ambiguity. Perl consistently chooses writability over readability. A language that prefers readability over writability will require more effort to code in, but be more readable (Python is a good example of such a language).
Well that's his point, isn't it ? That a language can be intrinsically more or less readable than another language. Once you accept the possibility of an "unreadable" language, there's a legitimate question of the degree of readability.
You seem to be afflicted with a certain sort of political correctness where everything has to be "equally" readable. It's simply not true. For example, a good assembly programmer might be able to read code in a hex editor, but they can't do so as quickly and easily as a python programmer can read a python program that does the same thing. There are a number of factors that can make a language intrinsically more or less readable.
There's another tradeoff that you don't go into, which does affect maintainability. It's essentially an effort/maintainability trade. There are two conflicting principles:
Python fairly consistently chooses readability, while perl consistently chooses writability. This makes python moderately more effort intensive than perl, which is why perl is often preferred for quick and dirty sys admin scripts. As for design and planning-- yes, sure that's important, but it's not the only factor. There are other languages like Eiffel that don't have the terse flavor of languages with C like syntax, but are more readable.
I'll allow that Perl can really let you shoot yourself in the foot as far as maintainablity goes, but what languages aren't like this? Especially beloved C++?
C++ is closer the "code should be easy to read" end of the spectrum than Perl. Perl gives you much more expressive power, and makes it much simpler to produce write-only code.
I am not disputing that there were some tremendous improvements. The gcc 3.0 compiler laid down the foundation for gcc 3.1 which is a very good compiler (the first gcc release I'm really happy with)
However, gcc 3.0 wasn't merely not "Redhat approved", it was unacceptable as a distribution compiler because it couldn't correctly compile KDE. I am not attacking the gcc development team, but it is important to note that Linux distributors have tougher release criteria than the gcc project, so it's not always practical for them to use whatever the gcc project decides to release. The gcc project had the option of releasing a compiler that couldn't compile glibc on ALPHA or KDE on anyhing, Redhat didn't.
Regarding the other gcc releases-- the 3.0 series all have the same ABI bug that I was referring to. gcc 3.1 is the first release that is suitable for more general use, and as I said, I don't dispute that it's a very good release.
I'd forgotten that, thanks for pointing it out. I think this is one of many examples of the why a fork is not such a bad thing: Redhat simply has different goals and needs from the gcc project. In particular, Redhat needs the compiler to compile a lot of software on a lot of platforms. One only needs look at the problems with gcc 3.0 to see that using the current production release is not always an option (let alone the best option) for distributors.
No, Redhat were right. gcc 2.95 was released July 1999. It took the gcc project 2 years to release the ill-fated 3.0 compiler, and nearly 3 years to get out a major release that was good enough to use as a distribution compiler. One would hope for a more aggressive release schedule given that the ANSI/ISO C++ standard was released at the time of the EGCS fork, and there were major standards compliance problems with gcc 2.95.
The maintainers of gcc pointed out that development branches of gcc are not intended for production purposes and that any software which is compiled with the forthcoming, stable version of gcc (gcc 3.0) would simply not run on Red Hat 7.
What the article omits is that Redhat were right, and the gcc developers were wrong. Sure, you couldn't run gcc 3.0 software on Redhat, but so what ? gcc 3.0 was a botched, DOA release, containing an embarrassing bug that prevented it from compiling KDE correctly, which is why it was "skipped" as a distribution compiler. Redhat havereleased an extended 7.x series waiting for an acceptable distribution compiler (gcc 3.1).
The gcc team are within their rights releasing something that isn't known to compile a package as important as gcc. Redhat, on the other hand, have to make sure that their distribution compiler can build hundreds of packages. In hindsight, it's very clear that Redhats move on gcc was the right one.
Again, most buffer overruns are a result of unchecked index based access, or static buffers that turn out to be too small. Neither of these are an issue with the C++ code I write-- you use STL algorithms, and iterators, and dynamic vectors as opposed to fixed size static arrays.
If there are substantial problems with large numbers of developers using their tools poorly, you have a much bigger problem on your hands than choice of language.
Right. I think the main thing you get moving to java is a tradeoff -- you lose quality in the end result, but increase productivity. You're right that you can speed up an application by throwing more hardware at it, but this requires all your users to do the same. Actually, the fact that *you* can throw more hardware at the problem is an argument in favor of a system with tougher compile requirements and lower runtime requirements.
It is actually quite easy to override the automatic garbage collection, you simply call the dispose method explicitly when you have finished with an object. If you forget you might end up with the garbage collection getting triggered, but that is a much smaller penalty than a memory leak.
if you're having serious problems with memory leaks in C++ based projects, then you not only have incompetent developers, you have a project management problem. Memory leaks nearly always boil down to severe problems with coding style. Java is not a silver bullet either, and it will not save you from incompetent project managers and developers.
Nonsense. C was, and still is one of the most successful programming languages in existance. All programming languages make different tradeoffs, and C consistently makes tradeoffs in favor of simplicity and performance.
C++ took nothing out and added a lot more complexity in.
In practice, one can get by without using very much of the standard C library for the most part.
Java and C# both started from the premise that people wanted a good language for writing new code in and absolute backwards compatibility was not their principle concern.
Wrong. Java and C# made completely different design tradeoffs to C++. The move was towards more runtime flexibility and less compile time checking. The reason for this is that there were certain application domains where these tradeoffs were appropriate. It has nothing to do with trying to design a "better" language than C++.
As with most posters who insist that one tool is "better" than the other, you make the mistake of confusing design tradeoffs with a free lunch.
As a result C# has a switch statement that allows a compiler to catch the common programming error of forgetting the break statement, Java likewise avoids that problem (slightly differently).
switch statements are rarely necessary, and the programming error you cite is not common if you rarely use switch.
Both C# and Java eliminate buffer overrun errors which are the #1 cause of security problems and so it goes on.
C++ does not have a problem with buffer overrun errors if you use it sensibly. The main causes of errors -- out of bounds array indexing, and static arrays -- are addressed by dynamic container classes, and STL algorithms (as opposed to writing loops). The nice thing about using the STL algorithm approach is it eliminates the cause of the problem (logic errors with loop bounds) rather than just treating symptoms.
is that you don't have the tortured aaa::b.c->d.e->g (x,y) syntax
Java has its own issues with syntax, which is pretty funny given that you're claiming it wasn't burdened by backward compatibility. The syntax is as bad as C++, but at least C++ has the excuse that it's C compatible. Compared to Eiffel or python, java syntax is a bad joke.
As for the efficiency question, C# is certainly as fast as C++ if you use the compile on install option and for numeric stuff is quite a bit better as the compilers are optimised for the specific intel processors.
do you have any supporting evidence for this claim ? VM vs native code are not the only performance issues that Java and C# have.
If you're foolish enough to make decisions like this without knowing anything about the context, there's a good reason you aren't the one making these decisions (just a guess)
As for "memory allocation bugs", I rarely have memory allocation bugs in my C++ code. if you really think memory allocation bugs are the major issue with C++ development, you don't know C++ very well. HTH,
In case you've forgotten, the topic of this discussion is software piracy. I claim that conviction rates for software piracy are less than 2/3. Would you like to contest that claim ?
BTW, I'm not going to chase down reference to prove that I'm right. If you're prepared to look up the facts, you'll work it out for yourself. If you're willfuly ignorant, then I can't help you.
The government is not "military run", and "tens of thousands" is the total number of annual executions (out of a population of 1.3billion), not the number of political dissidents who are executed.
Your dissatisfaction, while well founded is somewhat orthogonal to my point, since I'm discussing conviction rates. I suspect that it would be a fairly safe bet that the vast majority of convictions are of the perpetrator.