It's truly comical to see how completely music company executives ignore reality. Watch MTV for an hour or two, and it quickly becomes apparent that music simply doesn't matter much to its primary target demographic. Based on how little air time it now gets, sales should be down much further than they are. Somehow the executives blithely ignore this, however, and blame their troubles entirely on file sharing, p2p, and so on.
They need to concentrate on finding some real talent. Right now they seem to concentrate primarily on finding second-rate wannabe-models, and then try to cover their complete lack of talent with lousy recording, lots of digital processing and when that doesn't work, attempt to distract from the mediocrity with synchronized dancing.
Once they've found some talent, they need to do a good (not over-produced) job of recording them, and sell the recording at a reasonably fair price. Here again, they've fallen down badly -- at one time, the amount of work and machinery raised enough barrier to entry that prices are recordings were at least partially justified. That's just no longer the case. Photocopiers haven't hurt the book market noticeably, simply because most people prefer a nicely printed and bound book to a photocopy, and a photocopy generally doesn't save much (if any) money anyway. The recording labels don't want to compete similarly because it would cut their profit margins -- but it's the only route that has any chance of being truly viable in the long term.
The fact is, if you want to sell something, you have to start by providing something that people actually want. Then you have to set a price that people will accept. These are simple facts the record companies have to face. Until they do, neither DRM nor lawsuits will improve their situation -- or even noticeably slow the rate at which it deteriorates.
The fact that there weren't any Apple ][ clones was due more to the big diversity in personal computer models at the time than any trade secret.
Please see the site exclusively devoted to Apple II clones. Virtually all of these (a couple hundred or so) were put out of business by Apple suing them.
Don't get me wrong: I think in most of these cases, Apple had a perfect right to sue. Many of these didn't even make an attempt at being legal or legitimate at all, just using outright copies of the Apple II ROMs and selling them. AFAIK, the only company that did legal Apple II clones was VTech, who did the (in retrospect) obvious thing: they went to Microsoft and took out a license to AppleSoft, just like Apple had in the first place. Other than that, most were just taking an Apple II, copying its ROM and putting it into a machine similar to a real Apple II. Apple successfully took nearly all of these (e.g. the Pineapple, most of the Franklins) off the market via lawsuits.
Apple also sued nearly everybody over supposedly copying their GUI -- in nearly every case, it was pretty obvious that the real source was Xerox, but Apple's motto seemed to be "it's our's; we stole it first." This forced changes (mostly minor) in GEM, and (IIRC) Tandy's GUI system (sorry, I don't remember its name).
You don't know anything about the HPs. Overly complicated, sure, but I wouldn't call a 4MHz processor overspecced and I certainly wouldn't ever call the 48GX unreliable since many have chimed in with their stories of their 12 year old HPs still working.
I'm not sure about the models from only 12 years ago, but the HP-41C I bought around 1982 or so still works perfectly. Truth be told, it works better than new, thanks to it's accepting add-on modules (of which all four slots are permanently full). The newer HPs don't seem to be quite as solidly build as that, but they're still quite a bit better than the TIs and Sharps.
The comments about RPN being difficult really are nonsense. If you can't figure out RPN, my advice is to forget even politics and just live under a bridge -- though you'll probably have to fight for a spot, since the other homeless people will neither respect nor wish to associate with you.
On this legal copy of Vista I can play 1920x1080 content just fine. Because I simply don't touch DRMed content. Your paranoia borderlines stupidity (or you know nothing about programming) if you think a "bug" will cause normal video-operations to randomly generate calls to the DRM-subsystem.
It's hardly paranoia. Assuming you know programming well enough to read a tiny bit of trivial code, consider something like this:
switch (video.format) { case MPEG: switch(video.format.subformat) { case ABC: play_full_resolution(video); break; case XYZ: play_reduced_resolution(video); break; } }
The only question at this point is what are the odds that 'pointer' happened to contain the address of 'video.format' when it was dereferenced. Looking at it from the other direction, it's basically inevitable that once in a while, a video that started out as 'ABC' or 'DEF' will be changed so the system thinks it's an 'XYZ' instead.
If you think no Microsoft code has ever written through an uninitialized pointer, you're mistaken as well. When you leave out all the other code like I've done above, it's pretty obvious -- but with a few pages of other code between pointer being defined and being dereferenced (e.g. code that attempts to exchange an HDCP key and normally initializes the pointer) it can be considerably more difficult to track down the fact that for one specific set of circumstances that only rarely occurs (and may not have occurred in their testing at all) that pointer simply isn't initialized.
Of course, that's far from the only possibility. It can be something like 'pointer' never being initialized, but due to previous code it usually contains a location that changes exactly one pixel in the first frame of your video to a '2'. This affects one pixel in one frame, but the change is so tiny you usually miss it entirely -- but one particular format uses a large enough header that it overwrites a byte in the header instead of the payload.
Yes. The Vista DRM do indeed suck. Yes. It would be a better OS without it. No. It will not in any way affect any media you consume, as long as it's not DRMed.
You'd think the "smart people" of slashdot which "are much more enlightened than Joe Average" would be capable of grasping this simple concept.
I'd have thought the concept of a "bug" was pretty well known and easily understood, but apparently there's at least one reader here who hasn't quite grasped it yet...
Even if we accept Microsoft's word that Vista really is designed to affect only commercial content, how reassuring is that? Given the number of bugs in Microsoft's software, the only way we should honestly feel at all reassured is if the capability simply isn't present. Even if Microsoft does their absolute best to ensure the munging happens only when it should, experience indicates that their best simply isn't good enough.
For those who care, Bruce Schneier gave some real facts about the attack on his site a couple of years ago. As he pointed out:
For the average Internet user, this news is not a cause for panic. No one is going to be breaking digital signatures or reading encrypted messages anytime soon. The electronic world is no less secure after these announcements than it was before.
A short note about the attack has been available for a couple of years as well. The note shows collisions for two different reduced versions of SHA-1.
Though it's not absolutely certain, my guess is that the reality behind the new announcement is that they've actually found a collision for the full version of SHA-1, and possibly for MD-5 as well. OTOH, maybe the mention of MD-5 is just a journalist's hashed (no pun intended) version of the fact that SHA-1 is based closely enough on MD-5 that an algorithm that's successful against SHA-1 will probably be effective with respect to MD-5 as well.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
I'm not sure what you meant by that, but many Common Lisp implementations compile and run equivalent in speed to C/C++.
Somehow, I doubt you've really read that paper very carefully. At least IMO, you're seriously mis-characterizing what it really contains. First of all, it contains no comparison to C++ at all, only to C. Second, while they use a number of Lisp compilers, they use only one C compiler -- and one that doesn't optimize terribly well either. Finally, the test code they used was, quite frankly, so trivial, that nearly any compiler for any language ever invented should be able to produce results almost indistinguishable from hand-written assembly language (in fact, if anything is surprising about the LISP code, it's the extra work required to make it competitive -- in fact, their optimized Lisp code is longer, and IMO more difficult to read, than hand-written assembly for these tasks).
I agree that Lisp's reputation for poor performance is largely undeserved. Nonetheless, this paper falls well short of showing that it's equivalent to C except, at best, in extremely limited circumstances. C, in turn, falls well short of the performance of C++. Libraries like Blitz++ allow C++ to offer substantially better performance than C. Likewise, other compilers generally offer substantially better performance from either C or C++ code. As a result, even though Lisp does far better than most people expect, C++ with a good compiler still wins by a fairly wide margin.
OTOH, I feel obliged to reiterate: the reputation for poor performance is largely undeserved. If you start with a good design, a decent implementation in Lisp will usually give perfectly acceptable performance. Compared to a program in C, it might (or might not) suffer a slight penalty in raw speed of low-level operations. OTOH, given the difference in mind-set between typical C programmers and typical Lisp programmers the overall speed of the Lisp version will often be better, because they'll do more optimization at a higher level (e.g. caching frequently-used results instead of re-computing them). Very few programs really depend primarily upon the raw speed of a few simple operations such as those examined in this paper -- architecture and design are what make the big differences.
I would like to see DVDs, en masse, released in a dual layer setup, where layer 1 is standard DVD (for backward compatibility), and layer 2 is the HD-DVD version.
It'd be more than dual layer -- a typical DVD is already dual layer. There are both single and dual layer versions of HD-DVD, but it memory serves, the "second layer" is accessed by flipping the disc rather than changing laser focus.
OTOH, that's mostly details -- from a technical viewpoint, been demonstrated and could be produced -- and at some point, probably will be. The real reason it's not being done is almost certainly financial. To sell, this combined format would need to be competitive with normal DVDs, but the disc is undoubtedly more expensive to manufacture. They want the opposite: instead of selling you a single disc at a reduced profit margin, they'd rather sell you a DVD and then later sell you an HD-DVD of the same content -- both with inflated profit margins.
Given that it's technically feasible, chances are it'll happen eventually -- but I'd bet it happens only when the market for SD DVDs starts to shrink to the point that it no longer justifies producing them separately anymore.
...promote the concept of the title "Software Engineer" requiring a professional certification, the way real engineering does.
For this to do any good, you'd need reasonable criteria upon which to base the certification. IMO, TFA was mostly correct in pointing out that right now, we don't know what those criteria should be. The Mythical Man-Month remains relevant today largely because relatively little progress has been made in solving the problems it explored. As Brooks pointed out in No Silver Bullet, we've cured a lot of the accidental problems of software engineering, but done relatively little about the essential problems.
In terms of the certification itself, we're just about as lost. The correlation between formal schooling and success as a software engineer is weak at best, and quite possibly negative. Experience indicates more, but still very little. Certification based on such criteria would do more harm than good.
There are other problems as well. With buildings, it's pretty easy for most people to realize that "skyscraper" and "dog house" have different requirements as to the level of expertise involved in their design. In software those differences often aren't nearly so obvious. The managerial people who'd need to enforce the requirement for certification don't know the difference between a skyscraper and a scale model of one for a train set (and sometimes the developers don't either). "Web developers" (in particular) seem prone to jumping (metaphorically) from doll houses to 18-lane suspension bridges in high-wind, earthquake-prone areas.
...C++'s STL may introduce new problems, but it sure as hell fixes a metric ton of them in the process.
Other than the minor detail of using the term "STL", I agree completely. Actually, I'm a bit surprised that nobody mentioned the problem that I think is most annoying: the fact that a truly trivial error can result in an error message that's three pages long and nearly impossible to decipher. Leor Zolman's stlfilt can help, but it's hardly a panacea. (And yes, if there are any other old farts like me reading, this is the same Leor Zolman who wrote BDS C, back before the continents separated and such...)
In case anybody cares: I object to "STL" on the grounds that it's extremely ambiguous -- some people use it to refer to the entire STandard Library, others to refer to a library written years ago by Alex Stepanov, still others to a library currently maintained by SGI based on Alex Stepanov's library, and still others to those portions of the current C++ standard library closely based on Alex Stepanov's library (usually with a rather poorly defined boundary). Still others seem to use the term to refer to all code that uses templates. While ambiguity in English is hardly new or unique, this situation seems worse than usual to me -- enough to warrant avoiding the term altogether.
...a design-by-contract subset of Ada95 that is entirely designed-from-scratch for verification purposes.
To be true, it would appear that SPARK would have to have been designed sometime before Ada83, and then the other parts of Ada added on afterwards. I don't believe that's the case.
fgets(buf, BUFSZ, stdin);/* the SECURE way to do it, don't even think of using gets() or scanf()! */
You can use scanf perfectly well:
scanf("%1023s", buf);
Though, of course, actually doing so is fairly unusual. Of course, it's also possible to find buggy implementations of scanf that have (for example) fixed-size internal buffers...
strip_newline(buf, BUFSZ);/* some function to remove trailing newline */
One thing many people fail to note is exactly why fgets doesn't already do this. The trailing newline (or lack thereof) tells you whether you've really read the entire line, or there's more data waiting to be consumed. If you really want to do this, the library provides a function for the job -- albeit, it's a rather unusual use for this particular function:
strtok(buf, "\n");
does a perfectly fine job of stripping a trailing new-line.
Why would you HAVE to use C or C+ or C*+**+++? I don't mean to be a troll, but if you are writing in an inherently insecure language (i.e., any compiled language) you aren't going to get secure code.
OTOH of you write in, say, assembly, you are setting yourself up for the complexity. You have to make sure your buffers won't overflow, as opposed to leaving it to the compiler writers.
I'm not sure what makes you think "any compiled language" is inherently insecure, but I'm pretty sure anything that would support such a claim would apply equally well to assembly language. An assembler is enough like a compiler that almost any characteristic inherent to one is virtually certain to be inherent to the other.
My 1992 car is full of hundreds of thousands little bitty moving parts and fluids, but as long as I keep clean oil and filters in it, it doesn't break. My last car was an 1988, it lasted until last year. But I have to replace my 2002 Microsoft operating system because it's not secure?
An utterly nonsensical comparison. The 2002 code does exactly what it did back then, just as well as it did back then. It won't ever wear out in the way your car did.
If you insist on comparing a a computer to a vehicle, compare it to something like a tank or a jet fighter. It's a target in a hostile environment (i.e. a network), surrounded by enemies ready to exploit any weakness they can find.
Somebody is making a lot of money off of poorly designed and poorly built software. There is no reason why I should have rto replace an OS.
I suppose you also think the designers of WW I biplanes were lazy because they produced something that couldn't compete with an F15?
There are reasons for program errors, but no excuses. If your code is shit, it's shit because you wrote shit. Either you're incompetent or lazy. "You can have cheap, secure, or fast. Pick two."
Even the greatest chess masters lose occasionally -- and compared to programming, chess has simple rules, a well-defined goal, a stable environment, etc.
And automobiles can introduce problems (air pollution) that didn't previously exist with the form of transportation they replaced.
I suggest you take a look at the smoke from a forest fire started by a spark from a steam locomotive. Then take a whiff of a town where every street is a foot deep in horse manure. Then come back and try to convince us that cars cause more pollution than their predecessors.
Lack of pollution in the past is almost entirely a fantasy. Especially during the early industrial revolution, many cities (especially industrial centers) had air pollution so bad that they typically ran their street lights 24 hours a day.
It's no surprise when the/. editors due a poor job of summarizing a story, but in this case, they did a semi-reasonable job of summarizing the story they read. The problem is that the story they read is itself a summary, and a lousy one at that -- much worse, in fact, than/.'s usual.
The fact of the matter is that the GAO report did NOT draw the claimed conclusions at all. What the GAO report says is:
Through both their reports and our interviews with them, consumer advocates and some pharmaceutical industry analysts expressed concerns that certain intellectual property protections do not encourage innovations.
They then, however, go on to note that others disagree with this viewpoint. At least to me, it appears very much as if the "American Constitutional Society" (i.e. the blog referred to in the/. summary) is mostly reading its own viewpoint into the GAO report. If you read the report itself you'll find that it expresses no such position at all, and in its actual "concluding remarks", its only mention of patents is: "The extent to which scientific, business, regulatory and intellectual property issues related to drug development can be addressed will largely determine if and how quickly these trends can be reversed."
The fact is that the report itself takes basically no stance on patents in either direction, basically stating the near tautology that if issues with patents affect innovation, then addressing those issues will affect innovation as well.
To give my summary: don't trust the summaries. Read the paper itself, and draw your own conclusions -- at least IMO, the ACS blog entry simply isn't very accurate.
So include-ing iostream is always sufficent to get std::endl.
No, it's not. This problem has been fairly carefully studied, and well known in the C++ community for a long time. Nobody seems very interested in fixing it, mostly because nobody is aware of a compiler that actually breaks any code this way, and it also looks like the author would have to go to a fair amount of extra work to do it, so it probably won't ever happen either.
Firstly templates. They are just void pointers with type safety.
This is thoroughly wrong it's hard to keep my reply polite. You'd be roughly correct about the generic support in Java, but about C++ templates, your statement is completely, totally and thoroughly wrong. I can't do anything approaching justice to the subject here, but I'd recommend reading Modern C++ Design by Andrei Alexrandescu, to at least start getting a clue about how much more there really is to templates. You might also want to look at the source code to The boost library for more along the same general line (e.g. take a look at boost Lambda, which is quite different from anything you can do with void pointers.
The thing is, in practice the overhead of the type checking is superfluous as very few bugs are down to bad casts in functionally similar C code.
Sorry, but no. The type-checking is done at compile time, so it doesn't impose any overhead (at runtime -- in theory it makes for slightly longer compile times, but in practice the difference is rarely noticeable.
And while I'm considering performance, despite another poster claiming it's a linker issue, vtable lookups do impact performance regardless of whether you blame the linker or the compiler. The language requiring something like vtable support is the real culprit, excacerbated by the debatable way that C++ handles method resolution. In Java, if I call List.get() on an object that is actually an ArrayList, I get the ArrayList version of the method - the most derived one - not the List implementation. In C++, I get the List implementation (this ignores the fact that List is an interface in Java, but you should get the gist of what I'm saying). In practice, the C++ way of doing this is counter intuitive, despite the fact that the C++ way seems more logical from a syntax point of view.
The performance of a virtual function in C++ (at least with most recent compilers I've tested) is essentially the same as the switch statement or pointer to a function you'd have to use to get the same functionality in C. The problem arises primarily from the fact that people often use virtual functions where they're not really suitable.
The differences between C++ and Java tend to get sufficiently religious quickly enough that I'll stay away from discussing that, at least for now.
As for the inlining of sorting code, in a test I just ran the sorting function was inlined in a C example just like the use of std::sort() you described.
I specifically talked about using qsort. Obviously, you're not doing that. It's nearly always true that more specialized code can be more efficient than more generalized code. The trick is to write generalized code that retains close to the efficiency of the more specialized code -- and C++ does a better job of that than C does.
The difference is that my sort resulted in far less assembler instructions than the C++ std::sort() one, although I did have to spend an extra couple of minutes copying the sort code from a Sedgewick book.
Counting assembly instructions gave a useful of speed in the days of 68Ks and 8088s. Those days are long gone. Given that it came from a Sedgewick book, your code may easily be substantially slower ( I'm not a fan of Sedgewick).
Finally, the iostream library. I spent part of this afternoon refactoring a loop that was proving to be a bottleneck in some C++ code. It relied on ostringstream to turn an unsigned integer into a string, and then passed the std::string representation to be add
Well, while I am happy to see that you're sophisticated enough to quote the standard, I'm dissapointed that you immediately lapsed into going back to "the compiler is right"-- for example, my original program compiles just fine (for example, with "g++ -ansi -Wall -pedantic", although that is indeed not a way of guaranteeing standards-compliance).
I didn't "lapse into" anything. I pointed out two separate points: one, that the code isn't technically conforming, the other that for most practical purposes it probably won't ever matter. Which viewpoint you choose to care about is entirely your own decision. Personally, I prefer to stick as close to the theoretical ideal as reasonable, but I don't let that stop me from writing code that's portable in the real world when I need to.
In any case, I do not have the luxury of owning an expensive copy of the actual standard
So get yourself an inexpensive copy. The last time I checked, you could get an electronic copy from webstore.ansi.org for something like $20 US (or so -- it was originally $18, but I seem to recall that it's gone up a little bit).
but please refer to section 16.1.2 of "The C++ Programming Language", special edition (ISBN: 0-201-88954-4), and you will see that "A standard header with a name starting with the letter c is equivalent to a header in the C standard library'-- which, of course, obviates the inclusion of functions in the global namespace.
Sorry, but that's just plain wrong. According to the standard, section D.5:
1 For compatibility with the Standard C library, the C + + Standard library provides the 18 C headers, as shown in Table 100:
2 Every C header, each of which has a name of the form name.h, behaves as if each name placed in the Standard library namespace by the corresponding cname header is also placed within the namespace scope of the namespace std and is followed by an explicit using-declaration (7.3.3).
3 [Example: The header <cstdlib> provides its declarations and definitions within the namespace std. The header <stdlib.h> makes these available also in the global namespace, much as in the C Standard. --end example]
That seems pretty clear to me: by including <cstdio> you've gotten a declaration of printf in the std namespace. You could explicitly qualify the name printf (std::printf) or you could use an explicit using directive or declaration to make the name visible, or you could include stdio.h to do the same implicitly, but as it stands, your code simply isn't right, and won't work with a properly functioning compiler.
In face of this, I believe that Stroustrup's description of what should happen and g++'s actual implementation of what happens is correct.
I've been trying for years, and I've still yet to come up with a more polite way of saying: "Your logic is flawed and your conclusion erroneous." I wish I could though...
It certainly works, and by your own logic that's appearantly acceptable.
Not really. I (along with most real programmers) have to combine two viewpoints to varying degrees. One is writing code that's theoretically correct, and the applicable standard(s) gurantee will work. the other is making my code actually work in the targets I care about. From the theoretical viewpoint, I can write C++ code using export, and it's all fine and good. From a practical viewpoint, that only really works with
The first part is understanding how to solve the problem. This has nothing to do with the programming language you're using.
I have to disagree, at least to some extent. It is true that most of the mainstream languages are enough alike that they have little influence on choices in the solution. OTOH, that isn't always the case. Sufficient differences in languages (e.g. Fortran vs. Lisp) can have substantial differences on the solutions that are reasonable.
While part 2 is different for every programming language, part 1 is always the same.
It seems to me that you've stated this too absolutely. I would say part 1 tends to vary less, while part 2 tends to vary more. OTOH, until you look at an extremely detailed level (e.g. the way you spell some specific key words and such) you can have solutions that are essentially identical between some languages and others. At the same time, designing the solution can vary somewhat based on your target language as well. Even at the most basic level, my method for solving a problem is often quite a bit different if I'm working in SQL than if I'm working in C (just for one extreme contrast). This, in turn, can be influenced by the form of the data itself -- if the data is already in a SQL database, SQL is usually the easiest way to get at the data. If it's in some flat text files, C may be easier -- and so on, of course...
When you need high performance, C++ is better choice than any other language.
Bullshit, C is.
I have to disagree. Essentially any C code can also be written as C++ with essentially no modifications, short of possibly minor changes in spelling (e.g. if the C code happened to use 'class' as a variable name). The reverse is not true, however -- it's entirely possible to write things in C++ (e.g. using templates) that really have no direct counterpart in C.
Some of those give considerable opportunity for optimization that's (at best) considerably more difficult in C. An obvious example would be sorting. The C library includes qsort, which allows various forms of comparison by using a pointer to a function. The C++ library includes std::sort, which is a template that accepts a name of a comparison function/functor as a parameter. This may initially seem like a trivial distinction (name vs. pointer) but, in fact, makes a huge difference -- in particular, it frequently allows the compiler to generate the comparison code in-line instead of calling a function via a pointer to do each comparison. Since the comparison itself is often quite trivial, the call via a pointer often adds a great deal of overhead -- to the point that in my experience, std::sort is typically at least twice the speed of qsort (I'll attach a bit of benchmark code to the end of the message for those who care to test with their compiler).
While it has taken a fair amount of work, libraries like blitz++ include many more optimizations like this. While the code to implement them isn't always the most readable, the library is relatively easy to use, and the code that uses it is quite readable.
Consider the "one size fits all" and implicit copying of the STL
I'm not sure exactly what you mean by 'one size fits all', so it's hard to reply to that. Its' true that the containers in the standard library are written with the assumption that copying is relatively cheap. Fortunately, you can essentially always provide for that, since you can use a smart pointer with cheap copying and value semantics on the (IME relatively rare) occasion that copying the object itself causes a performance problem. Given that C simply lacks any counterpart of the C++ standard containers, it's difficult to compare C to C++ in this respect, but my own experience indicates that more often than not, C code that had hand-rolled containers gets faster when converted to C++ standard containers.
[...] or the brainfuck that is the iostream library once you actually want to format something.
This is a matter of verbosity of the code, not performance. Unfortunately, although you didn't point it out, most implementations of the iostream library really do have performance problems. Fortunately, that is strictly the library, not anything inherent to the language though. The problem arises primarily from the fact that the iostreams library has a couple of virtual function calls in the critical path. The flexibility this adds is considerable, but few programmers are aware of it, or attempt to take advantage of it, and this is one of those rare cases where you really do pay a price even when you don't use the feature.
In fairness, however, I should point out that this is an area that almost certainly could be improved considerably. Technical report 1 on the C++ language, a number of techniques that would almost certainly improve performance in this area, though I'm not aware of a full library that actually implements those techniques.
Getting back to your original comment about formatting, it's entirely possible to create a formatting class that allows you to set up a complex format, and then when you want to use that format, you simply apply the format as a whole to the stream instead of setting flags individually. While I've never attempted to write a parser
Here is a perfectly acceptable C++ "Hello, World":
#include <cstdio> int main() { printf("Hello, World\n"); }
Not really. When you #include <cstdio> you get a declaration of printf in the std namespace, so you'd need to use std::printf("..."); Alternatively, you can include <stdio.h> and get printf in the global namespace, and the remainder of your code is correct.
The standard C headers are included in Appendix D of the C++ standard, and while using them is officially deprecated, I consider it highly unlikely that they'll really be removed anytime soon at all. Even when/if they should be removed from the standard proper, I'd guess that essentially every real C++ compiler will continue to include them anyway (if only because essentially every C++ compiler is also a C compiler).
Still technically wrong. is required to declare std::cout, but it's not actually required to declare std::endl. OTOH, I believe your code should work with every real C++ compiler, even though in theory a conforming implementation of C++ could be written that wouldn't accept it.
Slashdot Mirror
It's truly comical to see how completely music company executives ignore reality. Watch MTV for an hour or two, and it quickly becomes apparent that music simply doesn't matter much to its primary target demographic. Based on how little air time it now gets, sales should be down much further than they are. Somehow the executives blithely ignore this, however, and blame their troubles entirely on file sharing, p2p, and so on.
They need to concentrate on finding some real talent. Right now they seem to concentrate primarily on finding second-rate wannabe-models, and then try to cover their complete lack of talent with lousy recording, lots of digital processing and when that doesn't work, attempt to distract from the mediocrity with synchronized dancing.
Once they've found some talent, they need to do a good (not over-produced) job of recording them, and sell the recording at a reasonably fair price. Here again, they've fallen down badly -- at one time, the amount of work and machinery raised enough barrier to entry that prices are recordings were at least partially justified. That's just no longer the case. Photocopiers haven't hurt the book market noticeably, simply because most people prefer a nicely printed and bound book to a photocopy, and a photocopy generally doesn't save much (if any) money anyway. The recording labels don't want to compete similarly because it would cut their profit margins -- but it's the only route that has any chance of being truly viable in the long term.
The fact is, if you want to sell something, you have to start by providing something that people actually want. Then you have to set a price that people will accept. These are simple facts the record companies have to face. Until they do, neither DRM nor lawsuits will improve their situation -- or even noticeably slow the rate at which it deteriorates.
Insightful and funny -- not to mention insightful and funny.
This message brought to you by the department of redundancy department's department of redundancy.
Please see the site exclusively devoted to Apple II clones. Virtually all of these (a couple hundred or so) were put out of business by Apple suing them.
Don't get me wrong: I think in most of these cases, Apple had a perfect right to sue. Many of these didn't even make an attempt at being legal or legitimate at all, just using outright copies of the Apple II ROMs and selling them. AFAIK, the only company that did legal Apple II clones was VTech, who did the (in retrospect) obvious thing: they went to Microsoft and took out a license to AppleSoft, just like Apple had in the first place. Other than that, most were just taking an Apple II, copying its ROM and putting it into a machine similar to a real Apple II. Apple successfully took nearly all of these (e.g. the Pineapple, most of the Franklins) off the market via lawsuits.
Apple also sued nearly everybody over supposedly copying their GUI -- in nearly every case, it was pretty obvious that the real source was Xerox, but Apple's motto seemed to be "it's our's; we stole it first." This forced changes (mostly minor) in GEM, and (IIRC) Tandy's GUI system (sorry, I don't remember its name).
I'm not sure about the models from only 12 years ago, but the HP-41C I bought around 1982 or so still works perfectly. Truth be told, it works better than new, thanks to it's accepting add-on modules (of which all four slots are permanently full). The newer HPs don't seem to be quite as solidly build as that, but they're still quite a bit better than the TIs and Sharps.
The comments about RPN being difficult really are nonsense. If you can't figure out RPN, my advice is to forget even politics and just live under a bridge -- though you'll probably have to fight for a spot, since the other homeless people will neither respect nor wish to associate with you.
It's hardly paranoia. Assuming you know programming well enough to read a tiny bit of trivial code, consider something like this:
The only question at this point is what are the odds that 'pointer' happened to contain the address of 'video.format' when it was dereferenced. Looking at it from the other direction, it's basically inevitable that once in a while, a video that started out as 'ABC' or 'DEF' will be changed so the system thinks it's an 'XYZ' instead.
If you think no Microsoft code has ever written through an uninitialized pointer, you're mistaken as well. When you leave out all the other code like I've done above, it's pretty obvious -- but with a few pages of other code between pointer being defined and being dereferenced (e.g. code that attempts to exchange an HDCP key and normally initializes the pointer) it can be considerably more difficult to track down the fact that for one specific set of circumstances that only rarely occurs (and may not have occurred in their testing at all) that pointer simply isn't initialized.
Of course, that's far from the only possibility. It can be something like 'pointer' never being initialized, but due to previous code it usually contains a location that changes exactly one pixel in the first frame of your video to a '2'. This affects one pixel in one frame, but the change is so tiny you usually miss it entirely -- but one particular format uses a large enough header that it overwrites a byte in the header instead of the payload.
I'd have thought the concept of a "bug" was pretty well known and easily understood, but apparently there's at least one reader here who hasn't quite grasped it yet...
Even if we accept Microsoft's word that Vista really is designed to affect only commercial content, how reassuring is that? Given the number of bugs in Microsoft's software, the only way we should honestly feel at all reassured is if the capability simply isn't present. Even if Microsoft does their absolute best to ensure the munging happens only when it should, experience indicates that their best simply isn't good enough.
A short note about the attack has been available for a couple of years as well. The note shows collisions for two different reduced versions of SHA-1.
Though it's not absolutely certain, my guess is that the reality behind the new announcement is that they've actually found a collision for the full version of SHA-1, and possibly for MD-5 as well. OTOH, maybe the mention of MD-5 is just a journalist's hashed (no pun intended) version of the fact that SHA-1 is based closely enough on MD-5 that an algorithm that's successful against SHA-1 will probably be effective with respect to MD-5 as well.
Somehow, I doubt you've really read that paper very carefully. At least IMO, you're seriously mis-characterizing what it really contains. First of all, it contains no comparison to C++ at all, only to C. Second, while they use a number of Lisp compilers, they use only one C compiler -- and one that doesn't optimize terribly well either. Finally, the test code they used was, quite frankly, so trivial, that nearly any compiler for any language ever invented should be able to produce results almost indistinguishable from hand-written assembly language (in fact, if anything is surprising about the LISP code, it's the extra work required to make it competitive -- in fact, their optimized Lisp code is longer, and IMO more difficult to read, than hand-written assembly for these tasks).
I agree that Lisp's reputation for poor performance is largely undeserved. Nonetheless, this paper falls well short of showing that it's equivalent to C except, at best, in extremely limited circumstances. C, in turn, falls well short of the performance of C++. Libraries like Blitz++ allow C++ to offer substantially better performance than C. Likewise, other compilers generally offer substantially better performance from either C or C++ code. As a result, even though Lisp does far better than most people expect, C++ with a good compiler still wins by a fairly wide margin.
OTOH, I feel obliged to reiterate: the reputation for poor performance is largely undeserved. If you start with a good design, a decent implementation in Lisp will usually give perfectly acceptable performance. Compared to a program in C, it might (or might not) suffer a slight penalty in raw speed of low-level operations. OTOH, given the difference in mind-set between typical C programmers and typical Lisp programmers the overall speed of the Lisp version will often be better, because they'll do more optimization at a higher level (e.g. caching frequently-used results instead of re-computing them). Very few programs really depend primarily upon the raw speed of a few simple operations such as those examined in this paper -- architecture and design are what make the big differences.
It'd be more than dual layer -- a typical DVD is already dual layer. There are both single and dual layer versions of HD-DVD, but it memory serves, the "second layer" is accessed by flipping the disc rather than changing laser focus.
OTOH, that's mostly details -- from a technical viewpoint, been demonstrated and could be produced -- and at some point, probably will be. The real reason it's not being done is almost certainly financial. To sell, this combined format would need to be competitive with normal DVDs, but the disc is undoubtedly more expensive to manufacture. They want the opposite: instead of selling you a single disc at a reduced profit margin, they'd rather sell you a DVD and then later sell you an HD-DVD of the same content -- both with inflated profit margins.
Given that it's technically feasible, chances are it'll happen eventually -- but I'd bet it happens only when the market for SD DVDs starts to shrink to the point that it no longer justifies producing them separately anymore.
For this to do any good, you'd need reasonable criteria upon which to base the certification. IMO, TFA was mostly correct in pointing out that right now, we don't know what those criteria should be. The Mythical Man-Month remains relevant today largely because relatively little progress has been made in solving the problems it explored. As Brooks pointed out in No Silver Bullet, we've cured a lot of the accidental problems of software engineering, but done relatively little about the essential problems.
In terms of the certification itself, we're just about as lost. The correlation between formal schooling and success as a software engineer is weak at best, and quite possibly negative. Experience indicates more, but still very little. Certification based on such criteria would do more harm than good.
There are other problems as well. With buildings, it's pretty easy for most people to realize that "skyscraper" and "dog house" have different requirements as to the level of expertise involved in their design. In software those differences often aren't nearly so obvious. The managerial people who'd need to enforce the requirement for certification don't know the difference between a skyscraper and a scale model of one for a train set (and sometimes the developers don't either). "Web developers" (in particular) seem prone to jumping (metaphorically) from doll houses to 18-lane suspension bridges in high-wind, earthquake-prone areas.
Other than the minor detail of using the term "STL", I agree completely. Actually, I'm a bit surprised that nobody mentioned the problem that I think is most annoying: the fact that a truly trivial error can result in an error message that's three pages long and nearly impossible to decipher. Leor Zolman's stlfilt can help, but it's hardly a panacea. (And yes, if there are any other old farts like me reading, this is the same Leor Zolman who wrote BDS C, back before the continents separated and such...)
In case anybody cares: I object to "STL" on the grounds that it's extremely ambiguous -- some people use it to refer to the entire STandard Library, others to refer to a library written years ago by Alex Stepanov, still others to a library currently maintained by SGI based on Alex Stepanov's library, and still others to those portions of the current C++ standard library closely based on Alex Stepanov's library (usually with a rather poorly defined boundary). Still others seem to use the term to refer to all code that uses templates. While ambiguity in English is hardly new or unique, this situation seems worse than usual to me -- enough to warrant avoiding the term altogether.
To be true, it would appear that SPARK would have to have been designed sometime before Ada83, and then the other parts of Ada added on afterwards. I don't believe that's the case.
You can use scanf perfectly well:
scanf("%1023s", buf);
Though, of course, actually doing so is fairly unusual. Of course, it's also possible to find buggy implementations of scanf that have (for example) fixed-size internal buffers...
One thing many people fail to note is exactly why fgets doesn't already do this. The trailing newline (or lack thereof) tells you whether you've really read the entire line, or there's more data waiting to be consumed. If you really want to do this, the library provides a function for the job -- albeit, it's a rather unusual use for this particular function:
strtok(buf, "\n");
does a perfectly fine job of stripping a trailing new-line.
I know I've been away from comp.std.c++ for a while, but I still thought I would have noticed if they were removing references from the language!
I'm not sure what makes you think "any compiled language" is inherently insecure, but I'm pretty sure anything that would support such a claim would apply equally well to assembly language. An assembler is enough like a compiler that almost any characteristic inherent to one is virtually certain to be inherent to the other.
An utterly nonsensical comparison. The 2002 code does exactly what it did back then, just as well as it did back then. It won't ever wear out in the way your car did.
If you insist on comparing a a computer to a vehicle, compare it to something like a tank or a jet fighter. It's a target in a hostile environment (i.e. a network), surrounded by enemies ready to exploit any weakness they can find.
I suppose you also think the designers of WW I biplanes were lazy because they produced something that couldn't compete with an F15?
Even the greatest chess masters lose occasionally -- and compared to programming, chess has simple rules, a well-defined goal, a stable environment, etc.
I suggest you take a look at the smoke from a forest fire started by a spark from a steam locomotive. Then take a whiff of a town where every street is a foot deep in horse manure. Then come back and try to convince us that cars cause more pollution than their predecessors.
Lack of pollution in the past is almost entirely a fantasy. Especially during the early industrial revolution, many cities (especially industrial centers) had air pollution so bad that they typically ran their street lights 24 hours a day.
The fact of the matter is that the GAO report did NOT draw the claimed conclusions at all. What the GAO report says is:
They then, however, go on to note that others disagree with this viewpoint. At least to me, it appears very much as if the "American Constitutional Society" (i.e. the blog referred to in the /. summary) is mostly reading its own viewpoint into the GAO report. If you read the report itself you'll find that it expresses no such position at all, and in its actual "concluding remarks", its only mention of patents is: "The extent to which scientific, business, regulatory and intellectual property issues related to drug development can be addressed will largely determine if and how quickly these trends can be reversed."
The fact is that the report itself takes basically no stance on patents in either direction, basically stating the near tautology that if issues with patents affect innovation, then addressing those issues will affect innovation as well.
To give my summary: don't trust the summaries. Read the paper itself, and draw your own conclusions -- at least IMO, the ACS blog entry simply isn't very accurate.
No, it's not. This problem has been fairly carefully studied, and well known in the C++ community for a long time. Nobody seems very interested in fixing it, mostly because nobody is aware of a compiler that actually breaks any code this way, and it also looks like the author would have to go to a fair amount of extra work to do it, so it probably won't ever happen either.
This is thoroughly wrong it's hard to keep my reply polite. You'd be roughly correct about the generic support in Java, but about C++ templates, your statement is completely, totally and thoroughly wrong. I can't do anything approaching justice to the subject here, but I'd recommend reading Modern C++ Design by Andrei Alexrandescu, to at least start getting a clue about how much more there really is to templates. You might also want to look at the source code to The boost library for more along the same general line (e.g. take a look at boost Lambda, which is quite different from anything you can do with void pointers.
Sorry, but no. The type-checking is done at compile time, so it doesn't impose any overhead (at runtime -- in theory it makes for slightly longer compile times, but in practice the difference is rarely noticeable.
The performance of a virtual function in C++ (at least with most recent compilers I've tested) is essentially the same as the switch statement or pointer to a function you'd have to use to get the same functionality in C. The problem arises primarily from the fact that people often use virtual functions where they're not really suitable.
The differences between C++ and Java tend to get sufficiently religious quickly enough that I'll stay away from discussing that, at least for now.
I specifically talked about using qsort. Obviously, you're not doing that. It's nearly always true that more specialized code can be more efficient than more generalized code. The trick is to write generalized code that retains close to the efficiency of the more specialized code -- and C++ does a better job of that than C does.
Counting assembly instructions gave a useful of speed in the days of 68Ks and 8088s. Those days are long gone. Given that it came from a Sedgewick book, your code may easily be substantially slower ( I'm not a fan of Sedgewick).
I didn't "lapse into" anything. I pointed out two separate points: one, that the code isn't technically conforming, the other that for most practical purposes it probably won't ever matter. Which viewpoint you choose to care about is entirely your own decision. Personally, I prefer to stick as close to the theoretical ideal as reasonable, but I don't let that stop me from writing code that's portable in the real world when I need to.
So get yourself an inexpensive copy. The last time I checked, you could get an electronic copy from webstore.ansi.org for something like $20 US (or so -- it was originally $18, but I seem to recall that it's gone up a little bit).
Sorry, but that's just plain wrong. According to the standard, section D.5:
That seems pretty clear to me: by including <cstdio> you've gotten a declaration of printf in the std namespace. You could explicitly qualify the name printf (std::printf) or you could use an explicit using directive or declaration to make the name visible, or you could include stdio.h to do the same implicitly, but as it stands, your code simply isn't right, and won't work with a properly functioning compiler.
I've been trying for years, and I've still yet to come up with a more polite way of saying: "Your logic is flawed and your conclusion erroneous." I wish I could though...
Not really. I (along with most real programmers) have to combine two viewpoints to varying degrees. One is writing code that's theoretically correct, and the applicable standard(s) gurantee will work. the other is making my code actually work in the targets I care about. From the theoretical viewpoint, I can write C++ code using export, and it's all fine and good. From a practical viewpoint, that only really works with
Please read what I actually said: you've included a declaration of std::cout, but NOT a declaration of std::endl.
I have to disagree, at least to some extent. It is true that most of the mainstream languages are enough alike that they have little influence on choices in the solution. OTOH, that isn't always the case. Sufficient differences in languages (e.g. Fortran vs. Lisp) can have substantial differences on the solutions that are reasonable.
It seems to me that you've stated this too absolutely. I would say part 1 tends to vary less, while part 2 tends to vary more. OTOH, until you look at an extremely detailed level (e.g. the way you spell some specific key words and such) you can have solutions that are essentially identical between some languages and others. At the same time, designing the solution can vary somewhat based on your target language as well. Even at the most basic level, my method for solving a problem is often quite a bit different if I'm working in SQL than if I'm working in C (just for one extreme contrast). This, in turn, can be influenced by the form of the data itself -- if the data is already in a SQL database, SQL is usually the easiest way to get at the data. If it's in some flat text files, C may be easier -- and so on, of course...
I have to disagree. Essentially any C code can also be written as C++ with essentially no modifications, short of possibly minor changes in spelling (e.g. if the C code happened to use 'class' as a variable name). The reverse is not true, however -- it's entirely possible to write things in C++ (e.g. using templates) that really have no direct counterpart in C.
Some of those give considerable opportunity for optimization that's (at best) considerably more difficult in C. An obvious example would be sorting. The C library includes qsort, which allows various forms of comparison by using a pointer to a function. The C++ library includes std::sort, which is a template that accepts a name of a comparison function/functor as a parameter. This may initially seem like a trivial distinction (name vs. pointer) but, in fact, makes a huge difference -- in particular, it frequently allows the compiler to generate the comparison code in-line instead of calling a function via a pointer to do each comparison. Since the comparison itself is often quite trivial, the call via a pointer often adds a great deal of overhead -- to the point that in my experience, std::sort is typically at least twice the speed of qsort (I'll attach a bit of benchmark code to the end of the message for those who care to test with their compiler).
While it has taken a fair amount of work, libraries like blitz++ include many more optimizations like this. While the code to implement them isn't always the most readable, the library is relatively easy to use, and the code that uses it is quite readable.
I'm not sure exactly what you mean by 'one size fits all', so it's hard to reply to that. Its' true that the containers in the standard library are written with the assumption that copying is relatively cheap. Fortunately, you can essentially always provide for that, since you can use a smart pointer with cheap copying and value semantics on the (IME relatively rare) occasion that copying the object itself causes a performance problem. Given that C simply lacks any counterpart of the C++ standard containers, it's difficult to compare C to C++ in this respect, but my own experience indicates that more often than not, C code that had hand-rolled containers gets faster when converted to C++ standard containers.
This is a matter of verbosity of the code, not performance. Unfortunately, although you didn't point it out, most implementations of the iostream library really do have performance problems. Fortunately, that is strictly the library, not anything inherent to the language though. The problem arises primarily from the fact that the iostreams library has a couple of virtual function calls in the critical path. The flexibility this adds is considerable, but few programmers are aware of it, or attempt to take advantage of it, and this is one of those rare cases where you really do pay a price even when you don't use the feature.
In fairness, however, I should point out that this is an area that almost certainly could be improved considerably. Technical report 1 on the C++ language, a number of techniques that would almost certainly improve performance in this area, though I'm not aware of a full library that actually implements those techniques.
Getting back to your original comment about formatting, it's entirely possible to create a formatting class that allows you to set up a complex format, and then when you want to use that format, you simply apply the format as a whole to the stream instead of setting flags individually. While I've never attempted to write a parser
Not really. When you #include <cstdio> you get a declaration of printf in the std namespace, so you'd need to use std::printf("..."); Alternatively, you can include <stdio.h> and get printf in the global namespace, and the remainder of your code is correct.
The standard C headers are included in Appendix D of the C++ standard, and while using them is officially deprecated, I consider it highly unlikely that they'll really be removed anytime soon at all. Even when/if they should be removed from the standard proper, I'd guess that essentially every real C++ compiler will continue to include them anyway (if only because essentially every C++ compiler is also a C compiler).
Still technically wrong. is required to declare std::cout, but it's not actually required to declare std::endl. OTOH, I believe your code should work with every real C++ compiler, even though in theory a conforming implementation of C++ could be written that wouldn't accept it.