i feel that this will mark the decline of perl. please don't take what i say as flamebait - perl will always be the language of choice for system administration - but ruby will eat up the application market's need for a fast, scriptable language. it's portable, it's syntax is wonderful, and it makes RAD a cinch (in contrast to perl, java, c, and c++ combined).
i'm enthusiastic about ruby's future (can't you tell).
STL, as all the previous posts have mentioned, does not involve virtual inheritance overhead (unless, of course, you derive from the STL - YOYO at that point).
however, that doesn't mean that there aren't any "cons" to the STL. if you don't catch exceptions thrown back from a contain, your bound (no pun intended) for trouble. expect performance hits if you insert into a vector, or you don't allocate sufficient memory ahead of time. the STL only wraps common data structure and their operations - the idea being that you don't have to write a list for Class A and Class B and Class C; you can just create a template of a list that holds a Class A or Class B or Class C. the behavior of a list is similar, the only difference between lists is what they hold.
perhaps what bill was really try to say was "there is a lot of overhead with using C++" for embedded and realtime platforms. that, i would agree with - to an extent. i would have to say that the big performance hit on a RTS w/ C++ would be vlookups against the vtable - but how would that compare to a large switch-case block? the vtable itself may consume a bit more memory, but it might cost much less in manhours and frustration to work with derived classes than to maintain switch case logic. remember, every time someone adds some new functionality, someone has to go through a full compilation/regression test w/ a switch-case. by adding a derived class, you only need to compile/test the class itself.
Well, since Jamie claims IE users are only a small minority of users that thread I posted above, then I guess it won't affect his subscriber too badly, will it?
Besides, Sega has a horrible track record with Hardware.
Only if you believe the marketing hype. Ask anyone who has played the Dreamcast, and I'm almost certain that 90% of them will comment on how comfortable and intuitive the controller is; true, it's stolen from the SNES, but they actually went out and made it big enough for most adult's hands.
I actually prefer the graphics rendering over that of the PS2 - it seems that many games, like Crazy Taxi or Skies of Arcadia, look much "cleaner" when compared to games like GT3 or Metal Gear. This isn't to comment on the gameplay (GT3 and Metal Gear are both amazing), but it seems like, for such an expensive system (in contrast to something like the GameCube), it should at least have graphics to match.
Sega failed at the hardware market because they never stuck it out; if they decided to stay for another year or so, they could have at least remained competitive against the likes of Sony and Nintendo. But Dreamcast became the nail in the coffin - they'll never be able to get back into selling hardware successfully now. They have too much of a reputation of putting out obsolete systems...
Actually, the Kai compiler (which is what the intel compiler really is) was multiplatform. And it would still outperform other compilers because it would generate platform-optimized C code, then call the native compiler/linker on that platform to create the executable. This way, you could write one set of code, compiler across different platforms, and still have a tight, fast, optimized executable.
Unforunately, Intel bought them out, and dropped multi-platform support...
We use Kai (or KCC) at work, and it is truely a remarkable product. It's a two-stage compiler - it generates C code native to the platform your working on, then calls the compiler/linker for that platform to compile it. The idea here is that the native compilers for any given platform will be able to optimize for that platform. So Kai just optimizes what it can and dumps it out into C code, then calls the native compiler/linker with optimizations on to recompile that code into the executable. The Kai C++ compiler was ported to Windows, Solaris, Linux, IRIX, etc., so there was the added benefit that any code written with Kai in mind would compile easily across other machines.
Kai and GCC are very similar in concept, except that Kai was a bit of a "higher end" compiler. Think of GCC being the Toyota of compilers, and KCC being the Lexus of compilers. You may pay the extra bucks just for the optimization/cross-platform abilities that Kai has - but most normal folk don't need it.
Unfortunately, Kai got purchased by Intel, and (from what I see on their site) they seem to be dropping the other platforms to support only intel. Really, the Intel compiler is really the Kai compiler, but only for Intel. In fact, Kai (Kuck and Associates Inc.), is now part of Intel. Personally, I think this sucks, since Kai really is a superior product compared to any other C++ compiler out there, if you will to pay the extra $$$...
Remember that yahoo decided to branch off from being a "pure" search engine (e.g. "google") to become more of a web portal. I think yahoo is still trying to be profitable as a "web portal" (e-mail, shopping, chat) company, and part of its "portal" services will be a pay websearch service. However, IMHO, I doubt it will be very profitable against a free engine like google, or the other competition (altavista, excite, hotbot, )
If yahoo really wanted to make a profit on its search engine capabilities, it should have advertising like google, but it would point to yahoo sponsored sites, such as its shopping network or yahoo member pages. Then yahoo should charge a small commission for each sale done through its site (ala ebay)...
I really don't know why people are complaining. To me, this seems like a good thing.
First of all, this isn't AOL/Time/Warner buying out Linux, this is AOL/Time/Warner buying out Red Hat. Linux will be alive and well, and Red Hat will become whatever AOL wants it to become.
Second, AOL can provide the $$ to make RH a contender against Microsoft. Right now, Microsoft is (for all intents and purposes) the only operating system out there aimed for middle-income home users. AOL can help break that monopoly into a duopoly by introducing a user-friendly version of RH. Sure, far from ideal, but certainly better than having Microsoft still control the home market.
As long as there's Slackware/Caldera/Debian/* Linux distros, Linux will survive w/o Red Hat.
Slashdot Mirror
of "Structured Computer Organization" fame...
except in the case of xbox controllers. i guess those developers must be giants over at redmond..
i feel that this will mark the decline of perl. please don't take what i say as flamebait - perl will always be the language of choice for system administration - but ruby will eat up the application market's need for a fast, scriptable language. it's portable, it's syntax is wonderful, and it makes RAD a cinch (in contrast to perl, java, c, and c++ combined).
i'm enthusiastic about ruby's future (can't you tell).
STL, as all the previous posts have mentioned, does not involve virtual inheritance overhead (unless, of course, you derive from the STL - YOYO at that point).
however, that doesn't mean that there aren't any "cons" to the STL. if you don't catch exceptions thrown back from a contain, your bound (no pun intended) for trouble. expect performance hits if you insert into a vector, or you don't allocate sufficient memory ahead of time. the STL only wraps common data structure and their operations - the idea being that you don't have to write a list for Class A and Class B and Class C; you can just create a template of a list that holds a Class A or Class B or Class C. the behavior of a list is similar, the only difference between lists is what they hold.
perhaps what bill was really try to say was "there is a lot of overhead with using C++" for embedded and realtime platforms. that, i would agree with - to an extent. i would have to say that the big performance hit on a RTS w/ C++ would be vlookups against the vtable - but how would that compare to a large switch-case block? the vtable itself may consume a bit more memory, but it might cost much less in manhours and frustration to work with derived classes than to maintain switch case logic. remember, every time someone adds some new functionality, someone has to go through a full compilation/regression test w/ a switch-case. by adding a derived class, you only need to compile/test the class itself.
I agree. Slashdot has let this bug go on way too long. And you know what? Jamie McCarthy has been given the patch to fix this, but he chooses not to implement it!
Well, since Jamie claims IE users are only a small minority of users that thread I posted above, then I guess it won't affect his subscriber too badly, will it?
Besides, Sega has a horrible track record with Hardware.
Only if you believe the marketing hype. Ask anyone who has played the Dreamcast, and I'm almost certain that 90% of them will comment on how comfortable and intuitive the controller is; true, it's stolen from the SNES, but they actually went out and made it big enough for most adult's hands.
I actually prefer the graphics rendering over that of the PS2 - it seems that many games, like Crazy Taxi or Skies of Arcadia, look much "cleaner" when compared to games like GT3 or Metal Gear. This isn't to comment on the gameplay (GT3 and Metal Gear are both amazing), but it seems like, for such an expensive system (in contrast to something like the GameCube), it should at least have graphics to match.
Sega failed at the hardware market because they never stuck it out; if they decided to stay for another year or so, they could have at least remained competitive against the likes of Sony and Nintendo. But Dreamcast became the nail in the coffin - they'll never be able to get back into selling hardware successfully now. They have too much of a reputation of putting out obsolete systems...
I like the graphics change
you must not have read/referenced anything published by Addison-Wesley...
you must not have read any books published by Addison-Wesley.
They didn't produce the compiler - Kuck and Associates did. Intel bought them out. The guy who invented it has been around for a while - here is a short bio on him.
Actually, the Kai compiler (which is what the intel compiler really is) was multiplatform. And it would still outperform other compilers because it would generate platform-optimized C code, then call the native compiler/linker on that platform to create the executable. This way, you could write one set of code, compiler across different platforms, and still have a tight, fast, optimized executable.
Unforunately, Intel bought them out, and dropped multi-platform support...
We use Kai (or KCC) at work, and it is truely a remarkable product. It's a two-stage compiler - it generates C code native to the platform your working on, then calls the compiler/linker for that platform to compile it. The idea here is that the native compilers for any given platform will be able to optimize for that platform. So Kai just optimizes what it can and dumps it out into C code, then calls the native compiler/linker with optimizations on to recompile that code into the executable. The Kai C++ compiler was ported to Windows, Solaris, Linux, IRIX, etc., so there was the added benefit that any code written with Kai in mind would compile easily across other machines.
Kai and GCC are very similar in concept, except that Kai was a bit of a "higher end" compiler. Think of GCC being the Toyota of compilers, and KCC being the Lexus of compilers. You may pay the extra bucks just for the optimization/cross-platform abilities that Kai has - but most normal folk don't need it.
Unfortunately, Kai got purchased by Intel, and (from what I see on their site) they seem to be dropping the other platforms to support only intel. Really, the Intel compiler is really the Kai compiler, but only for Intel. In fact, Kai (Kuck and Associates Inc.), is now part of Intel. Personally, I think this sucks, since Kai really is a superior product compared to any other C++ compiler out there, if you will to pay the extra $$$...
Remember that yahoo decided to branch off from being a "pure" search engine (e.g. "google") to become more of a web portal. I think yahoo is still trying to be profitable as a "web portal" (e-mail, shopping, chat) company, and part of its "portal" services will be a pay websearch service. However, IMHO, I doubt it will be very profitable against a free engine like google, or the other competition (altavista, excite, hotbot, )
If yahoo really wanted to make a profit on its search engine capabilities, it should have advertising like google, but it would point to yahoo sponsored sites, such as its shopping network or yahoo member pages. Then yahoo should charge a small commission for each sale done through its site (ala ebay)...
Seeing that they cache webpages from other sites, I wonder how long it will take before another company sues them?
Also, I wonder what their criteria will be for "submissions"? 1 month? 1 year?
I really don't know why people are complaining. To me, this seems like a good thing.
First of all, this isn't AOL/Time/Warner buying out Linux, this is AOL/Time/Warner buying out Red Hat. Linux will be alive and well, and Red Hat will become whatever AOL wants it to become.
Second, AOL can provide the $$ to make RH a contender against Microsoft. Right now, Microsoft is (for all intents and purposes) the only operating system out there aimed for middle-income home users. AOL can help break that monopoly into a duopoly by introducing a user-friendly version of RH. Sure, far from ideal, but certainly better than having Microsoft still control the home market.
As long as there's Slackware/Caldera/Debian/* Linux distros, Linux will survive w/o Red Hat.