The real problem with that is some of the platform dependencies won't be clearly visible until you've ported the code to other platforms. You may have designed something that works very well with one platform, but is insupportable on another. I believe there is something akin to "the rule of 3", where you only know if something is truly portable if you have successfully ported it to at least 3 different platforms.
Wouldn't this also apply to Apple, who a few years ago declared they were expanding their campus? I believe there was a video of Jobs talking to the Cupertino council. Now their share price has had a meteoric rise.
If they innovated and provided compelling reasons to use their APIs, developers would not want to use a third party API that continued to lag behind. However, third parties are motivated by customer demand to keep up with the latest changes to the API (see MonoTouch). This argument is pretty much moot.
The real problem is NeHe's tutorials are painfully out of date. Modern OpenGL has deprecated or removed a lot of the functionality that is used in those tutorials, and there doesn't seem to be any update for OpenGL 3 or 4.
It's an election year, we Australians need to ensure he is not re-elected. I'm not sure how to go about this, but anyone who has an idea, I'd be willing to help.
That's not true. You have a choice as to what OS you want to run on your desk, and what machine you want to run it on. Mac OS X, Linux and Windows are officially supported - I haven't seen anything else.
There are also situations that force your hand. If you're using a C library, and you provide it callbacks, if the library wasn't compiled with exception handling support (very rare for C libraries to be on Linux), then you're out of luck. If you throw an exception your whole program fails, you have to longjmp() to a safe point inside your C++ code from where you can throw. I find I have this happen a lot with image libraries, e.g.: libpng and libjpeg.
Best solution is to have all your objects set up before your setjmp(), then when you longjmp() back and throw, your objects should be cleanly deallocated.
There are also advantages to Subversion that Linus states himself [1]. Really the only one of note is that Git isn't so great at having multiple projects in the one repository and the recommendation is to have one per repository and have a super-project that contains pointers to others - which isn't so great a solution.
Why should it be dumbed down? I don't go reading Biology articles and expect to know everything. That's why there are links to other articles explaining each bit in more detail.
There is Moonlight. In the end I'd rather none of these plugins, but if I have to choose, my preference is Flash. Adobe have shown support for multiple platforms, while Microsoft is pretty much delegating that to Mono, which is perpetually playing catch-up.
You can still pass data to a process via a message that causes it to crash. Just as with any program, you still need strict validation on the input, which is the same across processes as within a process. You just can't pass invalid pointers and arbitrarily trash memory (hopefully).
You can have a TLS jmpbuf and setjmp at the start of the thread. So when you segfault you can longjmp to a known location and clean up the thread, continuing on. Ofcourse you can't guarantee the state of the program after this unless you limit the functionality of each thread and make some limited guarantees.
That does not make it significantly different. I'm sure in time you'll see something similar in Java too, they seem to follow each others lead quite a lot.
Hmmm, I'm writing this from my MBP running 10.5.3 - and well, it runs like ass. I've been doing a lot of IPC work lately and my system seems to perform _really_ poorly under load. Safari repeatedly spins, transmission constantly locks up.
I never have these problems under Linux, it runs smooth as butter the whole time. I can always guarantee that performance on my benchmarks will be an order of magnitude better under Linux on an equivalent computer.
Saying all this though, I still like OS X. But it's mainly for the applications, not the environment that the OS provides - with it's patchy POSIX support (yeah I know, to get certified you don't have to support all the RT extensions).
I'll second that. I think it's a good idea to mix multiple languages that bare particular strengths, rather than trying to find a single silver bullet. Personally I use Lua and C++, for which I wrote my own binding libraries to tailor to my particular needs. However atop this I also use GLSL for graphics and Python for my build system. I wouldn't have it any other way, and it works in wonderous harmony.
People often go on about the "compiler generated overhead" in C++, which always made me believe that function pointers would be just as fast or faster than virtual functions. So I went along with this belief and passed function pointers around instead of just having a virtual function in a base class - I'm talking about one particular situation here where I had the choice of the 2 and I wanted maximum performance, this isn't something I blindly do all the time, virtual functions are infinitely useful and function pointers are a pain in the ass. However one day I thought I'd benchmark the 2 for the hell of it and challenge my assumptions. Turns out, at least with GCC 4 under Linux, virtual methods are significantly faster, especially when optimisations are turned on. So sometimes it's not compiler generated overhead, but rather compiler enabled optimisation due to better object model integration.
If you want objects, use C++ - C with GLib is a horrible, horrible hack.
Boost.Program_Options has some odd problems with the GCC visibility flags that cause it to return invalid values. However, after wrapping the header with visibility pragmas it works, and it works well with my needs. I needed a library that would allow me to specify a library on the command line, load that library and add possibly more command line options, then continue processing all other arguments. However PO is rather bloated compared to other options available, but at least it isn't leaking memory like Popt.
Personally I'm not a fan of LuaBind, mainly because it's not as flexible as I'd like and it seems to be getting out of date. But using template metaprogramming techniques, you can create a much cleaner and smaller bridge. Also things like the preprocessor metaprogramming library that comes with Boost are just invaluable. I find if you use Boost judiciously, it can be a very handy tool. A lot of the things it has you'd rather not write yourself, unless you have the time and there is a clear benefit.
Slashdot Mirror
The real problem with that is some of the platform dependencies won't be clearly visible until you've ported the code to other platforms. You may have designed something that works very well with one platform, but is insupportable on another. I believe there is something akin to "the rule of 3", where you only know if something is truly portable if you have successfully ported it to at least 3 different platforms.
Wouldn't this also apply to Apple, who a few years ago declared they were expanding their campus? I believe there was a video of Jobs talking to the Cupertino council. Now their share price has had a meteoric rise.
If they innovated and provided compelling reasons to use their APIs, developers would not want to use a third party API that continued to lag behind. However, third parties are motivated by customer demand to keep up with the latest changes to the API (see MonoTouch). This argument is pretty much moot.
The real problem is NeHe's tutorials are painfully out of date. Modern OpenGL has deprecated or removed a lot of the functionality that is used in those tutorials, and there doesn't seem to be any update for OpenGL 3 or 4.
It's an election year, we Australians need to ensure he is not re-elected. I'm not sure how to go about this, but anyone who has an idea, I'd be willing to help.
That's not true. You have a choice as to what OS you want to run on your desk, and what machine you want to run it on. Mac OS X, Linux and Windows are officially supported - I haven't seen anything else.
Are these x86/x86-64 CPUs? It wasn't particularly clear to me.
How do you determine what "needs" unit testing?
You aim for 100% coverage.
There are also situations that force your hand. If you're using a C library, and you provide it callbacks, if the library wasn't compiled with exception handling support (very rare for C libraries to be on Linux), then you're out of luck. If you throw an exception your whole program fails, you have to longjmp() to a safe point inside your C++ code from where you can throw. I find I have this happen a lot with image libraries, e.g.: libpng and libjpeg.
Best solution is to have all your objects set up before your setjmp(), then when you longjmp() back and throw, your objects should be cleanly deallocated.
There are also advantages to Subversion that Linus states himself [1]. Really the only one of note is that Git isn't so great at having multiple projects in the one repository and the recommendation is to have one per repository and have a super-project that contains pointers to others - which isn't so great a solution.
[1] It was stated in relation to the layout of the KDE repository: http://git.or.cz/gitwiki/LinusTalk200705Transcript
Why should it be dumbed down? I don't go reading Biology articles and expect to know everything. That's why there are links to other articles explaining each bit in more detail.
Linux cannot seriously be called "monolithic".
Well it can't be called a micro-kernel. And the notion of a "hybrid-kernel" is a joke. It's squarely in monolithic town.
There is Moonlight. In the end I'd rather none of these plugins, but if I have to choose, my preference is Flash. Adobe have shown support for multiple platforms, while Microsoft is pretty much delegating that to Mono, which is perpetually playing catch-up.
Wikipedia says >1000, even that seems small from what I remember. I remember a Sony tech spec somewhere that said something in the few thousand.
for every single book on Objective-C/Cocoa there are one hundred C++ or Java tombs
Mass graves? Some people take their language wars way too far.
You can still pass data to a process via a message that causes it to crash. Just as with any program, you still need strict validation on the input, which is the same across processes as within a process. You just can't pass invalid pointers and arbitrarily trash memory (hopefully).
You can have a TLS jmpbuf and setjmp at the start of the thread. So when you segfault you can longjmp to a known location and clean up the thread, continuing on. Ofcourse you can't guarantee the state of the program after this unless you limit the functionality of each thread and make some limited guarantees.
That does not make it significantly different. I'm sure in time you'll see something similar in Java too, they seem to follow each others lead quite a lot.
Sounds like I'd be better off with destructors and RAII. Less code and precise control of object lifetimes.
Hmmm, I'm writing this from my MBP running 10.5.3 - and well, it runs like ass. I've been doing a lot of IPC work lately and my system seems to perform _really_ poorly under load. Safari repeatedly spins, transmission constantly locks up.
I never have these problems under Linux, it runs smooth as butter the whole time. I can always guarantee that performance on my benchmarks will be an order of magnitude better under Linux on an equivalent computer.
Saying all this though, I still like OS X. But it's mainly for the applications, not the environment that the OS provides - with it's patchy POSIX support (yeah I know, to get certified you don't have to support all the RT extensions).
I'll second that. I think it's a good idea to mix multiple languages that bare particular strengths, rather than trying to find a single silver bullet. Personally I use Lua and C++, for which I wrote my own binding libraries to tailor to my particular needs. However atop this I also use GLSL for graphics and Python for my build system. I wouldn't have it any other way, and it works in wonderous harmony.
People often go on about the "compiler generated overhead" in C++, which always made me believe that function pointers would be just as fast or faster than virtual functions. So I went along with this belief and passed function pointers around instead of just having a virtual function in a base class - I'm talking about one particular situation here where I had the choice of the 2 and I wanted maximum performance, this isn't something I blindly do all the time, virtual functions are infinitely useful and function pointers are a pain in the ass. However one day I thought I'd benchmark the 2 for the hell of it and challenge my assumptions. Turns out, at least with GCC 4 under Linux, virtual methods are significantly faster, especially when optimisations are turned on. So sometimes it's not compiler generated overhead, but rather compiler enabled optimisation due to better object model integration. If you want objects, use C++ - C with GLib is a horrible, horrible hack.
Boost.Program_Options has some odd problems with the GCC visibility flags that cause it to return invalid values. However, after wrapping the header with visibility pragmas it works, and it works well with my needs. I needed a library that would allow me to specify a library on the command line, load that library and add possibly more command line options, then continue processing all other arguments. However PO is rather bloated compared to other options available, but at least it isn't leaking memory like Popt.
Personally I'm not a fan of LuaBind, mainly because it's not as flexible as I'd like and it seems to be getting out of date. But using template metaprogramming techniques, you can create a much cleaner and smaller bridge. Also things like the preprocessor metaprogramming library that comes with Boost are just invaluable. I find if you use Boost judiciously, it can be a very handy tool. A lot of the things it has you'd rather not write yourself, unless you have the time and there is a clear benefit.
I think it's actually 5 years. They must have one hell of a deal.