Microsoft's first OS was MS-DOS. Sure, it compared favorably to the operating system it sought to compete with, CP/M,
It competed with CP/M because it was designed from the beginning to be a clone of CP/M.
And it competed *favorably* only because MS didn't create it, they bought it from someone else. Afterwards, MS began changing and adding to it, and it became the shocking mess that users loved to hate.
Can you provide an example of Microsoft preventing another company's software from running on Windows?
The shenanigans they tried with DR-DOS is just one example, and, if you really want to know the truth (and aren't simply an MS shill), then you can find plenty more.
since the instruments (Hubble and Hershel) gather 2 different types of information, are the respective scientific teams going to overlay Hubble/Hershel data and extrapolate the differences?
What a lot of people don't know is that many of those colorized images released by NASA for example, are in fact overlays using data from Hubble *and* other instruments providing data from the rest of the frequency spectrum outside of the optical band.
In the press these images are just attributed to Hubble, because a lot of people know about Hubble but not the other ones, such as the infra-red Spitzer Space Telescope, and because they don't have to explain the part about it being a computer-generated combination of data from multiple sources, instead they just say its "a picture from Hubble".
The point many miss is that Hubble is almost *blind* to a *majority* of the Universe. Much of what we know about the Universe comes from observing the infra-red and radio frequencies, not the optical frequencies.
So to answer your question, yes, they've been combining data from multiple sources all along, but the media, in their never-ending quest to dumb us all down, have just been leaving out a few details. Shocking, I know...
"Time alloted" and "RAM available" are generally not concerns for an average desktop application.
They sure as hell are important on *my* desktop. Maybe if we ever see, for example, a desktop environment written in a managed code system that is fast and stable then you might have a point. Until then, "high-performance" is just as important for the desktop as it is for super-computing.
That's just plain naive.
Why? The very next thing you yourself say is:
Experienced professionals *can* write high-quality code in any language
which is exactly what I said! So, naive how, exactly?
(Is this code safe from buffer overflows? Did I free that pointer a while back? Am I sure this pointer I'm casting is the type I think it is? Etc, etc, etc).
True for C, but not for C++. That's my other issue with your post: C++ != C.
Irony, most delicious it is...
I have no idea what your point is
That "high-performance" still matters to all of us?
That C++ is still important because "high-performance" is what it does?
That managed code systems, for all their promise, aren't even close to "high-performance"?
Anyone who's watched a managed code app that, after running awhile, starts to crawl because its GC has gone bonkers will recognize the irony in your post.
"High-performance" isn't just for rich kids and geeks in ivory towers you know.
Every winforms app... worked flawlessly on Linux...
A Winforms app working on a non-Windows system is entirely at the discretion of Microsoft because Mono's Winforms implementation is violating MS patents. This is the *reason* for the controversy surrounding Mono.
By "stop supporting Mono" you mean "stop supporting.NET 2.0"
No, he means they stop allowing Mono to use their patent-encumbered implementations of Winforms, ASP.NET and ADO.NET. That is the glue code that allows a Mono app to become a Windows app on Windows, and that has always been what the controversy over Mono is about.
Of course, using Mono/GTK# isn't a problem, as I think you pointed out, but judging from Mono's overall popularity in the Linux world, at least outside of Gnome, few people are really interested (for now) in doing that, since there are other ways to build a Linux GTK app, using almost whatever language you want via one of the numerous bindings available for GTK, and never mind that GTK isn't the only GUI toolkit available in Linux.
This gives developers the choice between making software platform independent or dependent
Huh? We've always had this choice. Its not like MS, in.NET, just gave you the ability to do something you couldn't do before. The "platform independent" thing, however, has always been really hard to do, and thats what Java was/is trying to tackle. MS, on the other hand, and for obvious reasons, is utterly uninterested in the cross-platform problem.
With Java you must find a cross-platform solution to almost every problem, but with C# you have the choice.
Your attitude just proves what many have been saying all along: NET, and thus Mono, is all about Windows, and has nothing to do with being cross-platform, which is what Java has *always* been about, whatever its technical flaws.
It also proves a point I made elsewhere in this thread: the people knocking Java here are primarily Windows-centric devs who don't gave a damn about being cross-platform anyway.
And all this leads to the observation that Mono is the step-child that no relative really wants to claim, because it doesn't fit well with the goals of either of the opposing camps. Mono is deliberately standing squarely in the center no-man's land, yet loudly proclaiming that it belongs to both sides, and is thus rightly taking fire from both sides.
The only amusing thing from this sad situation is that some Mono backers seem to be genuinely surprised by that.
However, you can do loosely coupled member callbacks
I'm not an expert on template programming (primarily I'm a *user* of them, not a creator), but first of all, off the top of my head, that 'typename' keyword you use in your example is itself a "fairly recent" addition to the C++ Standard, whereas the Qt library on the other hand was born in 1991. One of the problems they faced was that even basic template support was not "commonly available" back then.
Sometimes I think people don't realize that for a long time C++ was defined by its only implementation, which was just a front-end to the C compiler (AT&T's CFront - can't remember the exact name), but in effect, C++ then was just a "smarter" C compiler, not at all like a "Standard C++" conforming compiler is today. The difference is as night and day.
Also, I don't believe your example really qualifies as "loosely coupled":
You're passing a reference to c to the callback mechanism that is called from p, so in this case the producer of your signal has to know who its consumer is. However, Qt's signals/slots mechanism allows the producers and consumers to know nothing about one another, while simultaneously being type-safe, which is what makes it so powerful, with the drawback being that it is not *quite* as efficient as the callback method, but in real-world Qt usage this difference is negligible.
Now, to be fair, its the fact that their library is a hierarchy based on a common "smart" object, the underlying (but non-graphical) "QObject", combined with 'moc', which implements their meta-object system, that is what makes their signals/slots thing possible to begin with, thus producers and consumers of signals must inherit from QObject - not an issue for Qt as virtually everything in it does so anyway. It was exactly for this signals/slots mechanism that they made moc in the first place.
So to do what they're doing in "straight Standard C++" will require more boilerplate code than anyone could do in a simple example. Boost.signals2 is doing most/all of what they are in signals/slots, and it is also not at all what you would call "a trivial implementation".:)
This gives C# a competitive edge over other languages with much less influential and powerful backers.
C# isn't the important part, its the integration into.NET and Windows which makes it useful/compelling, which of course is what MS is pushing hard. The issue with Mono isn't C#/CLR, its Winforms, ASP, ADO, all that proprietary glue code that makes it valuable to a Windows-centric developer. However, that stuff is toxic on a non-Windows system. So again, this is only meaningful if Windows is all that you care about. That was my point.
at some point, marketing has to take over.
At which point the users usually get owned. No thanks.
Removing the Mono runtime results in about a dozen Gnome desktop application being uninstalled.
Sounds to me like thats Gnome's problem, not Linux's problem. FWIW, I run KDE, so I have nothing on my system that needs Mono, but several things that use Java. That doesn't really prove anything though, as "proof by anecdote" isn't real proof at all.
Java really has little significance on the Gnome desktop
There, fixed that for ya.
and for good reason: Java applications don't look and feel right on Linux.
Oh please, Linux doesn't even have a standard desktop environment, GUI toolkit, or even a standard theme, and you have the audacity to use the phrase "look and feel" in the same sentence with "Linux"?
C, Shell, and Perl work well enough. What is this 'mono' and 'java' you speak of?
You, sir, are a very brave man, I salute you.
Brave not for using C/Shell/Perl (well, except maybe the Perl part), but for saying that in the middle of this thread. That takes cojones... Good luck.
the whole way the ecosystem of Linux is does not help, and is not helping at all.
What kind of of EULA did you agree to when you started using Linux? Because I certainly don't remember signing up for any crusade...
You didn't read the GP's last para did you? The part about FOSS programmers working on what *they* liked, not what you like? I hate to break this to you, but quite a few of those programmers aren't interested in crusades either.
Linux is not a monolith, its not an entity, its not a herd, its not a movement, its just an OS. An OS with a lot of users, all with *wildly* *different* *motivations*. That's it. Nothing to see here (for now), move along.
Anyone thinking of rebellions, castle stormings, and the guillotining of the arrogant nobles of our time need to snap out of their daydream and get back to work... or at least count me out, its way past my bedtime.
if you need to be reminded of the type of a variable, you must have already forgot its role and purpose in your project.
*blink*
.."your" project...
You know, some people actually work on projects that are so big & complex, they require more than one programmer, yea, really, its true!, projects that have too many modules & source files to keep track of, never mind variables... I believe its called the 'real world'. Look it up.
It's my understanding that C# is more popular than Java for desktop applications because of faster startup and lower memory use.
Well, its *my* understanding that C# is more popular than Java because its being pushed by MS, the 800 pound gorilla of the PC desktop market, and oh, I would imagine the difference between being integrated with the OS (IE all over again) versus making end users go onto the net to get the other one, is also playing a role...
So which of us is going to blink first and reach for our trusty '[citation needed]'?:)
I put my money on C#/Mono, since it is technically the better platform with MS behind it
Funny how people think, that last bit is precisely why I *wouldn't* put my money on.NET.
Bottom line from reading posts here seems to be this: if you only care about Windows, then.NET rules and the answer is obvious, but if you are on, or are interested in, any other platform, then.NET is irrelevant, thus making the answer equally obvious... but different.:)
Yeah, but you have to miss just one of those deletes, and boom
For deletes that you can't put in the obvious "proper" RAII place (class destructor), you now just wrap in a tr1/C++0x::shared_ptr and stop worrying...
Not everything is in Qt
Damn close though: Networking (http, ftp, sockets, ssl, etc), SQL, XML, WebKit, OpenGL, SVG, Multimedia... never mind whats in qt-core & qt-gui... have you browsed the Qt 4.5 docs lately?
import other libraries... string... hashmap
Just out of curiosity what libraries would these be?
it still requires Q_SIGNAL/SLOT/EMIT preprocessor pseudo-keywords
That's still a heck of a lot better than what (now-defunct) Borland did back in the good 'ole days of proprietary compilers, they added custom keywords right into the C++ language, not as macros, but hardwired into their compilers...
I think its fair to point out to anyone else that might not know, 'moc' is basically just a "boilerplate C++ code generator", its output is 100% standard C++. Its just doing boring mechanical work so you don't have to. When Trolltech took this approach, this was waaaay back when a typical "C++ compiler" would choke and die a horrible death if it was feed anything like, say, today's Boost source code. All you needed to get a segfault or ICE from your compiler back then was 3 magic words: "partial template specialization". Most compilers would faint dead away upon hearing that...
There *was* no "C++ standard" back then, especially when it came to templates and meta-programming which is the only (AFAIK) way to implement a callback mechanism directly within the confines of the C++ language itself. When the Trolls needed this functionally, there just wasn't any other way to do it in a *cross-platform*, *multi-compiler* manner. When you think about it, it is kinda amazing they managed to pull it off, as they were *essentially* using the **dumbest** platform and the **dumbest** compiler of the time as *their* "standard"! What they did was at least a heck of a lot better than going the Borland route of just saying "to hell with standards, lets go with lock-in!".:)
The only "practical & significant" (obviously IMHO of course!) issue remaining was the namespace pollution issue created by a lot of Qt globals and macros and such. Remember, Qt was started *before* we even had a standard, cross-compiler 'namespace {}' thingie! That has been cleared up now. Besides corralling all of their stuff into its own namespaces, there is now an option to disable the old "signals/slots/emit" macros and replace them with the more appropriate "Q_SIGNALS/Q_SLOTS/Q_EMIT" names, so you can now actually use Boost.signals(2) with Qt if you wanted to.
As for your earlier comment about ugly error messages, what immediately came to my mind was the usual C++ error messages you get when a deeply nested template instantiation goes horribly, *horribly* sideways. Compared to that, those Qyoto error messages look positively tame to me, never mind also looking a little underfed...
Oh please, *please* Santa, bring me C++0x & Concepts for Christmas, if not this coming Christmas then at least one thats within my productive lifetime, pretty please?
Unlike Sun's JRE, both Microsoft's.NET Framework and Mono have an AOT compiler
Well, there's a switch to the Java runtime to tell it to "compile everything it can *before* running" which is close to the same as "ahead of time". It isn't precompilation though, true. I guess there's a philosophical difference here between CLR & JVM on this, since precompilation *could* turn into "premature compilation" that can actually prevent a JITC from doing the best runtime optimizations its capable of. A JITC that can optimize across the entire program, possibly using runtime profiling information, is best when it can "see" all of the "code", whether in source or bytecode form (CLR/JVM bytecode still preserves semantic information about the code/data an optimizing compiler needs, which is normally lost once the code is compiled all the way to machine code).
Its probably just because of the fact that CLR is now integrated into the OS (Windows), that it made sense to MS to support precompiling it just like any other system library, after all, to them, thats what it is now: a system library.
but everything runs natively
I probably should have been a little more clearer in what I meant by compiling "down to 100% native machine code". I wasn't just referring to any bytecode that would need JIT'ing or interpretation, I was also thinking of the overhead (no matter how significant or not) imposed by the platform's runtime engine (CLR/JVM).
See my response to the other poster.
The upside of "managed code" is that a lot of things are done for you, the downside of managed code is... that a lot of things are done for you.:)
Besides, a JIT compiler could compile the complete program when you start it, thereby removing the interpretation completely,
It could compile all the functions/methods/objects of your app to machine code, but your app is still being "processed in a loop", even if most the normal work of that loop (bytecode interpretation or JIT'ing) has already been done. Instead of interpreting bytecode, the loop just directly executes the native code, but then return passes back to the loop and it goes to the next chunk of code to run, and then the next, etc.
That "control loop" is the "main()" routine of your platform's runtime engine (CLR/JVM) and is still adding some (however small) overhead, in addition to the eval loop, there is garbage collection, the security framework, error checking/handling, dynamic typing, etc, etc. Thats why they call it "managed code", and it applies to both CLR/JVM equally. You can't completely get away from that "managed" aspect, if you could, it wouldn't be CLR/JVM anymore.
However, as you or someone said, depending on the source code, a clever JITC with a highly optimized runtime, can get within 5% of the speed of "unmanaged code" (ignoring garbage collection), I wasn't trying to imply that it was always a drastic difference. For many apps/purposes, thats plenty "fast enough".
creates what I'll call an executable stub that invokes the IL code interpreter
I'm sure the GP is referring to compiling a program down to 100% native machine code. If there is an "interpreter" involved, then you don't get that.
GCC's gcj will do this for *some* Java apps, but it has limitations (mainly on the GUI side). Don't know about Mono.
Even JIT compilers, which Java has, and I assume Mono as well, can only compile parts of a program to machine code, the virtual machine's interpreter loop is still there, so between that and the overhead of the garbage collector, Java/Mono apps are prevented from approaching the speed(*) of a fully compiled app, like one written in C/C++ for example, because the latter has no interpretation being performed.
(*) speed being also dependent on how well/poorly the app is written, whatever its language, of course.
In addition to what Enleth said, why are we all assuming they run a *stock* bash on these sensitive systems? I'll bet money there's a "secured" shell out there somewhere, or perhaps they just customized a version of bash, that will not let you do this at all. Its logging is automatic and hardwired I'll bet.
Slashdot Mirror
It competed with CP/M because it was designed from the beginning to be a clone of CP/M.
And it competed *favorably* only because MS didn't create it, they bought it from someone else . Afterwards, MS began changing and adding to it, and it became the shocking mess that users loved to hate.
Otherwise, great post.
The shenanigans they tried with DR-DOS is just one example, and, if you really want to know the truth (and aren't simply an MS shill), then you can find plenty more.
Only for as long as MS chooses to let them follow.
The existence of Moonlight is entirely at the discretion and whim of Microsoft.
Been there, done that. No thanks.
only if said platform is running MS Windows...
Shockingly, some of us don't think that constitutes "platform independence".
What a lot of people don't know is that many of those colorized images released by NASA for example, are in fact overlays using data from Hubble *and* other instruments providing data from the rest of the frequency spectrum outside of the optical band.
In the press these images are just attributed to Hubble, because a lot of people know about Hubble but not the other ones, such as the infra-red Spitzer Space Telescope, and because they don't have to explain the part about it being a computer-generated combination of data from multiple sources, instead they just say its "a picture from Hubble".
The point many miss is that Hubble is almost *blind* to a *majority* of the Universe. Much of what we know about the Universe comes from observing the infra-red and radio frequencies, not the optical frequencies.
So to answer your question, yes, they've been combining data from multiple sources all along, but the media, in their never-ending quest to dumb us all down, have just been leaving out a few details. Shocking, I know...
They sure as hell are important on *my* desktop. Maybe if we ever see, for example, a desktop environment written in a managed code system that is fast and stable then you might have a point. Until then, "high-performance" is just as important for the desktop as it is for super-computing.
Why? The very next thing you yourself say is:
which is exactly what I said! So, naive how, exactly?
True for C, but not for C++. That's my other issue with your post: C++ != C.
That "high-performance" still matters to all of us?
That C++ is still important because "high-performance" is what it does?
That managed code systems, for all their promise, aren't even close to "high-performance"?
Anyone who's watched a managed code app that, after running awhile, starts to crawl because its GC has gone bonkers will recognize the irony in your post.
"High-performance" isn't just for rich kids and geeks in ivory towers you know.
A Winforms app working on a non-Windows system is entirely at the discretion of Microsoft because Mono's Winforms implementation is violating MS patents. This is the *reason* for the controversy surrounding Mono.
No, he means they stop allowing Mono to use their patent-encumbered implementations of Winforms, ASP.NET and ADO.NET. That is the glue code that allows a Mono app to become a Windows app on Windows, and that has always been what the controversy over Mono is about.
Of course, using Mono/GTK# isn't a problem, as I think you pointed out, but judging from Mono's overall popularity in the Linux world, at least outside of Gnome, few people are really interested (for now) in doing that, since there are other ways to build a Linux GTK app, using almost whatever language you want via one of the numerous bindings available for GTK, and never mind that GTK isn't the only GUI toolkit available in Linux.
Huh? We've always had this choice. Its not like MS, in .NET, just gave you the ability to do something you couldn't do before. The "platform independent" thing, however, has always been really hard to do, and thats what Java was/is trying to tackle. MS, on the other hand, and for obvious reasons, is utterly uninterested in the cross-platform problem.
Your attitude just proves what many have been saying all along: NET, and thus Mono, is all about Windows, and has nothing to do with being cross-platform, which is what Java has *always* been about, whatever its technical flaws.
It also proves a point I made elsewhere in this thread: the people knocking Java here are primarily Windows-centric devs who don't gave a damn about being cross-platform anyway.
And all this leads to the observation that Mono is the step-child that no relative really wants to claim, because it doesn't fit well with the goals of either of the opposing camps. Mono is deliberately standing squarely in the center no-man's land, yet loudly proclaiming that it belongs to both sides, and is thus rightly taking fire from both sides.
The only amusing thing from this sad situation is that some Mono backers seem to be genuinely surprised by that.
I'm not an expert on template programming (primarily I'm a *user* of them, not a creator), but first of all, off the top of my head, that 'typename' keyword you use in your example is itself a "fairly recent" addition to the C++ Standard, whereas the Qt library on the other hand was born in 1991. One of the problems they faced was that even basic template support was not "commonly available" back then.
Sometimes I think people don't realize that for a long time C++ was defined by its only implementation, which was just a front-end to the C compiler (AT&T's CFront - can't remember the exact name), but in effect, C++ then was just a "smarter" C compiler, not at all like a "Standard C++" conforming compiler is today. The difference is as night and day.
Also, I don't believe your example really qualifies as "loosely coupled":
You're passing a reference to c to the callback mechanism that is called from p, so in this case the producer of your signal has to know who its consumer is. However, Qt's signals/slots mechanism allows the producers and consumers to know nothing about one another, while simultaneously being type-safe, which is what makes it so powerful, with the drawback being that it is not *quite* as efficient as the callback method, but in real-world Qt usage this difference is negligible.
Now, to be fair, its the fact that their library is a hierarchy based on a common "smart" object, the underlying (but non-graphical) "QObject", combined with 'moc', which implements their meta-object system, that is what makes their signals/slots thing possible to begin with, thus producers and consumers of signals must inherit from QObject - not an issue for Qt as virtually everything in it does so anyway. It was exactly for this signals/slots mechanism that they made moc in the first place.
So to do what they're doing in "straight Standard C++" will require more boilerplate code than anyone could do in a simple example. Boost.signals2 is doing most/all of what they are in signals/slots, and it is also not at all what you would call "a trivial implementation". :)
C# isn't the important part, its the integration into .NET and Windows which makes it useful/compelling, which of course is what MS is pushing hard. The issue with Mono isn't C#/CLR, its Winforms, ASP, ADO, all that proprietary glue code that makes it valuable to a Windows-centric developer. However, that stuff is toxic on a non-Windows system. So again, this is only meaningful if Windows is all that you care about. That was my point.
At which point the users usually get owned. No thanks.
Sounds to me like thats Gnome's problem, not Linux's problem. FWIW, I run KDE, so I have nothing on my system that needs Mono, but several things that use Java. That doesn't really prove anything though, as "proof by anecdote" isn't real proof at all.
There, fixed that for ya.
Oh please, Linux doesn't even have a standard desktop environment, GUI toolkit, or even a standard theme, and you have the audacity to use the phrase "look and feel" in the same sentence with "Linux"?
Troll much?
You, sir, are a very brave man, I salute you.
Brave not for using C/Shell/Perl (well, except maybe the Perl part), but for saying that in the middle of this thread. That takes cojones... Good luck.
Right, when those shiny "managed code" systems can't manage to run in the time alloted or the ram available, who'ya gonna call?
Oh bullshit, *experienced* *professionals* can write high-quality code in any language, just as amateurs can screw up in any language.
Right tool for the job, and use what you know.
Irony, most delicious it is...
What kind of of EULA did you agree to when you started using Linux? Because I certainly don't remember signing up for any crusade...
You didn't read the GP's last para did you? The part about FOSS programmers working on what *they* liked, not what you like? I hate to break this to you, but quite a few of those programmers aren't interested in crusades either.
Linux is not a monolith, its not an entity, its not a herd, its not a movement, its just an OS. An OS with a lot of users, all with *wildly* *different* *motivations*. That's it. Nothing to see here (for now), move along.
Anyone thinking of rebellions, castle stormings, and the guillotining of the arrogant nobles of our time need to snap out of their daydream and get back to work... or at least count me out, its way past my bedtime.
*blink*
You know, some people actually work on projects that are so big & complex, they require more than one programmer, yea, really, its true!, projects that have too many modules & source files to keep track of, never mind variables... I believe its called the 'real world'. Look it up.
JIT'ing is a one night stand, its the garbage collection that will haunt you for the rest of your program's life...
It's my understanding that C# is more popular than Java for desktop applications because of faster startup and lower memory use.
Well, its *my* understanding that C# is more popular than Java because its being pushed by MS, the 800 pound gorilla of the PC desktop market, and oh, I would imagine the difference between being integrated with the OS (IE all over again) versus making end users go onto the net to get the other one, is also playing a role...
:)
So which of us is going to blink first and reach for our trusty '[citation needed]'?
Funny how people think, that last bit is precisely why I *wouldn't* put my money on .NET.
Bottom line from reading posts here seems to be this: if you only care about Windows, then .NET rules and the answer is obvious, but if you are on, or are interested in, any other platform, then .NET is irrelevant, thus making the answer equally obvious... but different. :)
For deletes that you can't put in the obvious "proper" RAII place (class destructor), you now just wrap in a tr1/C++0x::shared_ptr and stop worrying...
Damn close though: Networking (http, ftp, sockets, ssl, etc), SQL, XML, WebKit, OpenGL, SVG, Multimedia... never mind whats in qt-core & qt-gui... have you browsed the Qt 4.5 docs lately?
Just out of curiosity what libraries would these be?
That's still a heck of a lot better than what (now-defunct) Borland did back in the good 'ole days of proprietary compilers, they added custom keywords right into the C++ language, not as macros, but hardwired into their compilers...
I think its fair to point out to anyone else that might not know, 'moc' is basically just a "boilerplate C++ code generator", its output is 100% standard C++. Its just doing boring mechanical work so you don't have to. When Trolltech took this approach, this was waaaay back when a typical "C++ compiler" would choke and die a horrible death if it was feed anything like, say, today's Boost source code. All you needed to get a segfault or ICE from your compiler back then was 3 magic words: "partial template specialization". Most compilers would faint dead away upon hearing that...
There *was* no "C++ standard" back then, especially when it came to templates and meta-programming which is the only (AFAIK) way to implement a callback mechanism directly within the confines of the C++ language itself. When the Trolls needed this functionally, there just wasn't any other way to do it in a *cross-platform*, *multi-compiler* manner. When you think about it, it is kinda amazing they managed to pull it off, as they were *essentially* using the **dumbest** platform and the **dumbest** compiler of the time as *their* "standard"! What they did was at least a heck of a lot better than going the Borland route of just saying "to hell with standards, lets go with lock-in!". :)
The only "practical & significant" (obviously IMHO of course!) issue remaining was the namespace pollution issue created by a lot of Qt globals and macros and such. Remember, Qt was started *before* we even had a standard, cross-compiler 'namespace {}' thingie! That has been cleared up now. Besides corralling all of their stuff into its own namespaces, there is now an option to disable the old "signals/slots/emit" macros and replace them with the more appropriate "Q_SIGNALS/Q_SLOTS/Q_EMIT" names, so you can now actually use Boost.signals(2) with Qt if you wanted to.
As for your earlier comment about ugly error messages, what immediately came to my mind was the usual C++ error messages you get when a deeply nested template instantiation goes horribly, *horribly* sideways. Compared to that, those Qyoto error messages look positively tame to me, never mind also looking a little underfed...
Oh please, *please* Santa, bring me C++0x & Concepts for Christmas, if not this coming Christmas then at least one thats within my productive lifetime, pretty please?
Well, there's a switch to the Java runtime to tell it to "compile everything it can *before* running" which is close to the same as "ahead of time". It isn't precompilation though, true. I guess there's a philosophical difference here between CLR & JVM on this, since precompilation *could* turn into "premature compilation" that can actually prevent a JITC from doing the best runtime optimizations its capable of. A JITC that can optimize across the entire program, possibly using runtime profiling information, is best when it can "see" all of the "code", whether in source or bytecode form (CLR/JVM bytecode still preserves semantic information about the code/data an optimizing compiler needs, which is normally lost once the code is compiled all the way to machine code).
Its probably just because of the fact that CLR is now integrated into the OS (Windows), that it made sense to MS to support precompiling it just like any other system library, after all, to them, thats what it is now: a system library.
I probably should have been a little more clearer in what I meant by compiling "down to 100% native machine code". I wasn't just referring to any bytecode that would need JIT'ing or interpretation, I was also thinking of the overhead (no matter how significant or not) imposed by the platform's runtime engine (CLR/JVM).
See my response to the other poster.
The upside of "managed code" is that a lot of things are done for you, the downside of managed code is... that a lot of things are done for you. :)
It could compile all the functions/methods/objects of your app to machine code, but your app is still being "processed in a loop", even if most the normal work of that loop (bytecode interpretation or JIT'ing) has already been done. Instead of interpreting bytecode, the loop just directly executes the native code, but then return passes back to the loop and it goes to the next chunk of code to run, and then the next, etc.
That "control loop" is the "main()" routine of your platform's runtime engine (CLR/JVM) and is still adding some (however small) overhead, in addition to the eval loop, there is garbage collection, the security framework, error checking/handling, dynamic typing, etc, etc. Thats why they call it "managed code", and it applies to both CLR/JVM equally. You can't completely get away from that "managed" aspect, if you could, it wouldn't be CLR/JVM anymore.
However, as you or someone said, depending on the source code, a clever JITC with a highly optimized runtime, can get within 5% of the speed of "unmanaged code" (ignoring garbage collection), I wasn't trying to imply that it was always a drastic difference. For many apps/purposes, thats plenty "fast enough".
creates what I'll call an executable stub that invokes the IL code interpreter
I'm sure the GP is referring to compiling a program down to 100% native machine code. If there is an "interpreter" involved, then you don't get that.
GCC's gcj will do this for *some* Java apps, but it has limitations (mainly on the GUI side). Don't know about Mono.
Even JIT compilers, which Java has, and I assume Mono as well, can only compile parts of a program to machine code, the virtual machine's interpreter loop is still there, so between that and the overhead of the garbage collector, Java/Mono apps are prevented from approaching the speed(*) of a fully compiled app, like one written in C/C++ for example, because the latter has no interpretation being performed.
(*) speed being also dependent on how well/poorly the app is written, whatever its language, of course.
In addition to what Enleth said, why are we all assuming they run a *stock* bash on these sensitive systems? I'll bet money there's a "secured" shell out there somewhere, or perhaps they just customized a version of bash, that will not let you do this at all. Its logging is automatic and hardwired I'll bet.