It is no slower than C if you know what you are doing
Yeah, it's that "knowing what you are doing" bit that gets me. It always seems that you have to pay a huge amount of attention to what the compiler is trying to hide from you (creating temporary variables, etc.), which kinda defeats the purpose, and ultimately is mounds harder than just coding in C. (In my limited experience;)
I believed so to. Then I tried to compile some sample code with GCC (get/set functions, virtual functions, etc.) and compared the resulting assembly with whatever was generated from analogous C code. When optimizations are off, the results are horrible. Nevertheless, the optimized version did not differ from C very much.
I think that what happens most often is that people try to use library data types (String class, etc.). With C++ operator overloading, the code looks exactly the same as if base data types were used, but the speed now depends on the library perfomance, so the code looks "slower".
Well, C++ is the only known cure at the moment, AFAIK.
Can you elaborate on this point? (I don't code gui's, so I know nothing about gui specific problems. But I've always found C++ pretty slow & useless.) What's the scoop? What is an example of the problem & how does C++ solve it?
The basic problem is that as you add new GUI elements and new features to each GUI element, you tend to multiply number of various functions. Look at Motif for example: you will see that many widgets have special functions associated with them, plus there are multiple properties set in a nightmarish way. Toolkit names grow and become untypable.
With C++ you can encapsulate widgets into classes. Then properties and functions naturally become members of the class. Even better, you can use inheritance for widgets which are almost the same as parent, but differ in behaviour. And this also applies to other abstractions, such as Application, AppSettings, etc.
As to C++ speed, it seems to strongly depend on how you use it. It is no slower than C if you know what you are doing, although there is place for screwups (most STL implementations seem to be screwups, but I may be wrong here).
Well, let us first perform a reality check on what was said here before:
1. If you look at the software available for Unix systems now, you will see that 99.99..% of it is written in C or C++. Not Java. Not Pascal. Not Ada9x mentioned by the original poster. What does this mean? This apparently means that any GUI framework worthy consideration probably has to support C/C++.
2. If you look at any extensive GUI framework in C, you will immediately see that as the number of features grows linearly, the complexity of API grows exponentially. Both Motif and GNOME are good examples of this. Again, what is the cure? Well, C++ is the only known cure at the moment, AFAIK. Some people do not like C++, but it does help to organize GUI APIs better. Look at Qt/KDE, BeOS, or Borland C++Builder for examples. So, the suspicion is that whatever "best" GUI kit you choose, it should at least allow an extension into C++.
3. The license must allow a person to sell programs written with the GUI kit. Period. LGPL doesn't cut it. If money is charged for the GUI kit itself, it must be in $100US range to allow us, the mere mortals, to buy the kit (>$1000US charged by Troll for its commercial Qt license is a bitter joke on programming community).
4. It is really helpful to have some GUI designer or a layout tool. Fortunately, most widely used toolkits have got such tools by now.
What does it leave us with? Well, basically, with nothing. Of well-known GUI kits, we are left with:
1. Qt/KDE -- It's a very nicely organized C++ kit which definitely comes up on top (yes, I can live with MOC, it's ok), but it's LGPL/Troll/GPL licensing makes it difficult to write commercial software (commercial Qt license is beyond the reach of most "normal" people).
2. BeOS -- Also a very nicely organized C++ kit, but we are talking Unix toolkits now, so no BeOS.
3. C++Builder VCL -- One more nice C++ kit which may become a killer when ported to Unix (you can divide your code and GUI in C++Builder, it just requires common sense). So far, it is Windows-only though. Period.
4. GTK -- The toolkit has become overblown, IMHO, both complexity an speed wise. It may be a result of too many people trying to develop it (KDE lacks this problem), but I think that it is rather a limitation of C (as opposed to C++).
5. WINGS -- Very nice C-based toolkit, really easy to program with. Two problems here: 1) dependency on WMaker and 2) Lack of development. It is sure to hit the complexity threshold if it becomes extensive though.
6. Java awt/sling/whatever -- You really can't expect people to use Java programs. Slow. Unstable. Incompatible between releases of Java. Require megabytes of Java installed. How many of you have deleted a program off your Windows system after finding out it is written in VisualBASIC and requires MSVBVM.DLL (or whatever it is called)?
7. Delphi -- It is very nice. It is Pascal. Most contemporary programmers would expect compatibility with the C/C++ code though. So, use C++Builder. And still, Delphi is Windows-only.
8. XForms -- Simple, easy to program C-based toolkit. Same problem as with WINGS: lack of active development. Same warning: at some point, it may become to complicated and require switching to C++.
So, to summarize: There is still no ideal GUI toolkit for Unix right now. But Qt/KDE would probably quickly become and ideal toolkit if it allowed normal commercial usage, possibly for a modest fee.
If you took all the files associated with FreeBSD, and replaced it's kernel (and support programs like ps, lsof, etc) with the Linux kernel (&etc), you would be running Linux. Wouldn't you?
In fact, no. I would be running a FreeBSD system with a Linux kernel. And I suspect it would be pretty much useless.
Everyone is distributing libc6. Some people are still running libc5. Backwards compatibility is achieved by distributing libc5 as well. Forward compatibility is achieved by installing libc6.
Let us see...During the last 6 months, I am receiving about 4 emails a week (on the average) dealing with library incompatibilities between different flavors of Linux. I have seen libc5, GLIBC, and GLIBC2, each had its own problems. In addition, there are different versions of GLIBC and GLIBC2. Do you actually expect normal people (that is excluding Linux fans ready to fiddle with their system just for the sake of it) use something like this? Even more, do you still insist on the fact that this is not fragmentation?
Has FreeBSD never had changes which are not forward-compatible?
It had. The changes tend to be slow and gentle on the userbase though. Maybe because most of the userbase treats FreeBSD as a tool, not as a fetish?
So, what is there to read? Torvalds displays his lack of understanding of operating systems and Tannenbaum promises him a "C" in the operating systems class. You can also go to EGCS discussion board at Cygnus and read a more recent piece where Torvalds tries to teach EGCS developers about programming language semantics. Quite depressive, I must say.
Sigh. Most of the hype around microkernels have run out in the sand. They are currently, with a few exceptions, simply not good enough, or fast enough, to be interesting for a wide deployment.
What you are apparently talking about is called Mach. While it is bloated for political reasons, Mach is certainly not *all* the microkernels.
But QNX is NOT a good commercial choice for a company that want to release a consumer machine, since there's practically NO available software for it.
QNX is POSIX which means it runs most of the correctly written Unix software. Now, Linux software may often be non-compliant with POSIX, but it is a different story.
By going with the Linux kernel, both Amiga and Linux win: There will be more reasons for people to port to Linux.
Have I missed a reason for Amiga to win in this paragraph of yours? Where is it?
The kernel provide memory protection, file system abstraction, process management, and a hardware driver model. Not much else. There's a damn lot more needed for a full OS, and in Linux that is taken care of by lots of libraries and applications with Unix heritage.
As a matter of fact, there is *not* much more needed for a full OS and even some parts you mentioned are not needed. Now, if you really remember AmigaOS, as you say, the only things present in the exec.library (AmigaOS microkernel) were process and memory management, scheduling, and interprocess communication.
The rest (devices, file services, graphics, GUI, sound) has been done via run-time loadable modules. Modules which you didn't have to recompile every week in the fear of a coredump.
Re:Why assume all h4x0rZ are guys?
on
Slashdot Tweaks
·
· Score: 1
Absolutely correct. I always use gender-unspecific "it" when talking about their kind. With no significant brain activity, they do not deserve "he" or "she" anyway.
Slashdot Mirror
I may be biased, but....
if you're into software development full time, USD 1000 will pay for your time and expenses for several DAYS.
Unfortunately, you are not only biased, but also wrong. It would still be nice if this statement were true though
It is no slower than C if you know what you are doing
Yeah, it's that "knowing what you are doing" bit that gets me. It always seems that you have to pay a huge amount of attention to what the compiler is trying to hide from you (creating temporary variables, etc.), which kinda defeats the purpose, and ultimately is mounds harder than just coding in C. (In my limited experience
I believed so to. Then I tried to compile some sample code with GCC (get/set functions, virtual functions, etc.) and compared the resulting assembly with whatever was generated from analogous C code. When optimizations are off, the results are horrible. Nevertheless, the optimized version did not differ from C very much.
I think that what happens most often is that people try to use library data types (String class, etc.). With C++ operator overloading, the code looks exactly the same as if base data types were used, but the speed now depends on the library perfomance, so the code looks "slower".
Well, C++ is the only known cure at the moment, AFAIK.
Can you elaborate on this point? (I don't code gui's, so I know nothing about gui specific problems. But I've always found C++ pretty slow & useless.) What's the scoop? What is an example of the problem & how does C++ solve it?
The basic problem is that as you add new GUI elements and new features to each GUI element, you tend to multiply number of various functions. Look at Motif for example: you will see that many widgets have special functions associated with them, plus there are multiple properties set in a nightmarish way. Toolkit names grow and become untypable.
With C++ you can encapsulate widgets into classes. Then properties and functions naturally become members of the class. Even better, you can use inheritance for widgets which are almost the same as parent, but differ in behaviour. And this also applies to other abstractions, such as Application, AppSettings, etc.
As to C++ speed, it seems to strongly depend on how you use it. It is no slower than C if you know what you are doing, although there is place for screwups (most STL implementations seem to be screwups, but I may be wrong here).
Well, let us first perform a reality check on what was said here before:
1. If you look at the software available for Unix systems now, you will see that 99.99..% of it is written in C or C++. Not Java. Not Pascal. Not Ada9x mentioned by the original poster. What does this mean? This apparently means that any GUI framework worthy consideration probably has to support C/C++.
2. If you look at any extensive GUI framework in C, you will immediately see that as the number of features grows linearly, the complexity of API grows exponentially. Both Motif and GNOME are good examples of this. Again, what is the cure? Well, C++ is the only known cure at the moment, AFAIK. Some people do not like C++, but it does help to organize GUI APIs better. Look at Qt/KDE, BeOS, or Borland C++Builder for examples. So, the suspicion is that whatever "best" GUI kit you choose, it should at least allow an extension into C++.
3. The license must allow a person to sell programs written with the GUI kit. Period. LGPL doesn't cut it. If money is charged for the GUI kit itself, it must be in $100US range to allow us, the mere mortals, to buy the kit (>$1000US charged by Troll for its commercial Qt license is a bitter joke on programming community).
4. It is really helpful to have some GUI designer or a layout tool. Fortunately, most widely used toolkits have got such tools by now.
What does it leave us with? Well, basically, with nothing. Of well-known GUI kits, we are left with:
1. Qt/KDE -- It's a very nicely organized C++ kit which definitely comes up on top (yes, I can live with MOC, it's ok), but it's LGPL/Troll/GPL licensing makes it difficult to write commercial software (commercial Qt license is beyond the reach of most "normal" people).
2. BeOS -- Also a very nicely organized C++ kit, but we are talking Unix toolkits now, so no BeOS.
3. C++Builder VCL -- One more nice C++ kit which may become a killer when ported to Unix (you can divide your code and GUI in C++Builder, it just requires common sense). So far, it is Windows-only though. Period.
4. GTK -- The toolkit has become overblown, IMHO, both complexity an speed wise. It may be a result of too many people trying to develop it (KDE lacks this problem), but I think that it is rather a limitation of C (as opposed to C++).
5. WINGS -- Very nice C-based toolkit, really easy to program with. Two problems here: 1) dependency on WMaker and 2) Lack of development. It is sure to hit the complexity threshold if it becomes extensive though.
6. Java awt/sling/whatever -- You really can't expect people to use Java programs. Slow. Unstable. Incompatible between releases of Java. Require megabytes of Java installed. How many of you have deleted a program off your Windows system after finding out it is written in VisualBASIC and requires MSVBVM.DLL (or whatever it is called)?
7. Delphi -- It is very nice. It is Pascal. Most contemporary programmers would expect compatibility with the C/C++ code though. So, use C++Builder. And still, Delphi is Windows-only.
8. XForms -- Simple, easy to program C-based toolkit. Same problem as with WINGS: lack of active development. Same warning: at some point, it may become to complicated and require switching to C++.
So, to summarize: There is still no ideal GUI toolkit for Unix right now. But Qt/KDE would probably quickly become and ideal toolkit if it allowed normal commercial usage, possibly for a modest fee.
If you took all the files associated with FreeBSD, and replaced it's kernel (and support programs like ps, lsof, etc) with the Linux kernel (&etc), you would be running Linux. Wouldn't you?
In fact, no. I would be running a FreeBSD system with a Linux kernel. And I suspect it would be pretty much useless.
Everyone is distributing libc6. Some people are still running libc5. Backwards compatibility is achieved by distributing libc5 as well. Forward compatibility is achieved by installing libc6.
Let us see...During the last 6 months, I am receiving about 4 emails a week (on the average) dealing with library incompatibilities between different flavors of Linux. I have seen libc5,
GLIBC, and GLIBC2, each had its own problems. In addition, there are different versions of GLIBC and GLIBC2. Do you actually expect normal people (that is excluding Linux fans ready to fiddle with their system just for the sake of it) use something like this? Even more, do you still insist on the fact that this is not fragmentation?
Has FreeBSD never had changes which are not forward-compatible?
It had. The changes tend to be slow and gentle on the userbase though. Maybe because most of the userbase treats FreeBSD as a tool, not as a fetish?
So, what is there to read? Torvalds displays his lack of understanding of operating systems and Tannenbaum promises him a "C" in the operating systems class. You can also go to EGCS discussion board at Cygnus and read a more recent piece where Torvalds tries to teach EGCS developers about programming language semantics. Quite depressive, I must say.
Sigh. Most of the hype around microkernels have run out in the sand. They are currently, with a few exceptions, simply not good enough, or fast enough, to be interesting for a wide deployment.
What you are apparently talking about is called Mach. While it is bloated for political reasons, Mach is certainly not *all* the microkernels.
But QNX is NOT a good commercial choice for a company that want to release a consumer machine, since there's practically NO available software for it.
QNX is POSIX which means it runs most of the correctly written Unix software. Now, Linux software may often be non-compliant with POSIX, but it is a different story.
By going with the Linux kernel, both Amiga and Linux win: There will be more reasons for people to port to Linux.
Have I missed a reason for Amiga to win in this paragraph of yours? Where is it?
The kernel provide memory protection, file system abstraction, process management, and a hardware driver model. Not much else. There's a damn lot more needed for a full OS, and in Linux that is taken care of by lots of libraries and applications with Unix heritage.
As a matter of fact, there is *not* much more needed for a full OS and even some parts you mentioned are not needed. Now, if you really remember AmigaOS, as you say, the only things present in the exec.library (AmigaOS microkernel) were process and memory management, scheduling, and interprocess communication.
The rest (devices, file services, graphics, GUI, sound) has been done via run-time loadable modules. Modules which you didn't have to recompile every week in the fear of a coredump.
Absolutely correct. I always use gender-unspecific
"it" when talking about their kind. With no significant brain activity, they do not deserve
"he" or "she" anyway.