[...] the people of New York [ ... ] could maybe even revoke the MTA's right to use it.

That wouldn't make any difference -- the MTA already seems to ignore it completely!

Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.

I think you're overstating things a bit. It's certainly true that Concepts would have been an improvement, and would have made life a whole lot easier for a whole lot of people -- but let's face it, "renaissance" implies that we're currently in a dark age, and that's overstating things quite a bit. Point one, there's pretty substantial work being done right now. Point two, concepts are not going to allow an average programmer to just decide that they're going to recreate something like Spirit or Proto or Xpressive this afternoon, or anything like that.

I also the think "petty politics" is going overboard, at best. Howard Hinnant seems to have been the one who started the discussion at the last meeting that ultimately led to the removal of concepts from the draft standard -- and I find an accusation of his being involved with petty politics completely unbelievable. Quite the contrary, the (admittedly few) times I've talked with him, he struck me as a very level-headed person who was careful to evaluate ideas on their merits. Likewise, Beman Dawes, Bjarne himself, and (since you brought him up) Dave Abrahams don't seem to me exactly "petty politics" kinds of people either.

I'd also note that when it came to a vote, the overwhelming majority of committee members voted to remove them -- including (for one example) Douglas Gregor, the primary author of ConceptGCC, and one of the coauthors of both N1758 and N1849 (the two versions of the Indiana Proposal).

I think the vast majority of the committee simply believed that including concepts would delay the standard by a minimum of a couple years, and probably longer than that. A fair number of features originally intended to be included in C++0x have been removed for exactly the same reason, though quite a few others have localized enough effects that they're currently scheduled for a TR (Technical Report) rather than waiting for the next major update to the standard itself. Unfortunately, since they make fundamental changes to the type system, I don't think concepts can be added in the same way.

*(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).

I object your honor. Everybody knows a proper blues guitarist is short and fat, with black hair and a scraggly beard -- and this "Dave" is about as different from that as humanly possible! :-)

Now that the finalization has slipped past 2009, it's C++1x.

No, it is not C++ 1x. There's already a project that's called C++ 1x, which is slated to be the next revision of C++. There's also a plan for a Technical Report (TR) intended to be published a couple years (or so) after the C++0x revision, but before C++1x.

I'd note that it's actually fairly common for final approval of a language to happen some time after the date by which it's usually known.

• Fortran 2008: Not finished yet, most recent draft dated 23 June 2009
• Algol 60: Approved as an ISO standard in 1984
• Simula 67: Approved as a Swedish national standard in 1987 (never approved as an ISO standard)

As is all too often the case here on Slashdot, the summary has seized upon the title of the patent, which has no legal effect whatsoever, while ignoring the actual patent claims, which are all important.

Geeze, there you go ruining everybody's fun, posting facts instead of completely uninformed complaints.

Next you'll point out that the patent cites no fewer than 77 other patents going back to 1988 as related art, or that it cites 113 other documents, including documentation for file formats of things like AbiWord, StarOffice, Wisdom++, Docbook, WorX, MML, XMill, YAWK, and so on and so forth.

Were it not for your UID, I'd have to pull out the "you must be new around here" wheeze, since you're in clear violation of /. groupthink guidelines!

That's an interesting claim. According to the manufacturer "The exact formula and specific ingredients used in making Elmer's products are considered proprietary information, therefore, we cannot share those with you."

In any case, the PVA in an LCD panel is not as an ingredient in glue. It's used to build polarizers.

The bad news is that the LC material itself is very similar to some known carcinogens...

Undoubtedly meant to be funny, but the serious answer is no. What they're using is PVA (Polyvinyl Alcohol). An LCD panel has a polarizer on the front and back, and a layer of PVA is what actually does the polarizing. The polarizers are pretty much the same regardless of the response time... :-)

Regarding your fourth citation: Java's generics aren't "reified". If you care about what the means, here's a short article on the subject. I'm not trying to say I think Java's generics are entirely inferior, or anything like that -- just that what you've cited isn't really exactly the same thing.

Likewise, your fifth citation regards dynamic classes. The other post was about dynamic methods. A dynamic class means you can create a new class at run time. A dynamic method means you can create a new method for an existing class at run time. While there's certainly similarity between the two, they're just as certainly not the same thing.

To give a really simplified (but hopefully not to the point that's it's actively misleading) explanation: for Java, think of a grid with classes along one axis, and interfaces along the other axis. A dynamic proxy class lets you put an 'X' at a more or less arbitrary box in that grid, setting up the connections so that class implements that interface. On the C# side, think of a class as having a row of boxes, one for each method in that class. A dynamic method allows you to add an entirely new box to the row, so it now has a method that didn't previously exist at all.

Unfortunately, if the method for that "box" is really completely new, you won't have other code that knows how to use it, and it won't necessarily accomplish a lot. One obvious use is about like in Java, to add methods that some existing code already knows how to use. OTOH, it certainly is possible to use it other ways. For one example, another program sends some previously unknown message, and you connect things up so that message ends up invoking your entirely new function. Taken to an extreme, you could define your "program" as little more than a tiny framework, for defining functions and connecting them to be invoked by messages (collecting appropriate data from dynamically generated forms).

Yes. Did you bother to read what I said? The "even if" part fairly explicitly states that I was not commenting on the "comparison" that's currently provided, but on the possibility that "even if" they did write a comparison with enough depth to be meaningful, that there was a hint of a possibility that such a comparison might be somewhat biased.

Such bias is hard to avoid even under the best of circumstances. Even an author who really tries to be objective still tends to have rather set attitudes about the familiar versus the unfamiliar. I don't use either regularly, and don't care for either one, but I'm still enough more familiar with Java that I'd probably have difficulty comparing the two entirely fairly. For somebody who knows Java far better and uses it a great deal more, a truly unbiased comparison becomes simply impossible.

In this case, the problem is compounded considerably though: even if (somehow) they managed to write a comparison that was both meaningful and unbiased, the people to whom it could be useful would have no way of verifying its lack of bias. The only people who could/would know such a thing would be those with sufficient knowledge of both languages and platforms that they no longer needed any such comparison.

I stand by my original comment: the cited comparison is completely meaningless, and even if it did mean something, nobody who needs it would know enough to be certain whether they could trust it.

Personally, I don't care one way or the other (I don't care for either one), but I'm left wondering: could anybody honestly consider the "comparison" on the cited site useful in any way, shape, form, or fashion? Even if it provided a comparison that was deep enough to have a hope of meaning something, do you think there's just a hint of a possibility that a web site hosted on "javacamp.org" might have (and provide) a slightly biased view in a comparison between Java and any perceived competitor?

Project: 64 Channel logic analyzer.
Your Language: C
My Language: VHDL


Good luck!

And then the author concludes:

But HP's and Dell's prices are either comparable (for the 73 GB SAS drive) or $200 to $250 higher (for the 1 TB SATA and 300 GB SAS drives).. . . To sum up, there are multiple good reasons why ADMs cost more than bare retail drives of the same size, it's possible but not recommended to replace the drive in one, and Apple is in no way charging an unusual premium for ADMs.

Parts of this may be true (it's impossible to say, since they don't specify exactly what they're comparing) -- but even if parts are true, it's misleading at best. In fact, some of it doesn't even seem to make sense. Let's look at real price lists from Apple and dell.

First we note that Dell doesn't seem to offer a 73 GB drive at all, so it's not entirely clear what they're comparing. The most likely possibility appears to be Apple's smallest option, a 73 GB SAS ADM ($300) to Dell's smallest, a 146 GB SAS ($349). While it's certainly true that the prices are comparable, it's also true that the Dell drive is twice as big.

For 300 GB SAS drives, the Apple site shows $650 while the Dell site shows $699. While Apple's price is lower, it's certainly not even close to $200 lower. To get a $200 price difference, it looks like they compared the full price of a 300 GB drive for the Dell to upgrade price for the Apple (i.e. the price difference for changing from the stock drive to the 300 GB drive).

For 1 TB hard drives, they have something of a point, but not a very good one. Apple's price for a 1 TB SATA drive is $450, while Dell's is $639. They fail to note, however, that Dell also lists a 1 TB SAS drive (an option not available for the XServe) for $679. Taking this into account, it looks a great deal as if Dell is simply doing their best to encourage their higher-end customers to use enterprise-class SAS drives by offering them at a purely nominal incremental cost over SATA drives.

The original article attempts to portray the situation as Apple offering prices that are at least as good as, and often better than the competition. In reality, there appears to be only one reasonable configuration where the Apple is likely to be competitive: the one using 300 GB SAS. At the low end, the Dell offers twice as big of a drive as the Apple for a purely nominal price difference. For lots of storage, the Apple offers only SATA drives where Dell offers SAS. If you're storing 1 TB of data (or more) the incremental cost of SAS is usually fully justified. There are undoubtedly exceptions, but they're not particularly common.

How is storing the length wasteful of memory? 99% of the time I'd guess as much space would be used in storing a null character as would be consumed storing the length of the string itself.

You're basically right: the vast majority of strings are short enough that a single byte could hold the length. The problem is that if you decide to use only a single byte to hold the length, the design limits ALL strings to 255 characters -- and unfortunately, even though most strings are short, a few are long. A good design should be optimized for the common case, but allow anything that's at all reasonable.

There are, however, alternatives to NUL-termination to allow that. One example would be to have the initial byte hold the length for strings up to size X, but also have a value (or two) that signal the the next N bytes hold the real length. For most strings, this would waste no space at all. It would waste a little space only for the few that are quite long.

Of course nothing is free -- the penalty in such a case would be extra complexity in the string handling code.

This was to satisfy Bill G's desire to "factor large prime numbers."