I'll nominate two of Rutherford's experiments, both of which are simple and elegant, and both of which taught us things that were genuinely new.
First is his demonstration that alpha rays are helium nuclei. And second, and more important, his demonstration of what's now called Rutherford scattering: scattering of alpha particles from nuclei. That's the experiment that first showed us that such things as nuclei existed. Rutherford's observations were utterly inconsistent with what was previously the prevailing model of atomic structure. As Rutherford himself said, these results were "as surprising as if you were to fire cannon balls at tissue paper and have them bounce back at you".
Do you have considered Eiffel or Ada? Both come with generic programmic and with a far more friendly syntax. However, they require you to specify type constraints. This adds security, it makes clear what the requirements of a type you want to pass as template argument are. But it is also more restrictive than C++.
I can't speak to Ada 95, becuase I've never done any serious work in it. (I do know that Alex Stepanov and Dave Musser wrote a precursor to the STL in Ada 83, and they thought that Ada 83 was insufficiently expressive for the kind of library they were trying to write. Perhaps Ada 95 has removed some of Ada 83's limitations.)
I have tried using Eiffel. I think it's an interesting language, and it deserves to be better known than it is. It does some things (like design by contract) better than any other language that I know of. It's a well worked out system based on a consistent philosophy, and that's almost guaranteed to be interesting regardless of the a priori merits of the philosophy.
However, I have found Eiffel's generics to be frustratingly limited compared to C++'s templates. One problem is that Eiffel demands that genericity be constrained (Eiffel's "unconstrained genericity" is just a special case of constrained genericity: it uses ANY as the constraint class), and the only kind of constraint it understands is constraint by inheritance. I agree that constraints are very important, but I find inheritance to be a relatively uninteresting special case. Constraint by inheritance misses many of the important kinds of constraints, and it behaves poorly when you're dealing with a constraint that involves several different type parameters.
I believe it's possible to have a language that's better for generic programming than C++ is. I don't think that Eiffel is that language. (And the generic extensions to Java are even less so.)
The string class that is almost part of the STL should be avoided. It is extremely inefficient to use, does not implement reference counting, and will generally cause many more problems than it is worth.
You're confusing specification with implementation. The C++ Standard doesn't say whether or not std::basic_string uses reference counting. Some implementations do, some don't. The GNU implementation does, the older Dinkumware implementation does, the newer Dinkumware implementation doesn't, the SGI implementation (which I wrote) doesn't.
As a general rule, my impression is that newer STL implementations have been moving away from reference-counted strings and towards the "small string optimization". Experience has shown that reference-counting is much more bug-prone than one might expect, that it doesn't provide as many benefits as it seemed to at first, and that its behavior, when you poke at corner cases, can be surprising.
Itanium chips could do extremely well on many of the STL algorithms. (I have wondered if the Intel Optimizing compiler for Itanium would do massivly parallel ops with valarray classes. Does anyone have experience there?)
I'm not aware of any compilers, for IA-64 or for any other arthitecture, that do special things with std::valarray. My impression is that the people who care about high-performance matrix computation in C++ are spending more effort on things like MTL and Blitz than on valarray.
It's a pity, in a way. The C++ standard was deliberately changed, in subtle but important ways, to allow implementers to do clever optimizations with valarray. But if any implementers have taken advantage of that freedom, I haven't heard about it (and I'm in touch with enough people so that I probably would have).
Many of its classes that input or output strings are only designed to work with ASCII
Which classes do you have in mind? std::basic_stringbuf (and the wrappers basic_stringstream, basic_istringstream, and basic_ostringstream) all work with generalized basic_string, which can be instantiated for narrow or wide characters. All of the I/O classes, e.g. basic_istream and basic_ostream, work with general characters: again, both narrow and wide. std::bitset contains a stringification function, and, again, it outputs a general std::basic_string and doesn't assume narrow characters. There are a very few places in the library where narrow characters are built in, but they're many fewer than someone who's reading your comment might think.
std::basic_string has no CASE-INSENTIVE comparison routine
Indeed, and there's a reason for that. basic_string doesn't know about locales, and case-insensitive comparison is meaningless except in the context of a particular locale. (Quick quiz: if you're doing a case-insensitive comparison, is the one-character sequence 0x00df equivalent to the two-character sequence 0x0053 0x0053?)
Case-insensitive string comparison is one of those subjects that sounds simple at first, but that gets more and more complicated the more you learn about it. See my article in the May 2000 C++ Report (not on the Web, alas, but it's reprinted in Scott Meyers's Effective STL) for an introduction to why this is hard.
I don't think the right approach to complexity is pretending it isn't there.
You mean they'll be removing a feature that they've had in several earlier versions? That sounds unlikely, and it sounds like a really good way to alienate customers.
7.1 and 7.2 have reiserfs compiled into the stock kernels. I've been using reiserfs for my/home partition for some time, and I've had no trouble with it on my Red Hat system. Red Hat may encourage people to use ext3fs, but they do supply a kernel that supports reiserfs and they supply all of the userland tools that you need to manage a reiserfs partition.
I'd be shocked if 7.3 were less capable than 7.1 and 7.2.
This is a standard interview question for me, when I interview programmers. "In what case would you want to use a bubble sort?"
And the correct answer is: never.
It's true that for small lists, or lists that are nearly sorted, you want to use an O(N^2) algorithm rather than (say) quicksort. The mistake is making the leap from "an O(N^2) algorithm" to "bubble sort".
There are lots of O(N^2) sorting algorithms, with different constant factors. Bubble sort is one of the worst; see Knuth (v. 3, of course) for a detailed analysis. If you're dealing with a small list or a nearly-sorted list, you should probably use insertion sort. (Or, in some special cases, you might want selection sort or merge sort instead.)
I have yet to find any case, anywhere, where bubble sort is the right choice. If I ever teach an introductory algorithms class, I will probably omit bubble sort.
As the representatives of the law of those states, if those 9 attorneys general just keep holding out, as long as they feel MS has violated the fair business practice laws of their states, they have it perfectly within their rights to (they can at LEAST do this much) block MS from selling software in that state.
I don't believe this is within the states' rights. Article 1, section 8 of the US Constitution gives the Federal government the right to regulate interstate commerce. As a consequence, states do not have the right to regulate interstate commerce. Banning the sale of a particular product from another state would almost certainly qualify.
More seriously, most people whose favorite language is C++ have never used or even seen a Common Lisp implementation. At most, they might have been scarred by a few-week introduction to a limited Lisp dialect, which is "obviously" only useful for toy recursion problems.
I've used Common Lisp, Franz, Interlisp, Maclisp, Scheme, Emacs lisp, Zetalisp, UCI lisp, and probably a few other lisp dialects I've forgotten about. I took 6.001 at MIT, which used Scheme. My first programming job was to work on an automated medical diagnosis system. (Originally written in Interlisp, later ported to Franz. I wrote the database editor.)
I mostly use C++ nowadays; it offers abstraction
features that I haven't found in any lisp dialect I've ever used.
But then, on the other hand... I think MIT is right to use Scheme in its introductory CS class, and I do think that serious programmers ought to become familiar with lisp. It's always bad to be parochial, and lisp is likely to expose you to ideas you won't see otherwise.
Depends on what you mean by "standard".
It's true that the C++ standard doesn't specify
a C++ ABI. (It can't, since an ABI necessarily
depends on the platform.) However, the new
ABI for g++ does conform to an informal standard
defined in http://www.codesourcery.com/cxx-abi. This ABI was defined cooperatively by a number of companies with an interest in C++ interoperability; it was originally defined for the Intel Itanium, and was later generalized to other platforms.
What I would like to see is an implementation standard for C++
What you're looking for is called an ABI
(application binary interface). And, of course,
what you really need isn't an ABI, but
an ABI for each platform you care about. Since
you mention Sun Forte, for example, you probably
care about an ABI for Sparc/Solaris.
Some ABIs already exist; they're usually
defined by platform vendors. Sun, for example,
has published its C++ ABI.
There's currently a multi-vendor effort to
write a C++ ABI for Unix (various flavors,
including Linux, Solaris, HPUX, and IRIX)
running on Intel's new IA-64 architecture.
The work is almost
complete. The ABI is necessarily quite
complicated, of course.
I don't see that this can ever be something
that the C++ standardization committee can
deal with, since an ABI has to involve a lot
of very specific platform issues. (Which
register you use for passing which argument,
etc.)
They're working on the next revision of Standard (That's ANSI _AND_ ISO Standard) C++.
Actually, just to be picky: we are not
working on the next revision of Standard C++.
We are just beginning to think about working
on the next revision of Standard C++. Many
people on the C++ standardization committee
believe it's time to start thinking about what
the next revision should look like, but the
committee has not officially started work
on it and there are as yet no official plans
for it to do so.
There will be a standardization committee
meeting next week, in Copenhagen, and there
will be some informal discussions about this,
with something like Bjarne's SD talk as
a starting point. Formal discussions have
not begun and have not yet been scheduled.
There's an intermediate step between doing
nothing and coming up with a whole new revision
of the language: a technical report that
describes some semi-official library
extensions. (One obvious candidate would be
hash_set and hash_map, which
are now widely in use but which exist in
at least three slightly different versions.)
It's generally agreed that library extensions
are more appropriate at this point than core
language changes, so I think it's likely that
we'll see that library extension TR before
we see a new C++ standard.
My understanding is that Finder is, indeed,
not cocoa. Further, my understanding is that
it's impossible to write a cocoa program
unless you write it in Objective C or Java.
If you want to use C, or C++, you have no
choice but to use carbon.
I hope I'm wrong about this. If I'm right,
then I don't expect carbon to go away any
time soon. I find it very unlikely that
developers will switch to a new language
just so they can port their program to a
new version of an OS. Building that sort
of language dependence into their new API
strikes me as a mistake.
This shows the disadvantage of writing "C/C++",
as if C and C++ were the same language.
Strings are one of the ways in which C and C++
differ. C typically represents strings as
null-terminated arrays of characters; C++,
however, represents strings using the std::string
class. (Or, if you want to be pedantic,
the std::basic_string class template.) In C++,
it is important to distinguish between strings
and string literals.
See Koenig and Moo's Accelerated C++ for
a nice introductory discussion.
Slashdot Mirror
Exported templates, universal character names in identifiers, and a few less important things. As of 3.1, gcc has a pretty complete standard library.
I'll nominate two of Rutherford's experiments, both of which are simple and elegant, and both of which taught us things that were genuinely new.
First is his demonstration that alpha rays are helium nuclei. And second, and more important, his demonstration of what's now called Rutherford scattering: scattering of alpha particles from nuclei. That's the experiment that first showed us that such things as nuclei existed. Rutherford's observations were utterly inconsistent with what was previously the prevailing model of atomic structure. As Rutherford himself said, these results were "as surprising as if you were to fire cannon balls at tissue paper and have them bounce back at you".
I can't speak to Ada 95, becuase I've never done any serious work in it. (I do know that Alex Stepanov and Dave Musser wrote a precursor to the STL in Ada 83, and they thought that Ada 83 was insufficiently expressive for the kind of library they were trying to write. Perhaps Ada 95 has removed some of Ada 83's limitations.)
I have tried using Eiffel. I think it's an interesting language, and it deserves to be better known than it is. It does some things (like design by contract) better than any other language that I know of. It's a well worked out system based on a consistent philosophy, and that's almost guaranteed to be interesting regardless of the a priori merits of the philosophy.
However, I have found Eiffel's generics to be frustratingly limited compared to C++'s templates. One problem is that Eiffel demands that genericity be constrained (Eiffel's "unconstrained genericity" is just a special case of constrained genericity: it uses ANY as the constraint class), and the only kind of constraint it understands is constraint by inheritance. I agree that constraints are very important, but I find inheritance to be a relatively uninteresting special case. Constraint by inheritance misses many of the important kinds of constraints, and it behaves poorly when you're dealing with a constraint that involves several different type parameters.
I believe it's possible to have a language that's better for generic programming than C++ is. I don't think that Eiffel is that language. (And the generic extensions to Java are even less so.)
Assuming you want to use newfangled languages like C in the first place, of course. What's wrong with FORTRAN IV and LISP 1.5?
You're confusing specification with implementation. The C++ Standard doesn't say whether or not std::basic_string uses reference counting. Some implementations do, some don't. The GNU implementation does, the older Dinkumware implementation does, the newer Dinkumware implementation doesn't, the SGI implementation (which I wrote) doesn't.
As a general rule, my impression is that newer STL implementations have been moving away from reference-counted strings and towards the "small string optimization". Experience has shown that reference-counting is much more bug-prone than one might expect, that it doesn't provide as many benefits as it seemed to at first, and that its behavior, when you poke at corner cases, can be surprising.
I'm not aware of any compilers, for IA-64 or for any other arthitecture, that do special things with std::valarray. My impression is that the people who care about high-performance matrix computation in C++ are spending more effort on things like MTL and Blitz than on valarray.
It's a pity, in a way. The C++ standard was deliberately changed, in subtle but important ways, to allow implementers to do clever optimizations with valarray. But if any implementers have taken advantage of that freedom, I haven't heard about it (and I'm in touch with enough people so that I probably would have).
Which classes do you have in mind? std::basic_stringbuf (and the wrappers basic_stringstream, basic_istringstream, and basic_ostringstream) all work with generalized basic_string, which can be instantiated for narrow or wide characters. All of the I/O classes, e.g. basic_istream and basic_ostream, work with general characters: again, both narrow and wide. std::bitset contains a stringification function, and, again, it outputs a general std::basic_string and doesn't assume narrow characters. There are a very few places in the library where narrow characters are built in, but they're many fewer than someone who's reading your comment might think.
Indeed, and there's a reason for that. basic_string doesn't know about locales, and case-insensitive comparison is meaningless except in the context of a particular locale. (Quick quiz: if you're doing a case-insensitive comparison, is the one-character sequence 0x00df equivalent to the two-character sequence 0x0053 0x0053?)
Case-insensitive string comparison is one of those subjects that sounds simple at first, but that gets more and more complicated the more you learn about it. See my article in the May 2000 C++ Report (not on the Web, alas, but it's reprinted in Scott Meyers's Effective STL) for an introduction to why this is hard.
I don't think the right approach to complexity is pretending it isn't there.
You mean they'll be removing a feature that they've had in several earlier versions? That sounds unlikely, and it sounds like a really good way to alienate customers.
7.1 and 7.2 have reiserfs compiled into the stock kernels. I've been using reiserfs for my /home partition for some time, and I've had no trouble with it on my Red Hat system. Red Hat may encourage people to use ext3fs, but they do supply a kernel that supports reiserfs and they supply all of the userland tools that you need to manage a reiserfs partition.
I'd be shocked if 7.3 were less capable than 7.1 and 7.2.
And the correct answer is: never.
It's true that for small lists, or lists that are nearly sorted, you want to use an O(N^2) algorithm rather than (say) quicksort. The mistake is making the leap from "an O(N^2) algorithm" to "bubble sort".
There are lots of O(N^2) sorting algorithms, with different constant factors. Bubble sort is one of the worst; see Knuth (v. 3, of course) for a detailed analysis. If you're dealing with a small list or a nearly-sorted list, you should probably use insertion sort. (Or, in some special cases, you might want selection sort or merge sort instead.)
I have yet to find any case, anywhere, where bubble sort is the right choice. If I ever teach an introductory algorithms class, I will probably omit bubble sort.
I don't believe this is within the states' rights. Article 1, section 8 of the US Constitution gives the Federal government the right to regulate interstate commerce. As a consequence, states do not have the right to regulate interstate commerce. Banning the sale of a particular product from another state would almost certainly qualify.
More seriously, most people whose favorite language is C++ have never used or even seen a Common Lisp implementation. At most, they might have been scarred by a few-week introduction to a limited Lisp dialect, which is "obviously" only useful for toy recursion problems.
I've used Common Lisp, Franz, Interlisp, Maclisp, Scheme, Emacs lisp, Zetalisp, UCI lisp, and probably a few other lisp dialects I've forgotten about. I took 6.001 at MIT, which used Scheme. My first programming job was to work on an automated medical diagnosis system. (Originally written in Interlisp, later ported to Franz. I wrote the database editor.)
I mostly use C++ nowadays; it offers abstraction features that I haven't found in any lisp dialect I've ever used.
But then, on the other hand... I think MIT is right to use Scheme in its introductory CS class, and I do think that serious programmers ought to become familiar with lisp. It's always bad to be parochial, and lisp is likely to expose you to ideas you won't see otherwise.
Depends on what you mean by "standard". It's true that the C++ standard doesn't specify a C++ ABI. (It can't, since an ABI necessarily depends on the platform.) However, the new ABI for g++ does conform to an informal standard defined in http://www.codesourcery.com/cxx-abi. This ABI was defined cooperatively by a number of companies with an interest in C++ interoperability; it was originally defined for the Intel Itanium, and was later generalized to other platforms.
What you're looking for is called an ABI (application binary interface). And, of course, what you really need isn't an ABI, but an ABI for each platform you care about. Since you mention Sun Forte, for example, you probably care about an ABI for Sparc/Solaris.
Some ABIs already exist; they're usually defined by platform vendors. Sun, for example, has published its C++ ABI.
There's currently a multi-vendor effort to write a C++ ABI for Unix (various flavors, including Linux, Solaris, HPUX, and IRIX) running on Intel's new IA-64 architecture. The work is almost complete. The ABI is necessarily quite complicated, of course.
I don't see that this can ever be something that the C++ standardization committee can deal with, since an ABI has to involve a lot of very specific platform issues. (Which register you use for passing which argument, etc.)
Actually, just to be picky: we are not working on the next revision of Standard C++. We are just beginning to think about working on the next revision of Standard C++. Many people on the C++ standardization committee believe it's time to start thinking about what the next revision should look like, but the committee has not officially started work on it and there are as yet no official plans for it to do so.
There will be a standardization committee meeting next week, in Copenhagen, and there will be some informal discussions about this, with something like Bjarne's SD talk as a starting point. Formal discussions have not begun and have not yet been scheduled.
There's an intermediate step between doing nothing and coming up with a whole new revision of the language: a technical report that describes some semi-official library extensions. (One obvious candidate would be hash_set and hash_map, which are now widely in use but which exist in at least three slightly different versions.)
It's generally agreed that library extensions are more appropriate at this point than core language changes, so I think it's likely that we'll see that library extension TR before we see a new C++ standard.
My understanding is that Finder is, indeed, not cocoa. Further, my understanding is that it's impossible to write a cocoa program unless you write it in Objective C or Java. If you want to use C, or C++, you have no choice but to use carbon.
I hope I'm wrong about this. If I'm right, then I don't expect carbon to go away any time soon. I find it very unlikely that developers will switch to a new language just so they can port their program to a new version of an OS. Building that sort of language dependence into their new API strikes me as a mistake.
This shows the disadvantage of writing "C/C++", as if C and C++ were the same language.
Strings are one of the ways in which C and C++ differ. C typically represents strings as null-terminated arrays of characters; C++, however, represents strings using the std::string class. (Or, if you want to be pedantic, the std::basic_string class template.) In C++, it is important to distinguish between strings and string literals.
See Koenig and Moo's Accelerated C++ for a nice introductory discussion.