Earlier quoted context omitted.
> they still lagged gcc Isn't the "they" in this thread gcc, or did I misread something?
I took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".
“It is never a compiler error”
121–130 of 280 posts
Re: “It is never a compiler error”
#122Re: “It is never a compiler error”
#123"The compiler did not have a bug. The compiler never had a bug. The bug was always in the programmer's code and usually in their understanding of the language... It was caused by a misunderstanding of the way arguments to unprototyped functions were automatically promoted..." - I'd say the bug is neither in the compiler nor in their understanding of the language but in the language itself then. Why on Earth do we nee…
Backwards compatibility and uses that are niche but vital. Programmers insist on using parts of languages long after they're discovered to be bad ideas, or when they're included in the language for very specific use cases that aren't relevant to 99% of programmers. Those parts of languages are catnip for "real" programmers.
"You'd be foolish to use this technique, and you'd have to be stupid to need it for this application."
"That's a matter of opinion, but it's fact that I'd have to be clever to make it work."
Can't argue with someone who thinks like that.
Re: “It is never a compiler error”
#124"The compiler did not have a bug. The compiler never had a bug. The bug was always in the programmer's code and usually in their understanding of the language... It was caused by a misunderstanding of the way arguments to unprototyped functions were automatically promoted..." - I'd say the bug is neither in the compiler nor in their understanding of the language but in the language itself then. Why on Earth do we nee…
Re: “It is never a compiler error”
#125Earlier quoted context omitted.
I took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".
Oh, I thought the GP was accusing GCC devs of reckless optimizations. But UBSan is a clang project, so maybe you're interpretation makes more sense. Very confusing thread. :)
Note that UBSan is (mostly? totally? originally?) a Google project and it's been ported to both clang and gcc.
Re: “It is never a compiler error”
#126http://envisage-project.eu/proving-android-java-and-python-s...
Re: “It is never a compiler error”
#127Earlier quoted context omitted.
You're misidentifying the attitude. The problem is that Bubble Sort is a terrible algorithm, there's no reason not to use Insertion Sort or better instead except for some reason CS programs still inflict BS on students so that's what they remember when they just need to sort something. http://warp.povusers.org/grrr/bubblesort_eng.html http://warp.povusers.org/grrr/bubblesort_misconceptions.html (Bubble sort is not gr…
To the second link "Bubble sort always performs n-1 passes through the data (where n is the amount of elements), and it always performs (n-1)+(n-2)+...+1 comparisons regardless of how the data is organized to begin with." That is just false. 1 pass and n-1 comparisons then stops for already sorted data is what you get. An implementation that doesn't show that characteristic has been either deliberately or accidentall…
What about insertion sort? Which always performs fewer comparisons and swaps than bubble sort for any array, by the way.
Re: “It is never a compiler error”
#128Walter was quick with a fix. Sometimes it is the compiler, but usually it's not.
Re: “It is never a compiler error”
#129"The compiler did not have a bug. The compiler never had a bug. The bug was always in the programmer's code and usually in their understanding of the language... It was caused by a misunderstanding of the way arguments to unprototyped functions were automatically promoted..." - I'd say the bug is neither in the compiler nor in their understanding of the language but in the language itself then. Why on Earth do we nee…
Have someone sit down with you and explain how slow computers were in the 1970's. C won because it could be efficiently implemented on everything, produce better code than pretty much anything else, and still produce effective software quickly. And everything after that is a network effect because of all the inherited C.
Your complaint has been repeated ad nauseum by literally generations of programmers who simply can't imagine why everyone did things this way, and who then go on to productive careers writing or integrating or just living with software still written in C.
If you want to change the world, you need to stop pontificating and roll up your sleeves. There's a whole lot of code to write in rust, or whatever your particular brand of zealotry demands.
Re: “It is never a compiler error”
#130It was fixed in Java 1.0.3.