@Kian said:
It's just too bad it doesn't compile
You're right, it doesn't. I didn't have a C compiler handy at the moment and it was written in a rush. The intention was to return an int and to assing the newly created pointer to the old pointer.
@Mason_Wheeler said:
Then it should handle them differently, as a file type rather than a pointer.
Its a special type of pointer. FILE is already a type. The FILE * semantic actually tells you that it is a FILE pointer. FILE is the type. * signifies that its a pointer to a file. What would actually change if you omit the pointer? Nothing. Virtually no one tries to use free()
on a file pointer. It is not even an issue.
@Mason_Wheeler said:
Can you really?
Okay, I lied, two lines:
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
I didn't account for the first line, which handles the case of an empty list.
@Mason_Wheeler said:
Is it possible to achieve Quicksort's performance characteristics in one line of Haskell?
I haven't measured the code for speed (or claimed that it was faster for that matter). Do you have a large list of randomly generated numbers and enough time? Hold on, I'll fetch my beer.
@NeighborhoodButcher said:
Because you have to remember to use it on every execution path which necessitates the deallocation of memory.
Doing fclose()
on a file is not an issue amongst C programmers. Show me a large security hole that has resulted from it. Is not more complicated than doing .close()
on a file object. You are arguing non issues.
@NeighborhoodButcher said:
Because the guys who knew how to make an OS, were the guys who already had experience in it. And guess which language the had to get their experience with? That is the essence of the C vicious circle.
So Donald Knuth, Theo DeRaadt, Linus Torvalds and Bertrand Meyer are all wrong to distrust C++ and you are right, then?
@NeighborhoodButcher said:
Tizen
You mean the one that is based on the Linux kernel, which in turn is written in C? ( https://en.wikipedia.org/wiki/Tizen ). Given how unenthusiastic you are about C, why haven't you reimplement the rest of the kernel in C++?. I though that was the meat of your argument, that you know what is it like to implement an OS from the ground up in C++.
But regardless, you must have some killer performance measurements of what writing those not-quite-userspace parts of the OS in C++11 are. Can you share them with us?
@NeighborhoodButcher said:
The point is that C++ allows for optimizations, which are impossible to do in C. You can argue that's the compiler, but without the language support, the compiler wouldn't be able to do those. And a C compiler can't, as explained in that book.
Some optimizations are. Also some aren't. C++ has worse spatial locality than C. In fact so does anything object-oriented.
@NeighborhoodButcher said:
Oh yes, because it's better to rely on some 3rd party tool to show you your code is broken, instead of a compiler telling you that upfront.
Compilers can do that too now. I was hesitant to mention sanitizer routines since I don't know if they exist in GCC. On clang -fsanitize=< memory/address/etc > would do exactly that.
@NeighborhoodButcher said:
In other words, you know shit about C++, yet you dare compare it with C and give absolute statements, like it not being memory safe.
I wasn't aware of a C++11 feature, which uses object oriented parts to do its job. Exception handling has an overhead. Again...do you use object oriented constructs in the low level parts of the kernel? A little googling tells me that this is not the case. Because your operating system has those parts implemented in C. Because it uses the Linux kernel and that is written in C. You claim that you can get much better performance writing the entire OS in C++? Fine, so be prepared to backup your claims instead of restorting to angry outbursts against the C language or claiming that you are the only one in possesion of the truth.
Yes, I read the link you posted.C++ can qsort()
faster than C, but that doesn't prove that its faster for coding operating systems. This is why I brought up haskell. Generating a 10000 element list and asking for the first element is faster than both C and C++ because it computes fewer things. That doesn't make it faster for the general case and I wouldn't even want to see the code that generates.
The claim that C has to evolve and be replaced is a valid one. The claim that is a bad language is, at best a dubious one. The claim that C++ can replace it for ALL THE THINGS has to have some foundations. And instead of assuming that the rest of the world is idiotic and insane for using C, and going on lengthy and angry triades, calm down and try to provide evidence for your claims. If they are so compelling as you say they are, you will find no opposition.