Re: [SLE] Gnome disappointment
Allen,
Umm.. How do you get that? It is rather the other way around. C++ apps are generally slower. Why is the Linux kernel written in C? If C++ was faster, then would that not have made sense?
Actually, either can be faster/slower than the other, depending on the optimization used and other relevant factors.
The fact is actually that one cannot really say that the one language is faster than the other, becuase the speed all depends on the implementation and what you want to do.
A myth usually shown false with a little assembler.
That's irrelevant, because code written in assembly has little or no portability to other platforms and often marginal portability to other processors in the same family. And programmer productivity writing in assembler is abysmal.
LOL!
Just as Java's dynamic native code generation can perform optimizations no static C++ optimizer can, assembly code can only be statically optimized. That limits the ways and degrees to which it can be optimized for real-world dynamic situations. There's some code that can be statically and universally optimized (memcpy, perhaps) but much that cannot.
I have an idea, let's rewrite the kernel in VB.NET. :) -- kai ponte www.perfectreign.com linux - genuine windows replacement part
On Wednesday 09 November 2005 10:29 am, Kai Ponte wrote:
Allen,
Umm.. How do you get that? It is rather the other way around. C++ apps are generally slower. Why is the Linux kernel written in C? If C++ was faster, then would that not have made sense?
Actually, either can be faster/slower than the other, depending on the optimization used and other relevant factors.
The places where C++ code can be faster are not relevant to a lot of applications. They mostly apply to number crunching and chains of mathematical expressions. If I get motivated, I may try to fish out an example. As for why the kernel is written in C++. 1) Linus doesn't know how to use C++ correctly 2) C++ was not mature when the linux project was started 3) There's a certain amount of chicken and egg problem in that C++ relies on functionality provided by the kernel. Of course all that is done in C within the kernel could be done with C++. The differences between ANSI C and the C subset of C++ are trivial. This may be of interest: http://netlab.ru.is/exception/LinuxCXX.shtml Steven
On Wednesday 09 November 2005 11:32 am, Steven T. Hatton wrote:
The places where C++ code can be faster are not relevant to a lot of applications. They mostly apply to number crunching and chains of mathematical expressions. If I get motivated, I may try to fish out an example.
As for why the kernel is written in C++. 1) Linus doesn't know how to use C++ correctly 2) C++ was not mature when the linux project was started 3) There's a certain amount of chicken and egg problem in that C++ relies on functionality provided by the kernel. Of course all that is done in C within the kernel could be done with C++. The differences between ANSI C and the C subset of C++ are trivial. This is another discussion, maybe we should take it to programming. We discussed rewriting parts of a commercial Unix kernel in C++. I don't want to degenerate into a C/C++ discussion, but in general a C compiler is able to optimize better than a C++ compiler. Another issue with C++ when dealing with a kernel is its libraries. When you compile a kernel, you are completely stand-alone. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 09 November 2005 11:32 am, Steven T. Hatton wrote:
The places where C++ code can be faster are not relevant to a lot of applications. They mostly apply to number crunching and chains of mathematical expressions. If I get motivated, I may try to fish out an example.
This isn't completely correct. There are some more mundane places were you can really exploit C++ features. A disciplined and skilled C++ programmer in the habit of using the most efficient coding styles will produce code that has few pointers, avoids redundant memory allocations and cleans up after itself thus not needing garbage collection. My opinion of garbage collection in C++ is that a C++ programmer needs garbage collection like an alcoholic needs wiskey. I've taken 200 lines of C-style code and reduced it to a dozen lines of C++. Most of those lines were of the form out << "The input provided was stupid..." << "\"; Yes, I know about std::endl. Don't use it on every line. It makes unnecessary calls to flush. only use it when you really want to call flush. C++ has huge potential. One of its greatest shotcomings is the subornness on the part of the established C++ community. The are too quick to reject any form of criticism. OTOH, there are people doing some good things. Though I don't like everything about Qt, it is one of the nicest toolkits I've seen. And Qt 4 is markedly better than Qt3. Right now I'm spending my days arm wrestling Mathematica. Talk about a bizarre language. For example f[g[x_]] ^:= -g[x] is assigning what is called an up-value to g. And it just gets strangerer and strangerer from there. Steven
On Wednesday 09 November 2005 2:00 pm, Steven T. Hatton wrote:
This isn't completely correct. There are some more mundane places were you can really exploit C++ features. A disciplined and skilled C++ programmer in the habit of using the most efficient coding styles will produce code that has few pointers, avoids redundant memory allocations and cleans up after itself thus not needing garbage collection. My opinion of garbage collection in C++ is that a C++ programmer needs garbage collection like an alcoholic needs wiskey. Well said.
I've taken 200 lines of C-style code and reduced it to a dozen lines of C++. Most of those lines were of the form What is the assembler output? Did it generate more efficiant code, or did you just make the code more maintainable.
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 09 November 2005 11:32 am, Steven T. Hatton wrote:
The places where C++ code can be faster are not relevant to a lot of applications. They mostly apply to number crunching and chains of mathematical expressions. If I get motivated, I may try to fish out an example.
This isn't completely correct. There are some more mundane places were you can really exploit C++ features. A disciplined and skilled C++ programmer in the habit of using the most efficient coding styles will produce code that has few pointers, avoids redundant memory allocations and cleans up after itself thus not needing garbage collection. My opinion of garbage collection in C++ is that a C++ programmer needs garbage collection like an alcoholic needs wiskey.
I've taken 200 lines of C-style code and reduced it to a dozen lines of C++. Most of those lines were of the form
out << "The input provided was stupid..." << "\";
Yes, I know about std::endl. Don't use it on every line. It makes unnecessary calls to flush. only use it when you really want to call flush. C++ has huge potential. One of its greatest shotcomings is the subornness on the part of the established C++ community. The are too quick to reject any form of criticism. OTOH, there are people doing some good things. Though I don't like everything about Qt, it is one of the nicest toolkits I've seen. And Qt 4 is markedly better than Qt3.
Right now I'm spending my days arm wrestling Mathematica. Talk about a bizarre language. For example f[g[x_]] ^:= -g[x] is assigning what is called an up-value to g. And it just gets strangerer and strangerer from there.
Steven Steven, I appreciate this is continuing to drift further OT and apologize in advance. Given your frank observations on C++ development, can I ask for your suggestions/advice? I own a small software development company (3-5 emps). I would like to move our applications to C++. We have about 50 variously active customers all running custom apps of roughly an extended accounting nature. We have over 20 years experience and have converted all our apps three times
On Wednesday 09 November 2005 14:00, Steven T. Hatton wrote: previously. Obviously we would like to do this conversion with a high degree of skill and appreciate there may be several passes to produce a version to release. The question, then, is: where would one look amid the abundance of C++ information to separate the wheat from the chaff in development? To get accustomed to C++, I downloaded 'Thinking in C++' by Eckel. I'm using it to both learn C++ and to teach my 17 year old son (which I think is one of the better ways to learn, that is, by trying to teach someone else). The book is excellent but some parts use C examples to teach C++ and are a bit heady for a non C programmer. (Our current version is written in a RAD environment). I bought one of those 'learn C++ in x hours' books to get some simpler examples. It's OK for examples in some areas but the book is too limited and the author's comments too naive for serious development. Would you recommend any books, mailing lists, Internet sites for 'quality' input for C++ development? Again, this would be for end user application development, not device drivers, O/S extensions, etc.? I appreciate much of the discipline would be in common and so would appreciate any such sources worth considering. Thanks in advance. jcp
participants (4)
-
Jerry Feldman -
John C. Plummer -
Kai Ponte -
Steven T. Hatton