However, OO in particular is primarily intended to support re-use by derivation -- without that, there is no real point in using it at all, especially in C++, which offers so many other mechanisms for expressing solutions to problems. I would thus argue that the very act of using OO to write code that does not support re-use is an indication that the programmer(s) did not design and write their code for a particular purpose, but were instead trying to force certain types of problems into a paradigm that is ill-suited to them.
If you can find it, I'd advise reading "Code reuse, concrete classes, and inheritance" by Scott Meyers. Unfortunately, it's an article from the July/August 1994 issue of The C++ Report, so finding it probably won't be easy (and while Scott cites it on his site, he doesn't have a link to an online copy).
Lacking that, you might want to read this Usenet post, which at least discusses the basic problem.
What it comes down to is pretty simple though: in C++, a class should be designed to be used as a base class, OR to be instantiated, but you generally can't write a class that supports both properly.
It is perfectly possible to write a general-purpose programming language which is well-suited to both systems programming and applications programming without adding undue complexity. Oberon is a good example of such a language: its entire grammar can be expressed in 20 pages, and it is very easy indeed for any experienced programmer to learn, yet it can be (and indeed has been) used to write everything from operating systems through MVC frameworks to applications.
Learning Oberon well enough to use it is one thing -- the question was whether most users really know all the rules in their entirety. Quite frankly, I can't answer that very well. Offhand, I don't think I've ever known anybody who really did, but I've known only a few people who used Oberon at all, and it's possible they were the exception to the rule.
OTOH, learning enough of C++ to use it (and even use it quite well) doesn't require memorizing the entire C++ standard or anythign like it either. I doubt that even 5% of the good C++ programmers I've known have ever even attempted to learn all the details of two-phase lookup or anything like that. Of course, it probably helps that there's only one compiler (Comeau) that implements two-phase lookup nearly correctly, so most people have little reason to care a lot about it.
In both cases, the learning process is eased when there is a set of simple grammatic rules that are consistently applied, and becomes progressively more difficult when the complexity of the grammar increases, and / or the number of exceptions to the rules it expresses grow.
I can't say I really agree. FORTRAN has about the most god-awful grammar ever invented, but doesn't seem significantly more difficult to learn than most of the other mainstream imperative languages. At the opposite end of the spectrum, you could probably fit the grammars for Brainfsck, unlambda and Intercal all onto a single page, but good luck on ever really learning any of them.
This is especially true when a new feature is unfamiliar to existing programmers, and may therefore require a degree of training before (a) they can use it, and (b) realise why using it is a good idea, even though it may initially appear to require some extra work to use effectively. It is I think the reason why the STL still isn't utilised anything like as often as it should be: people think "Oh, templates", and start to read up on them, and it looks hellishly complicated and arcane, so they give up before realising that the level of knowledge required for using the pre-built templates in the STL can be grasped in a matter of hours. This would doubtless be even more true for DbC,
Yes, it's silly, but not for the reason you're thinking.
If WD had as good of marketing as some companies I can think of, they'd have put the windowless version on the market for a couple of months so the bleeding edge types would all buy it up. Then they would have released this, so those same people would replace their still nearly-new windowless version with this one.
A few months after that, they might start selling a new version with pre-installed internal LEDs. If they knew their fans were really loyal, they'd even start with just one color of LED, and then a year later (or so) come out with new versions in various different colors, and not only rake in the dough yet again, but get to listen to their fans proclaiming to the world what a privilege it is to get to buy from such a brilliant and innovative company.
Of course, if they were really that brilliant and innovative, they'd have to do all of this with a 40 Gb drive that was slower than anything else on the market -- if you have to engineer a decent product to sell it, your reality distortion technology is clearly inferior!
I think therefore that _all_ C++ books and courses should expound a rule in big, bold letters in a box that says "C++ has a variety of mechanisms that make the use of pointers for dynamically allocated member variables unnecessary. If however you are going to use pointers as member variables, you should provide your class with a copy constructor that initialises them properly when they are assigned to another variable of the same type."
In general, I'd tend to agree. Actually, most of the better books talk about this as the law of the big three. The "big three" are the destructor, the copy constructor and the assignment operator. In nearly every case, if you need to explicitly define any one of them (typically because your class has remote data referenced through a pointer) then chances are that you need all of them. IMO, there's very little excuse for books that (often flagrantly) violate this basic rule. It's been (for one example) in the comp.lang.c++ FAQ list since something like 1991 or so. While I realize Usenet doesn't constitute the entire world, or even the entire programming world, I see little excuse for somebody claiming to teach C++ when/if they don't know at least this much.
There is a golden rule in OO which says "Do not make any assumptions about the way people will use your classes".
IMO, this isn't a golden rule or even a good rule. Quite the contrary, I think code (OO or otherwise) should be designed and written for a particular purpose. If that purpose is to be derived from, good and well. If it's not, throwing in something to halfheartedly support derivation anyway is a poor idea. Going further and fully supporting derivation makes a bad situation still worse. You're still doing extra work, and probably introducing extra bugs, to make the code do something it's not really supposed to do. This is one area I agree with the people who advocate testing-oriented development -- you should define what the code really needs to do, and then write the simplest code you can that does it. Any extra capabilities, features, etc., beyond what it's really supposed to do is a bad thing.
If a class isn't designed to be a base class, then there should be a header comment or some other piece of documentation that says so, otherwise people will assume they can inherit from it, and do so.
The fact that the dtor is non-virtual IS documentation that says so. Better still, this documentation never gets out of sync with the code, because it's part of the code. The problem is that quite a few people reading the documentation don't really understand the language in which it's written (i.e. C++) very well. With that given, it's not necessarily a bad thing to add a comment or other documentation to expound on the fact, but it really should be redundant.
...some commercial RDBMS servers for example have code bases that pre-date C++ (or at least pre-date it becoming well known and popular), as do an astonishingly large collection of other applications. Rewriting such code bases in C++ (and then testing them exhaustively for functional compliance with the old one) would be an extremely expensive endeavour indeed, so any use of C++ is as an addition to the legacy code base, not a replacement for it.
With a minor quibble, I agree. The minor quibble is that I'd say it's really "most" rather than "any" use of C++ being an addition to the legacy code base. Ocassionally, somebody really does start something over from a relatively clean slate rather than adding to existing code -- but I certainly agree that it's relatively unsual.
...I would suggest that a root cause of the poor quality of didactic materials for C++ is that (a) it is an extremely difficult language to teach because it is so complex, and (b) said complexity means that those attemp
1. A class is a struct with different default member visibility rules. C++ structs are C structs wth some extra stuff, and _follow C struct copying rules_. In a purely C++ context, this means that classes without a copy constructor will effectively have a default one supplied by the system that does a bitwise copy, which can cause all manner of problems for classes with members that are pointers. Simple solution: get into the habit of writing copy constructors for all classes except those you _know_ can get by with the default one.
This is about half true -- it's true that classes that contain raw pointers generally need copy ctors. What's done, however, is not a bitwise copy, but a memberwise copy. The cure isn't to use copy ctors though. The cure is to not use raw pointers on a regular basis. I can hardly remember the last time I had to write a copy ctor because I used a raw pointer.
2. Classes with non-virtual destructors will not destroy themselves properly when used polymorphically, and this can lead to memory leaks in code that appears to be perfectly correct. Solution: make all destructors virtual unless there is an excellent reason for not doing so (e.g. performance). Such a reason should be documented so that people deriving classes from yours know about it, and can guard against it.
This is a problem part of the time, but not really very often. A class that doesn't have a virtual dtor generally means that class wasn't designed as a base class.
There is (occassionally) a problem with a class that was intended to be used as a base class, but due to oversight the dtor wasn't made virtual. In this regard, C++ could be improved -- rather than requiring an explicit virtual dtor, it should make the dtor virtual if the class contains any virtual function.
There are, however, quite a few classes that really have no use for any virtual functions at all -- and there's no point in making their dtors virtual, because deriving from them won't accomplish anything useful anyway.
IOW, much of the problem really arises from teachers trying to push OO as the answer to everything, and overusing derivation when it's not suitable or useful.
[talking about C++ having advantages for system programming]
If this is the case, then why isn't it used more for systems programming tasks? By far the bulk of systems programming still seems to be done in C, and this includes both embedded code, and OS kernels for general-purpose computing.
Of course, any answer to this is more or less a guess, since it's basically about the motivations people had for the decisions they made.
I suspect part of it is that many (most?) people who write code that works directly with hardware do so largely because they like the "feel" of working directly with the hardware -- and they simply don't like a language taking away that feel, regardless of how well it might work.
Second, OS designs tend to be nearly as conservative as possible. Consider, for example, that Microsoft's OSes prior to Windows NT (e.g. DOS, Windows 1.x, 2.x, 3.x) were still written primarily in assembly language! With Windows NT, they changed to primarily C. Direct from assembly language to modern C++ would be an awfully large jump though.
Third, OS designs tend change relatively slowly. The obvious mainstream OSes right now are Linux and Windows. Both have been around since the early '90s or so. At that time, most of what I'm talking about in C++ hadn't even been defined yet, not to mention actually being implemented. Worse, Microsoft (for one example) has only recently made a serious attempt at getting their compiler close to fully compliant with the C++ standard, so many of the best techniques simply haven't been available to them until quite recently.
On the Linux side things weren't quite as grim, but not really a whole lot better either. Worse, the educa
In order for a patent to be valid, the entity (person or company) owning the patent must produce at least one (1) working, real, physical example of whatever it is that they are patenting.
Not a new idea -- in fact, once upon a time, you were required to submit a working model with every patent application (in the US). The USPTO still has a museum of these working models, but storage became a problem.
Otherwise, the product/concept/business process/whatever else we've decided is patentable this week is subject to invalidation if someone else can produce a working example first. This would completely eliminate "patent trolls" and would provide a much larger incentive for entities seeking patents to bring their ideas/concepts/products to market more quickly.
This, however, favors larger companies (and such) with greater resources even more strongly than is currently the case. Assume, for example, that I have an idea for how to make CPUs twice as fast without using any more power than is currently the case. To build a single CPU using this technique I have to raise something like a million dollars just for mask work. Meanwhile Intel or IBM gets wind of the idea, and uses my invention to build a few CPUs in their own fab, so I can't get a patent on my idea -- in short, you've legalized their stealing my invention.
There should be a law to make public the patents that are in dispute in plain English.
Let's see -- how about if we went a bit further, and required that all of every patent be made public, even if it's not in dispute. Then we could require that the patent itself require a description of what it covers, in plain English. As long as we're at it, we might as well require that it not only describe the invention itself, but how to make and use it, and require that this description be understandable to anybody who works in that area of technology.
Maybe wording something like this:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Wouldn't that be great?
Looking at 35 USC 112, maybe that idea's not very original though.
So slowly C++ will become Ada? Are there really any substanive differences in Ada and C++0X other then using "{ }" vs. using "begin end" and simalar trivia?
C++ templates provide capabilities that are difficult (if even possible) to match with Ada generics. Look through the Boost library at things like bind and lambda, and try to figure out how to do similar things with Ada. I wouldn't say they're impossible, but at best they're considerably more difficult.
1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.
C99 includes <stdint.h> that provides standard types for things like integers guaranteed to have exactly 32 bits and such. While I'd expect it to be renamed to <cstdint>, it would be quite surprising if C++ 0x didn't include essentially the same thing.
2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.
This depends heavily upon what you do and how you do it. Some C++ features tend to lead to code that's slower than the most obvious equivalents in C -- but in other cases, exactly the opposite is true. Just for an exceptionally obvious example of the latter, try sorting an array of integers with qsort and then do the same with std::sort.
3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).
Your premise is that it's difficult to validate, but your conclusion would only be valid if it was actully impossible to validate. From a practical viewpoint, however, the difficulty is more or less irrelevant -- the real question is whether a compiler has been validated or not, and if not the language isn't usable for that purpose, regardless of how easy or difficult the validation might be.
4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.
To my knowledge, the language contains two actual ambiguities, both of which are resolved by fiat, so to speak. One of these was inherited from C, while the other is new to C++ (though fundamentally similar to the one inherited from C).
My guess is that you aren't talking about those though -- and in fact, there's a pretty fair chance you don't even know what they are.
There are a fair number of things many people misunderstand about C++, and many people call their misunderstanding ambiguities (or various less repeatable names) but that's a rather different sort of thing. I'm personally convinced that the concept of intuition applying to programming languages in general is pretty much nonsense as well. Programming is a learned skill, not a matter of intuition (the comment about the nipple being the only intuitive skill virtually springs to mind).
With that said, however, I tend to agree with the basic spirit I'm pretty sure you had in mind -- a programmer does have to learn quite a bit to make good use of C++. Worse, a majority of books and teachers that purport to teach C++ do so incredibly poorly, making the job substantially worse than it needs to be.
That, however, stems only in part from the language itself -- it's largely a matter of Sturgeon's law, though in this case the percentage might be closer to 99 instead of only 90. A large part of the problem is historical as well -- many books on C++ were originally written well before the language was standardized, and have not be adequately updated since, so much of what they cover really doesn't apply in a modern setting and much of the rest is often just plain wrong (often was all alon
Yeah, but how many billions is their currently-used chunk of spectrum worth on the open market?
It's generally sold at auction so the price isn't known until it's sold. Contrary to the statement elsethread, the $2B number is not an esimate of the value of this spectrum, but an (approximate) number from a previous auction. Unfortunately, the most recent projection I've found from the congressional budget office is quite old, but here is a more recent analysis from a decidedly interested (though hardly impartial) party.
Stop right there. Far from being "bug free", you've just committed one of the best-known sins of C. In C, main is required to return an int. As-is, this has undefined behavior, so nothing (at all) can be predicted about the security (or lack thereof) in the rest of your code.
The first step toward writing really good code is avoiding the most obvious textbook examples of bad code.
Of course they give some small details on what it ends up doing, but nothing about what language they used, etc., i.e. the interesting part.
At the risk of being modded offtopic, I have to disagree -- a programming language is nothing more than a way of expressing an algorithm. While there is some degree of interest in the degree to which a language allows one to express alogrithms clearly, allows for easy separation of areas of concern, etc., it's ultimately the algorithms that really matter -- the programming language is simply a way of expressing them.
OTOH, it would be interesting to hear more about the algorithms and how they were expressed -- including the programming language(s) involved, to the extent that it/they had a real effect. And make no mistake about it, programming languages do affect the algorithms used to a degree, if for no other reason than some languages make particular kinds of algorithms easier to express than others.
If you care about the algorithms involved, you might want to look into the book on probabalistic robotics by Thrun (and others). Note that this isn't specifically abou the Stanley project, but about the field of work, not simply a description of Stanley or something like that.
Monopoly is NOT about market share. If a product has a large market share it doesn't mean it is monopolizing the market. Monopolizing refers to the manner of conducting business which hurts other competitors.
A nice mixture of truth and nonsense.
Monopoly isn't purely about market share -- it's about control of the market, which the courts often tie to market share. In theory, the exact percentage of market share isn't the real point though.
Monopolizing does not (necessarily) have a thing in the world to do with hurting competitors. What Microsoft was sued for was their business practices that hurt their competitors. The monopoly itself is merely the control of the market, which wasn't/isn't illegal in and of itself. Their legal problems were due to the actions they were able to take because of their monopolistic position.
It's entirely possible to have a monopoly (even an absolute monopoly, rather than merely an effective monopoly), without engaging in any illegal practices. Just for one obvious example, the US Postal Service has a legally enforced monopoly on carrying certain kinds of letters and such, which places substantial restrictions on what FedEx, UPS, etc., can carry. Other monopolies are often similar -- for example, many utility companies have monopolies on providing things like electicity, water, etc., in specific geographic locations. Again, this doesn't necessarily imply anything about their business practices.
Not to be overly harsh on your post, since in truth there are a dozen other posts in this story which are equally wrong, but this post is just plain wrong.
Not at all -- you're absolutely right. As sometimes happens, I hit "preview" about three times to fix minor problems, and then three minutes after I hit submit, realized my brain had dredged up the wrong thing entirely, and I'd made a massive blunder...
In particular, the special number field sieve runs slower than polynomial time, so running it on a number of 10 million digits is wildly impractical.
I doubt that run-time would be the real limitation. I suspect the size of the factor bases would become prohibitive first. I suppose (in a way) you could look at this as a time problem, since you could theoretically store them largely in slower storage, but in doing so the problem would be (primarily) with access speed, not the complexity of the algorithm.
Now that's brilliant business:
Google: widely respected and quite profitable.
AOL: being bought out, and gets exactly the respect it deserves.
[closed captioning for the humor impaired: sarcasm to follow]
Obviously Google should be taking AOL's advice about how to finally achieve some real success, right?
[end sarcasm]
The trouble isn't making an arbitrary number in the hopes that it's prime, it's in proving that it's prime. There are relatively simple methods to look for Mersenne primes, they just take constant time for crunch. For non-Mersenne primes, you'd have to crunch out every possible factor to prove that it's prime, a tedious process.
This is not even close to correct. Testing primality this way becomes impractical around 30-40 digits or so (depending a bit on how patient you are) and there are methods that are faster even with substantially smaller numbers than that.
First of all, there are probabalistic methods of testing primality that don't involve factoring. While probabalistic, these can be carried to an arbitrary level of accuracy quite quickly and easily. This is a typically done as a preliminary before more difficult methods are attempted at all.
Once you're convinced that a number is almost certain to be prime, there are quite a few methods of proving it's prime that are faster than brute force -- probably the oldest and best known is based on Fermat's Little Theorem. There's also something known as Wilson't theorem that can prove the same thing, but TTBOMK, this rarely has much practical application. If you're interested in more, you can find a fairly reasonable introduction a number of the better-known factoring methods and such here. You can find more links about factoring here.
I'd remembered when the original decision was made, but (obviously enough) not when it was reversed. I remembered poorly enough that I looked for a reference, and clearly should have read through it better.
Again, my apologies. Nonetheless, I (for one) put a lot more trust in encryption than in people not reading it just because they're not supposed to...
Specifically, do we still have the idiotic and juvenile system architecture that specifies window parameters to low-level system calls? Like say, CreateProcess taking window parameters?
CreateProcess is part of the Win32 API. Think about what the "Win" in "Win32" stands for...
Do you, GOP fans, want the NSA reading your email?
I don't think it's particuarly relevant exactly who does it, and it's already been ruled that looking at email doesn't violate laws against wire-tapping. IOW, from a legal viewpoint, your email is already fair game in any case.
If you honestly care, I'd consider something like PGP or gpg.
Yeah, but NVIDIA could give PureVideo away for free with GeForce7 retail boxed GPUs.
Well, not really -- nVidia doesn't sell retail boxed GPUs; what goes into the boxes is up to the OEMs. Considering they sell it retail for $20, I'm sure the OEM price on it is pretty low -- but I'd guess the OEM's pass because 1) their customers aren't asking for it, and 2) they already have deals in place to distribute other DVD player software anyway.
IOW, the only way this is going to happen is how I said before: that nVidia just tacks the price onto every GPU they sell, and you pay for it whether you want it or not.
The bottom line that there's always a price. The question is whether the price is paid by those who want/benefit from the product, or whether it's paid by everybody whether they want it or not. "Free" translates to the latter...
I'll give ATI credit for not following in the greedy footsteps of their competitor, Nvidia. Charging for a DVD codec that's optimized for their hardware is just stupid.
There is a fundamental difference between the two though: ATI is providing this in the form of a driver that only works with ATI graphics cards. nVidia PureVideo, by contrast, is standard-based (admittedly not what you'd call an open standard, but a standard nonetheless) so it works with any video card that implements the standard.
IOW, ATIs offering is "free", but tied directly to their hardware. nVidia's offering isn't tied to any particular hardware and is paid for directly instead.
In most cases, "free" means you pay for it whether you want it or not.
I'm not sure what area you are coming from, but in what I do (astronomy, but I've seen this in other academic depts.) the number of apples have gone way up. Nearly every new laptop is an apple (with the exception of a few thinkpads or dells for the die-hard linux users).
It's not really a question of what area I'm from/in -- it's a question of what Apple's actually selling. Since you mention laptops, let's take a look at them: according to Apple's latest 10-Q report, they had 12% year-on-year growth in laptops. Dell's latest 10-Q shows approximately 40% growth in laptops.
Unfortunately, while I'm ambitious enough to find real numbers for Apple and Dell, trying to figure up Thinkpad sales across the transition from IBM to Lenevo is a bit more than I'm willing to try right now...
I thought Apple had something of a resurgence in the last couple years, but I don't see much indication of that.
It sounds like you pay a bit more attention to advertising than you really should. The reason you don't see it is that (despite Apple's ads) it's not real. Rather the contrary: the last time a Mac actually gained noticeable market share was the original iMac. Apple really topped out in the early 1990's, and has been on a long, (admittedly slow) downhill slide since then. They've managed to produce a couple of temporary upward bumps since then, but never anything very significant. Ultimately, it's just a bit of noise in a long, slow slide into oblivion.
Recently, Apple's doing a bit better financially, but that's due to sales of iPods (and associated music, accessories, etc.) not Macs.
This "change of venue" helps them considerably. On the computer front, they have a major problem: almost any change large enough to stand any chance of gaining significant market share would also very likely alienate a large portion of their existing user base. The iPod gives Apple a way out: instead of taking huge gambles in the OS, they just quietly de-emphasize the Mac, and put their real effort into iPods (which are more profitable anyway).
In fact, I'd personally guess that Apple's switch to Intel processors is driven far more by the iPod's success than by technical details like CPU clock speed or power consumption. The improvement in Macs will be an almost accidental side-effect. The fact that it lets them concentrate on iPods instead of things like bridge chips and motherboards for PowerPCs means far more. Of course, they do still make quite a bit of money on Macs, so they have to de-emphasize them slowly, carefully, and in a way that doesn't alienate their user base (after all, that's why they can't make significant improvements in the Mac either). Over time, however, the Mac will become much more like a generic PC clone, with just enough unique to Apple to prevent running OS/X on anything Apple didn't sell. Eventually, even those trivial differences may be eliminated in favor of using a "Trusted Computing Platform" to "manage your rights", so they can charge a 20% premium for what will otherwise be an utterly generic PC.
Slashdot Mirror
If you can find it, I'd advise reading "Code reuse, concrete classes, and inheritance" by Scott Meyers. Unfortunately, it's an article from the July/August 1994 issue of The C++ Report, so finding it probably won't be easy (and while Scott cites it on his site, he doesn't have a link to an online copy).
Lacking that, you might want to read this Usenet post, which at least discusses the basic problem.
What it comes down to is pretty simple though: in C++, a class should be designed to be used as a base class, OR to be instantiated, but you generally can't write a class that supports both properly.
Learning Oberon well enough to use it is one thing -- the question was whether most users really know all the rules in their entirety. Quite frankly, I can't answer that very well. Offhand, I don't think I've ever known anybody who really did, but I've known only a few people who used Oberon at all, and it's possible they were the exception to the rule.
OTOH, learning enough of C++ to use it (and even use it quite well) doesn't require memorizing the entire C++ standard or anythign like it either. I doubt that even 5% of the good C++ programmers I've known have ever even attempted to learn all the details of two-phase lookup or anything like that. Of course, it probably helps that there's only one compiler (Comeau) that implements two-phase lookup nearly correctly, so most people have little reason to care a lot about it.
I can't say I really agree. FORTRAN has about the most god-awful grammar ever invented, but doesn't seem significantly more difficult to learn than most of the other mainstream imperative languages. At the opposite end of the spectrum, you could probably fit the grammars for Brainfsck, unlambda and Intercal all onto a single page, but good luck on ever really learning any of them.
Yes, it's silly, but not for the reason you're thinking.
If WD had as good of marketing as some companies I can think of, they'd have put the windowless version on the market for a couple of months so the bleeding edge types would all buy it up. Then they would have released this, so those same people would replace their still nearly-new windowless version with this one.
A few months after that, they might start selling a new version with pre-installed internal LEDs. If they knew their fans were really loyal, they'd even start with just one color of LED, and then a year later (or so) come out with new versions in various different colors, and not only rake in the dough yet again, but get to listen to their fans proclaiming to the world what a privilege it is to get to buy from such a brilliant and innovative company.
Of course, if they were really that brilliant and innovative, they'd have to do all of this with a 40 Gb drive that was slower than anything else on the market -- if you have to engineer a decent product to sell it, your reality distortion technology is clearly inferior!
In general, I'd tend to agree. Actually, most of the better books talk about this as the law of the big three. The "big three" are the destructor, the copy constructor and the assignment operator. In nearly every case, if you need to explicitly define any one of them (typically because your class has remote data referenced through a pointer) then chances are that you need all of them. IMO, there's very little excuse for books that (often flagrantly) violate this basic rule. It's been (for one example) in the comp.lang.c++ FAQ list since something like 1991 or so. While I realize Usenet doesn't constitute the entire world, or even the entire programming world, I see little excuse for somebody claiming to teach C++ when/if they don't know at least this much.
IMO, this isn't a golden rule or even a good rule. Quite the contrary, I think code (OO or otherwise) should be designed and written for a particular purpose. If that purpose is to be derived from, good and well. If it's not, throwing in something to halfheartedly support derivation anyway is a poor idea. Going further and fully supporting derivation makes a bad situation still worse. You're still doing extra work, and probably introducing extra bugs, to make the code do something it's not really supposed to do. This is one area I agree with the people who advocate testing-oriented development -- you should define what the code really needs to do, and then write the simplest code you can that does it. Any extra capabilities, features, etc., beyond what it's really supposed to do is a bad thing.
The fact that the dtor is non-virtual IS documentation that says so. Better still, this documentation never gets out of sync with the code, because it's part of the code. The problem is that quite a few people reading the documentation don't really understand the language in which it's written (i.e. C++) very well. With that given, it's not necessarily a bad thing to add a comment or other documentation to expound on the fact, but it really should be redundant.
With a minor quibble, I agree. The minor quibble is that I'd say it's really "most" rather than "any" use of C++ being an addition to the legacy code base. Ocassionally, somebody really does start something over from a relatively clean slate rather than adding to existing code -- but I certainly agree that it's relatively unsual.
This is about half true -- it's true that classes that contain raw pointers generally need copy ctors. What's done, however, is not a bitwise copy, but a memberwise copy. The cure isn't to use copy ctors though. The cure is to not use raw pointers on a regular basis. I can hardly remember the last time I had to write a copy ctor because I used a raw pointer.
This is a problem part of the time, but not really very often. A class that doesn't have a virtual dtor generally means that class wasn't designed as a base class.
There is (occassionally) a problem with a class that was intended to be used as a base class, but due to oversight the dtor wasn't made virtual. In this regard, C++ could be improved -- rather than requiring an explicit virtual dtor, it should make the dtor virtual if the class contains any virtual function.
There are, however, quite a few classes that really have no use for any virtual functions at all -- and there's no point in making their dtors virtual, because deriving from them won't accomplish anything useful anyway.
IOW, much of the problem really arises from teachers trying to push OO as the answer to everything, and overusing derivation when it's not suitable or useful.
Of course, any answer to this is more or less a guess, since it's basically about the motivations people had for the decisions they made.
I suspect part of it is that many (most?) people who write code that works directly with hardware do so largely because they like the "feel" of working directly with the hardware -- and they simply don't like a language taking away that feel, regardless of how well it might work.
Second, OS designs tend to be nearly as conservative as possible. Consider, for example, that Microsoft's OSes prior to Windows NT (e.g. DOS, Windows 1.x, 2.x, 3.x) were still written primarily in assembly language! With Windows NT, they changed to primarily C. Direct from assembly language to modern C++ would be an awfully large jump though.
Third, OS designs tend change relatively slowly. The obvious mainstream OSes right now are Linux and Windows. Both have been around since the early '90s or so. At that time, most of what I'm talking about in C++ hadn't even been defined yet, not to mention actually being implemented. Worse, Microsoft (for one example) has only recently made a serious attempt at getting their compiler close to fully compliant with the C++ standard, so many of the best techniques simply haven't been available to them until quite recently.
On the Linux side things weren't quite as grim, but not really a whole lot better either. Worse, the educa
Not a new idea -- in fact, once upon a time, you were required to submit a working model with every patent application (in the US). The USPTO still has a museum of these working models, but storage became a problem.
This, however, favors larger companies (and such) with greater resources even more strongly than is currently the case. Assume, for example, that I have an idea for how to make CPUs twice as fast without using any more power than is currently the case. To build a single CPU using this technique I have to raise something like a million dollars just for mask work. Meanwhile Intel or IBM gets wind of the idea, and uses my invention to build a few CPUs in their own fab, so I can't get a patent on my idea -- in short, you've legalized their stealing my invention.
Let's see -- how about if we went a bit further, and required that all of every patent be made public, even if it's not in dispute. Then we could require that the patent itself require a description of what it covers, in plain English. As long as we're at it, we might as well require that it not only describe the invention itself, but how to make and use it, and require that this description be understandable to anybody who works in that area of technology.
Maybe wording something like this:
Wouldn't that be great?
Looking at 35 USC 112, maybe that idea's not very original though.
C++ templates provide capabilities that are difficult (if even possible) to match with Ada generics. Look through the Boost library at things like bind and lambda, and try to figure out how to do similar things with Ada. I wouldn't say they're impossible, but at best they're considerably more difficult.
C99 includes <stdint.h> that provides standard types for things like integers guaranteed to have exactly 32 bits and such. While I'd expect it to be renamed to <cstdint>, it would be quite surprising if C++ 0x didn't include essentially the same thing.
This depends heavily upon what you do and how you do it. Some C++ features tend to lead to code that's slower than the most obvious equivalents in C -- but in other cases, exactly the opposite is true. Just for an exceptionally obvious example of the latter, try sorting an array of integers with qsort and then do the same with std::sort.
Your premise is that it's difficult to validate, but your conclusion would only be valid if it was actully impossible to validate. From a practical viewpoint, however, the difficulty is more or less irrelevant -- the real question is whether a compiler has been validated or not, and if not the language isn't usable for that purpose, regardless of how easy or difficult the validation might be.
To my knowledge, the language contains two actual ambiguities, both of which are resolved by fiat, so to speak. One of these was inherited from C, while the other is new to C++ (though fundamentally similar to the one inherited from C).
My guess is that you aren't talking about those though -- and in fact, there's a pretty fair chance you don't even know what they are.
There are a fair number of things many people misunderstand about C++, and many people call their misunderstanding ambiguities (or various less repeatable names) but that's a rather different sort of thing. I'm personally convinced that the concept of intuition applying to programming languages in general is pretty much nonsense as well. Programming is a learned skill, not a matter of intuition (the comment about the nipple being the only intuitive skill virtually springs to mind).
With that said, however, I tend to agree with the basic spirit I'm pretty sure you had in mind -- a programmer does have to learn quite a bit to make good use of C++. Worse, a majority of books and teachers that purport to teach C++ do so incredibly poorly, making the job substantially worse than it needs to be.
That, however, stems only in part from the language itself -- it's largely a matter of Sturgeon's law, though in this case the percentage might be closer to 99 instead of only 90. A large part of the problem is historical as well -- many books on C++ were originally written well before the language was standardized, and have not be adequately updated since, so much of what they cover really doesn't apply in a modern setting and much of the rest is often just plain wrong (often was all alon
It's generally sold at auction so the price isn't known until it's sold. Contrary to the statement elsethread, the $2B number is not an esimate of the value of this spectrum, but an (approximate) number from a previous auction. Unfortunately, the most recent projection I've found from the congressional budget office is quite old, but here is a more recent analysis from a decidedly interested (though hardly impartial) party.
Stop right there. Far from being "bug free", you've just committed one of the best-known sins of C. In C, main is required to return an int. As-is, this has undefined behavior, so nothing (at all) can be predicted about the security (or lack thereof) in the rest of your code.
The first step toward writing really good code is avoiding the most obvious textbook examples of bad code.
At the risk of being modded offtopic, I have to disagree -- a programming language is nothing more than a way of expressing an algorithm. While there is some degree of interest in the degree to which a language allows one to express alogrithms clearly, allows for easy separation of areas of concern, etc., it's ultimately the algorithms that really matter -- the programming language is simply a way of expressing them.
OTOH, it would be interesting to hear more about the algorithms and how they were expressed -- including the programming language(s) involved, to the extent that it/they had a real effect. And make no mistake about it, programming languages do affect the algorithms used to a degree, if for no other reason than some languages make particular kinds of algorithms easier to express than others.
If you care about the algorithms involved, you might want to look into the book on probabalistic robotics by Thrun (and others). Note that this isn't specifically abou the Stanley project, but about the field of work, not simply a description of Stanley or something like that.
Were you thinking of something a lot different from the Xilinx Virtex 4 FX, Altera Excalibur or Atmel part (referred to elsethread)?
A nice mixture of truth and nonsense.
Monopoly isn't purely about market share -- it's about control of the market, which the courts often tie to market share. In theory, the exact percentage of market share isn't the real point though.
Monopolizing does not (necessarily) have a thing in the world to do with hurting competitors. What Microsoft was sued for was their business practices that hurt their competitors. The monopoly itself is merely the control of the market, which wasn't/isn't illegal in and of itself. Their legal problems were due to the actions they were able to take because of their monopolistic position.
It's entirely possible to have a monopoly (even an absolute monopoly, rather than merely an effective monopoly), without engaging in any illegal practices. Just for one obvious example, the US Postal Service has a legally enforced monopoly on carrying certain kinds of letters and such, which places substantial restrictions on what FedEx, UPS, etc., can carry. Other monopolies are often similar -- for example, many utility companies have monopolies on providing things like electicity, water, etc., in specific geographic locations. Again, this doesn't necessarily imply anything about their business practices.
Not at all -- you're absolutely right. As sometimes happens, I hit "preview" about three times to fix minor problems, and then three minutes after I hit submit, realized my brain had dredged up the wrong thing entirely, and I'd made a massive blunder...
I doubt that run-time would be the real limitation. I suspect the size of the factor bases would become prohibitive first. I suppose (in a way) you could look at this as a time problem, since you could theoretically store them largely in slower storage, but in doing so the problem would be (primarily) with access speed, not the complexity of the algorithm.
Oops -- yes, that would be the right one.
Google: widely respected and quite profitable.
AOL: being bought out, and gets exactly the respect it deserves.
[closed captioning for the humor impaired: sarcasm to follow]
Obviously Google should be taking AOL's advice about how to finally achieve some real success, right?
[end sarcasm]
No -- for Mersenne numbers, they usually use the special number field sieve.
This is not even close to correct. Testing primality this way becomes impractical around 30-40 digits or so (depending a bit on how patient you are) and there are methods that are faster even with substantially smaller numbers than that.
First of all, there are probabalistic methods of testing primality that don't involve factoring. While probabalistic, these can be carried to an arbitrary level of accuracy quite quickly and easily. This is a typically done as a preliminary before more difficult methods are attempted at all.
Once you're convinced that a number is almost certain to be prime, there are quite a few methods of proving it's prime that are faster than brute force -- probably the oldest and best known is based on Fermat's Little Theorem. There's also something known as Wilson't theorem that can prove the same thing, but TTBOMK, this rarely has much practical application. If you're interested in more, you can find a fairly reasonable introduction a number of the better-known factoring methods and such here. You can find more links about factoring here.
Obviously not! Thanks for the correction.
I'd remembered when the original decision was made, but (obviously enough) not when it was reversed. I remembered poorly enough that I looked for a reference, and clearly should have read through it better.
Again, my apologies. Nonetheless, I (for one) put a lot more trust in encryption than in people not reading it just because they're not supposed to...
CreateProcess is part of the Win32 API. Think about what the "Win" in "Win32" stands for...
I don't think it's particuarly relevant exactly who does it, and it's already been ruled that looking at email doesn't violate laws against wire-tapping. IOW, from a legal viewpoint, your email is already fair game in any case.
If you honestly care, I'd consider something like PGP or gpg.
Well, not really -- nVidia doesn't sell retail boxed GPUs; what goes into the boxes is up to the OEMs. Considering they sell it retail for $20, I'm sure the OEM price on it is pretty low -- but I'd guess the OEM's pass because 1) their customers aren't asking for it, and 2) they already have deals in place to distribute other DVD player software anyway.
IOW, the only way this is going to happen is how I said before: that nVidia just tacks the price onto every GPU they sell, and you pay for it whether you want it or not.
The bottom line that there's always a price. The question is whether the price is paid by those who want/benefit from the product, or whether it's paid by everybody whether they want it or not. "Free" translates to the latter...
There is a fundamental difference between the two though: ATI is providing this in the form of a driver that only works with ATI graphics cards. nVidia PureVideo, by contrast, is standard-based (admittedly not what you'd call an open standard, but a standard nonetheless) so it works with any video card that implements the standard.
IOW, ATIs offering is "free", but tied directly to their hardware. nVidia's offering isn't tied to any particular hardware and is paid for directly instead.
In most cases, "free" means you pay for it whether you want it or not.
It's not really a question of what area I'm from/in -- it's a question of what Apple's actually selling. Since you mention laptops, let's take a look at them: according to Apple's latest 10-Q report, they had 12% year-on-year growth in laptops. Dell's latest 10-Q shows approximately 40% growth in laptops.
Unfortunately, while I'm ambitious enough to find real numbers for Apple and Dell, trying to figure up Thinkpad sales across the transition from IBM to Lenevo is a bit more than I'm willing to try right now...
It sounds like you pay a bit more attention to advertising than you really should. The reason you don't see it is that (despite Apple's ads) it's not real. Rather the contrary: the last time a Mac actually gained noticeable market share was the original iMac. Apple really topped out in the early 1990's, and has been on a long, (admittedly slow) downhill slide since then. They've managed to produce a couple of temporary upward bumps since then, but never anything very significant. Ultimately, it's just a bit of noise in a long, slow slide into oblivion.
Recently, Apple's doing a bit better financially, but that's due to sales of iPods (and associated music, accessories, etc.) not Macs.
This "change of venue" helps them considerably. On the computer front, they have a major problem: almost any change large enough to stand any chance of gaining significant market share would also very likely alienate a large portion of their existing user base. The iPod gives Apple a way out: instead of taking huge gambles in the OS, they just quietly de-emphasize the Mac, and put their real effort into iPods (which are more profitable anyway).
In fact, I'd personally guess that Apple's switch to Intel processors is driven far more by the iPod's success than by technical details like CPU clock speed or power consumption. The improvement in Macs will be an almost accidental side-effect. The fact that it lets them concentrate on iPods instead of things like bridge chips and motherboards for PowerPCs means far more. Of course, they do still make quite a bit of money on Macs, so they have to de-emphasize them slowly, carefully, and in a way that doesn't alienate their user base (after all, that's why they can't make significant improvements in the Mac either). Over time, however, the Mac will become much more like a generic PC clone, with just enough unique to Apple to prevent running OS/X on anything Apple didn't sell. Eventually, even those trivial differences may be eliminated in favor of using a "Trusted Computing Platform" to "manage your rights", so they can charge a 20% premium for what will otherwise be an utterly generic PC.