GetVersionEx(Inout_ LPOSVERSIONINFO lpVersionInfo); Returns the major and minor versions, build number, platform id, service pack major and minor, and the product type.
I have been coding in C for a while (10 yrs or so) and tend to use short code snippets. As a simple example, take 'if (!ptr)' instead of 'if (ptr==NULL)'. The reason someone might use the former code snippet is because they believe it would result in smaller machine code if the compiler does not do optimizations or is not smart enough to optimize the particular code snippet.
That's simply inane. Why don't you check the assembly your compiler generates? If your're really up for shits and giggles, compare it to a C compiler from 10 years ago.
IMHO the latter code snippet is clearer than the former, and I would use it in my code if I know for sure that the compiler will optimize it and produce machine code equivalent to the former code snippet.
So why are you asking here? Check what your compiler generates.
Incidentally, I find the former more readable. While you might be under the illusion that people do use it as an optimization technique, many simply find it easier to read and write. It's a widely accepted and understood idiom for checking pointer validity. And in C++, it has the benefit of being able to look the same whether ptr is a smart pointer or a raw pointer.
The previous example was easy. What about code that is more complex? Now that compilers have matured over years and have had many improvements, I ask the Slashdot crowd, what they believe the compiler can be trusted to optimize and what must be hand optimized?
Write readable code. Ask a profiler what you need to optimize.
Except, of course, it's not gcc3, and isn't compatible with gcc3's ABI.
It doesn't bother me so much that gcc 2.96 is the primary compiler in Red Hat 7.3; but the availability of gcc3 RPMs for concurrent installation with 2.96 was extremely useful for those of us who need to compile modern C++ code that just won't work with 2.96. Those RPMs are sorely missed in Red Hat 7.3.
Is there any chance they'll make it back in an update?
Microsoft has gone to a lot of effort to ensure that you don't have the level of control you're seem to want in this rant. If you really wanted this level of control, you'd use a product that offered it. Instead, Windows consumers have demonstrated to Microsoft that they don't care. Microsoft users will suffer through countless reboots. They'll even readily grab their ankles for a complete reinstall when some poorly written software hoses their fragile system.
Windows users will not only tolerate, but pay for all of that. And they'll pay for it, as Microsoft well knows, because it's applications that sell Windows. So they'll ensure that application developers can fully commandeer your machine if they want to, because that's what application developers say they need to make the users happy.
Who would ever have imagined that such privileges can be misused and abused?
Now stop whining to the government to protect you from yourself and start making some forward-thinking decisions about the software you use and support.
A better algorithm will always beat out a bad algorithm written in a "faster" language on a faster computer.
That assumes that your program is limited by the algorithm it's using to perform a task, as opposed to limitations in the system. Unfortunately, with Java, it's those limitations built into the system that tend to bite you in the ass.
Java relies heavily on dynamic binding. That's a double edged sword. It makes Java a great RAD tool, but a poor performer. Toy benchmarks aside, Java apps run slower than their C++ equivalents. And that's not something you can fix by optimizing the VM. Java itself is designed to rely on that degree of dynamic binding, and you can't optimize all of that away without changing the language itself.
"Of course, with things like STL and Java, I think programmers of other languages are also becoming pretty ignorant."
That's a pretty ignorant comment, especially considering the context.
While naive programmers may see the STL as just another grab-bag of functionality, naive programmers will see any library that way. Put in its proper perspective, though, the STL is a framework for generic programming. Generic programming actually has a lot more in common with Lisp programming than the conventional way C and C++ have been applied. I find generic programming generally requires a good deal more thought and planning in the early stages of design, but the reward is more concise, more consistent, and thus easier to understand code. It takes practice, and you don't tend to find naive programmers developing software this way.
Naive application of the STL, though, is very easy to spot. The STL isn't increasing the number of naive programmers, but it certainly may make naive programmers more visible. The author's comment strikes me as just another case of blaming the tool when the problem is the user.
ParallelGraphics has put together some slick VRML scenes depicting the salvage operation. There's a link from their home page. It needs their VRML browser, but if you're running Windows it's worth a look.
It takes a lot more than OO design to solve this problem. The fact is that initial designs are almost always naive, and lack the specific flexibilities (and inflexibilities) the Ideal Solution would require. So, very often, are second iterations. But the third time's usually the charm.
The need to depart from backward compatibility is the result of correcting design flaws. And design flaws happen, regardless of your programming methodology. Design flaws are less a product of programming methodology, and more a product of not completely knowing the problem.
Java accommodates design flaws a little bit better not by being object-oriented, but by relying so heavily on dynamic binding. While this can make recovering from Bad Design simpler, it only lets you create bandaids that do nothing to fix the original design problems. And all that dynamic binding costs Java in performance across the board.
The charge of Netscape revenue not going back to mozilla.org is more than a little ridiculous. Netscape/AOL pockets have been the primary funding for mozilla.org for some time now, in terms of both equipment and manpower. I don't see any reason why mozilla.org ought to resent the ads in Netscape. Users, OTOH, will likely find plenty of reasons to resent the gratuitous nature of Netscape's commercialization. And they should. It's insulting. It's Netscape saying, "We think our users are such mindless tools that we can deliver them a browser overflowing with ads that they could otherwise get for free."
There's absolutely nothing wrong with leveraging open code for commercial ends. The problem is that Netsape/AOL have bungled it badly. What value do their commercial additions add to the product? Is the additional software and advertising actually useful to many users? Is it useful enough to those users that they'll endure the ads rather than turn to ad-free alternatives?
A fine balance must be struck between annoying ads and the useful features that justify them. Not only has Netscape failed to achieve this balance, it has failed badly--partly due to gratuitous ads, and partly due to not-quite-finished software.
The result will be that users will turn to competing products--including, in all likelihood, the mozilla.org distribution of the browser. That wasn't supposed to *be* a competing product--Netscape was supposed to be able to add enough value that Mozilla would only be of interest to developers.
Enums are strongly typed in non-brain dead C++ compilers. It's a part of the language, not a compiler frill. Blame Visual C++ (one of the least stanard-conforming compilers in the industry) for the shoddy code you have to deal with.
I wonder if MS has managed to add this feature to their C++ compiler yet, or if they're just hoping anyone who wants a properly functioning compiler will move to C#.
You idiot. The masculine declension in Latin is pluralized with -i, not -ii. Correct plurals for "virus" are either "viruses" (Anglicized) or "viri" (Latin). "virii" is never correct.
Open source software developers should indeed be culpable for the code they write. They should answer to whomever has paid them to be culpable. But should culpability be automatic? Of course not. Who in their right mind would write open source software if it were possible that someday, out of the blue, someone could sue them because the software didn't work as expected?
The inevitability of bugs is one of the reasons OSS makes so much sense. Just about every open source license I see includes a clause that obviates culpability of the authors for any unintended features. I don't have a problem with that. Hey, it's free! What bugs me is that more or less the same disclaimer can be found in the EULAs of commercial software packages. It is the norm for commercial software vendors to sell goods which are not claimed to be suitable for any particular purpose (or similar wording). That, I have a problem with.
Who in their right mind would pay money for something not guaranteed to be suitable for any particular purpose??? A lot of people, amazingly. Hell, I have to admit I did, before I wised up. Software with no warranty isn't worth paying for. But software warranted to work? Now that's a valuable thing.
Slashdot Mirror
There, I said it.
Holy cow has nobody learned their lesson about Kickstarter?
1. MAKE THE THING YOU SAID YOU WERE GOING TO MAKE. 2. DO THE EXTRA STUFF.
People seem to always skip to step 2 and never manage to hit step 1.
While we're discussing teachable moments, let's touch on "making crucial, consequential changes in staff and scope" based on "a verbal commitment".
Seriously.
GetVersionEx(Inout_ LPOSVERSIONINFO lpVersionInfo);
Returns the major and minor versions, build number, platform id, service pack major and minor, and the product type.
Deprecated as of Windows 8.1. Unfortunately, what appears to be the only remotely adequate replacement for it requires resorting to WMI.
Sonic the Hedgehog!
The Me-262 was a jet. The Komet was the Me-163. Neither of these were BWB craft.
Well, what's to stop other party from creating a binary distribution? Called, say, "Untied Linux".
Except, of course, it's not gcc3, and isn't compatible with gcc3's ABI.
It doesn't bother me so much that gcc 2.96 is the primary compiler in Red Hat 7.3; but the availability of gcc3 RPMs for concurrent installation with 2.96 was extremely useful for those of us who need to compile modern C++ code that just won't work with 2.96. Those RPMs are sorely missed in Red Hat 7.3.
Is there any chance they'll make it back in an update?
Why play with risky new drugs when there are proven safe, effective, and more enjoyable ways of getting the same effect?
Windows users will not only tolerate, but pay for all of that. And they'll pay for it, as Microsoft well knows, because it's applications that sell Windows. So they'll ensure that application developers can fully commandeer your machine if they want to, because that's what application developers say they need to make the users happy.
Who would ever have imagined that such privileges can be misused and abused?
Now stop whining to the government to protect you from yourself and start making some forward-thinking decisions about the software you use and support.
That assumes that your program is limited by the algorithm it's using to perform a task, as opposed to limitations in the system. Unfortunately, with Java, it's those limitations built into the system that tend to bite you in the ass.
Java relies heavily on dynamic binding. That's a double edged sword. It makes Java a great RAD tool, but a poor performer. Toy benchmarks aside, Java apps run slower than their C++ equivalents. And that's not something you can fix by optimizing the VM. Java itself is designed to rely on that degree of dynamic binding, and you can't optimize all of that away without changing the language itself.
That's a pretty ignorant comment, especially considering the context.
While naive programmers may see the STL as just another grab-bag of functionality, naive programmers will see any library that way. Put in its proper perspective, though, the STL is a framework for generic programming. Generic programming actually has a lot more in common with Lisp programming than the conventional way C and C++ have been applied. I find generic programming generally requires a good deal more thought and planning in the early stages of design, but the reward is more concise, more consistent, and thus easier to understand code. It takes practice, and you don't tend to find naive programmers developing software this way.
Naive application of the STL, though, is very easy to spot. The STL isn't increasing the number of naive programmers, but it certainly may make naive programmers more visible. The author's comment strikes me as just another case of blaming the tool when the problem is the user.
ParallelGraphics has put together some slick VRML scenes depicting the salvage operation. There's a link from their home page. It needs their VRML browser, but if you're running Windows it's worth a look.
It takes a lot more than OO design to solve this problem. The fact is that initial designs are almost always naive, and lack the specific flexibilities (and inflexibilities) the Ideal Solution would require. So, very often, are second iterations. But the third time's usually the charm.
The need to depart from backward compatibility is the result of correcting design flaws. And design flaws happen, regardless of your programming methodology. Design flaws are less a product of programming methodology, and more a product of not completely knowing the problem.
Java accommodates design flaws a little bit better not by being object-oriented, but by relying so heavily on dynamic binding. While this can make recovering from Bad Design simpler, it only lets you create bandaids that do nothing to fix the original design problems. And all that dynamic binding costs Java in performance across the board.
The charge of Netscape revenue not going back to mozilla.org is more than a little ridiculous. Netscape/AOL pockets have been the primary funding for mozilla.org for some time now, in terms of both equipment and manpower. I don't see any reason why mozilla.org ought to resent the ads in Netscape. Users, OTOH, will likely find plenty of reasons to resent the gratuitous nature of Netscape's commercialization. And they should. It's insulting. It's Netscape saying, "We think our users are such mindless tools that we can deliver them a browser overflowing with ads that they could otherwise get for free."
There's absolutely nothing wrong with leveraging open code for commercial ends. The problem is that Netsape/AOL have bungled it badly. What value do their commercial additions add to the product? Is the additional software and advertising actually useful to many users? Is it useful enough to those users that they'll endure the ads rather than turn to ad-free alternatives?
A fine balance must be struck between annoying ads and the useful features that justify them. Not only has Netscape failed to achieve this balance, it has failed badly--partly due to gratuitous ads, and partly due to not-quite-finished software.
The result will be that users will turn to competing products--including, in all likelihood, the mozilla.org distribution of the browser. That wasn't supposed to *be* a competing product--Netscape was supposed to be able to add enough value that Mozilla would only be of interest to developers.
Enums are strongly typed in non-brain dead C++ compilers. It's a part of the language, not a compiler frill. Blame Visual C++ (one of the least stanard-conforming compilers in the industry) for the shoddy code you have to deal with. I wonder if MS has managed to add this feature to their C++ compiler yet, or if they're just hoping anyone who wants a properly functioning compiler will move to C#.
You idiot. The masculine declension in Latin is pluralized with -i, not -ii. Correct plurals for "virus" are either "viruses" (Anglicized) or "viri" (Latin). "virii" is never correct.
Open source software developers should indeed be culpable for the code they write. They should answer to whomever has paid them to be culpable. But should culpability be automatic? Of course not. Who in their right mind would write open source software if it were possible that someday, out of the blue, someone could sue them because the software didn't work as expected?
The inevitability of bugs is one of the reasons OSS makes so much sense. Just about every open source license I see includes a clause that obviates culpability of the authors for any unintended features. I don't have a problem with that. Hey, it's free! What bugs me is that more or less the same disclaimer can be found in the EULAs of commercial software packages. It is the norm for commercial software vendors to sell goods which are not claimed to be suitable for any particular purpose (or similar wording). That, I have a problem with.
Who in their right mind would pay money for something not guaranteed to be suitable for any particular purpose??? A lot of people, amazingly. Hell, I have to admit I did, before I wised up. Software with no warranty isn't worth paying for. But software warranted to work? Now that's a valuable thing.