Do the CMT chips assume greatly expanded L1 and L2 caches? The more threads, the broader and more scattered the working set.
Most CMT simulations (at least that I've seen) have assumed larger caches. Most implementations don't match -- which seems to be a large part of why it's not working nearly as well in real-life as simulations.
Of course, the simulations also often assume a more or less optimal mix of compute- and I/O-bound threads, where improving thread-switching speed helps a lot. Again, real-world loads are rarely so cooperative.
--
The universe is a figment of its own imagination.
Just ban software patents, period! Is that too hard?
Yes, it is. For quite a long time, the patent office didn't even accept applications for patents on software, deeming them "nonstatuatory material" (i.e. not patentable), much like mathematical formulae.
The courts struck that down based (largely) on the basis of machinery with embedded processors, saying that the mere fact that a process (for example) happened to be carried out under software control didn't suddenly invalidate the patent. The original case was related to a machine for making tires. The process was patented, and somebody built a machine that did exactly what the patent described, but partly under software control. The court eventually decided that the patent applied anyway, because they couldn't find a meaningful way to differentiate them.
Even so, (at least in the US) technically there aren't patents on software per se anyway -- they patent is on something like a method or process (that might be implemented in software) or an apparatus that does something (again, perhaps under software control), or an "article of manufacture", etc. -- for example, on the CD-ROM containing the software, not on the software itself.
IMO, trying to separate between hardware and software is nearly impossible though -- there are simply too many "corner" cases that make such a separation difficult in either direction. If I pre-program a microcontroller to act exactly like a well-defined (but, for example, obsolete) piece of hardware, why should the fact that internally it's using code in a ROM have anything to do with anything? In the opposite direction, does something like a CPLD or FPGA fall under software or hardware?
That really only leaves two choices: allow patents (even on things that might be implemented partly or entirely in software) or else don't allow patents (at all).
For better or worse, at least in the US, that's not likely to happen anytime soon. First of all, eliminating patents would require a constitutional amendment, which is never easy. Second, a substantial portion of what the US exports is intellectual property, largely in the form of patent licenses. Given the US's trade balance, it seems highly unlikely (at least to me) that anybody's going to seriously contemplate something that would eliminate that entire business in one fell swoop.
--
The universe is a figment of its own imagination.
Sure on a desktop which will likely have HW accel this isn't a problem but on some laptop [e.g. with an ATI or S3 card] where HW accel is non-existent it's a pain.
Hi Tom,
It's been a long time -- good to see you're still around.
I'm not sure which ATI chip set you have, but my laptop has a Mobility Radeon 7000, which definitely does have alpha-blending hardware. Elsethread you mentioned this as a possible driver problem, which may well be right. If you haven't already, it might be worth looking at http://dri.freedesktop.org/wiki/ for one possible source of drivers that might give you better hardware support. I don't have any really ancient hardware handy to test with, but as I said, I definitely get hardware alpha blending at least as far back as the Radeon 7000, which certainly isn't what you'd call particularly new. I haven't had any S3 hardware to test with for quite a while, but the DRI site at least claims to support some of it, and even some really old stuff (for the Virge) that's incomplete supports Alpha blending in hardware anyway.
--
The universe is a figment of its own imagination.
Things like that are novelties that keep people interesting in writing it. Transparent shells have little actual use [and waste resources] but look cool and give you braging rights.
Transparent windows are pretty easy to implement without wasting much in the way of resources. Nearly any reasonably recent graphics card has alpha blending hardware.
There is a little bit of bloat in that you need to use an RGBA format instead of RGB -- but even this is a tradeoff, not a simple loss. It uses more memory, but along with giving you alpha blending, it (usually) speeds up processing in general, because the bits for one pixel fit nicely in a word, over a bus, etc., without constant shifting/rotating/swizzling. In fact, most people I've seen run in 32-bit color modes all the time, even though they almost never use the alpha blending it enables -- and the extra memory involved is on the grapics card anyway.
IOW, yes it uses extra resources -- but the resources it uses would just sit idle otherwise. The resource consumption involved is nearly meaningless unless you're running on something truly ancient that doesn't directly support it in hardware.
--
The universe is a figment of its own imagination.
2) C++ Algorithms 3rd Edition by Robert Sedgewick also Addison Wesley books. Why? You seriouly have to know your date structure skills, linked lists, stacks, trees, queues and its accompanying algoritms, such as: searching and sorting, merging and merge sorting. Stroustrups books assumes you know how these all come together, if you do not believe this, then look at his stark and algorithmically complex data structure examples, once this is read everything will be a piece of cake, believe this, do not fool yourself.
While I agree that a good book (or three) on algorithms is necessary, this book does not qualify, at least IMO. I would recommend Introduction to Algorithms by Cormen, Leiserson, Rivest and Stein as one of many superior alternatives. It has a few problems as well (mostly excessive formality) but at least it has the information you need. Of course the old standby in this genre is to get all three volumes of Knuth, plus the "fasicles" of volume four that are coming out (supplemented as needed in areas he hasn't covered yet). If you can find a copy of Algorithms + Data Structures = Programs by Niklaus Wirth, it's a very good book as well (though I'm pretty sure it's been out of print for quite a while -- but getting your favorite used book store to search for ISBN 0-12-022418-9 may be worthwhile). As you might expect, this uses Pascal for its examples, but for this kind of book, the specific language used doesn't matter all that much.
If you want more detail about these books (such as why Sedgewick's is utterly worthless) see: http://tinyurl.com/d68kl.
Last Word: Stroustrups book is definite worth in purchase and you cannot consider yourself a C++ software engineer, or C++ Software/Systems architect without having this book in your library, but patience and read books 1,2, and three first in that order.
Hmm...oddly enough, I don't have this book, and manage to get by fairly well -- IMO, if you want a book on software engineering, something by Grady Booch or Bertrand Meyer would be a better bet. Somewhere in here there should also be a mention of Structure and Interpretation of Computer Programs -- in fact, it might be the most important and useful of all -- even though it uses Scheme rather than C++.
Another incredibly powerful weapon for world's largest loose cannon to be playing with. Go America!
While it's theoretically possible that a weapon might be derived from this research someday, but for a moment think about what this is really talking about.
It's a machine that can accelerate a tiny disc of metal very quickly, but only for a short distance, and AFAICT, it's all happening down inside of a big machine so about the biggest thing you could kill with it might be a cockroach.
Right now, as far as killing things goes, it's not a weapon -- it's just a $6+ million bug exterminator!
Hmm...bug extermination for only $6 millon or so. Maybe MS should buy a few dozen!
c += c++ + ++c
c = c + (c+1)+(c+1)
the increment operator (++) takes precedent over addition (+).
So the parser (should) created the second formula above.
You've modified c three times without any intervening sequence points, which gives undefined behavior. See http://dspace.dial.pipex.com/town/green/gfd34/art/ and click on "bloopers", or just Google for "nasal demons" (honest!)
Also note that if you don't insert spaces yourself, "c+++++c" is NOT tokenized as "c++ + ++c" either -- it's tokenized as "c++ ++" and then lexing will normally stop because what you have is illegal. Google for "maximum munch".
The biggest problem in SSE2 is that the only compiler that optimizes it well is Intel's, gcc sucks when generating code for the P4, but with hand-optimized code this is irrelevant. If the Intel architecture that Apple will adopt has SSE2, this could be very good news for developers. Let's hope Apple implements efficient optimization for SSE2.
IMO, you've almost hit on an important point, but then missed it. The Intel compiler is currently available for Windows and Linux -- and it's a fair bet that relatively soon, it'll be available for OS X as well.
At least for portable code, Apple can just use the Intel compiler instead of re-implementing what it does.
So, if a guy wanted to build a more "modern" homebrew CPU, what options are there? Are there any decent CAD tools that don't cost a thousand million dollars? And once a layout is done, is there anywhere you can get just one single chip made for a reasonable price?
Yes -- Xilinx and Altera (and probably others as well) will let you download toolkits for free. They allow you to work in Verilog/VHDL or schematics (though most people use the latter primarily to see what the V* has produced).
If you only want one chip, you're probably best off using an FPGA or CPLD. Xilinx has a development kit (using a Digilent board) available for $100US. It has a 200 Kgate Spartan 3, which is plenty to build a variety of CPUs. If you really want to low-ball things, they have a $50US kit with something like a 50 Kgate CPLD. While that should be plenty for something like a Z80, it's still half the price for a quarter the gates...
Of course, Altera has some cheap development kits as well, but at least the last time I looked, their low-end kits didn't look (to me) like nearly as good of deals.
If you really want custom hardware made: well, the cheapest I know of for a one-off chip is around $10K. That's a lot better than the $100+ K just for maskwork to do conventional fabrication, but still way too high for most hobbyists. Below that, you're more or less stuck with an FPGA/CPLD or else hardwiring from individual gates.
Elsethread there was mention of the "big guys" with their Verilog tools not being able to do things like this. While opencores.org certainly isn't Intel, it also certainly has enough IP that putting together something on this order wouldn't really be a particularly huge challenge. They have a number of CPU cores, including some that emulate things like MIPS, so compilers aren't a major problem. Using the Wishbone SoC bus, connecting one of those to their Ethernet core should be fairly simple, and you're already about 90% done. Alternatively, you might want to look at the 10M Ethernet circuitry at fgpa4fun. The Ethernet core on opencores.org is only a MAC (so you'd need a separate PHY), but this outlines an on-chip PHY.
Those who are sufficiently serious that they don't like fpga4fun very well might prefer to look at the FPGA CPU site instead.
As you'd expect from the name, opencores.org is devoted to open source. The IP on the others varies, but IIRC, most of them are open to at least some degree as well.
Object Oriented Programming theory would disagree with you.
This begs the question "what Object Oriented Programming theory?"
There is no one all-encompassing theory of object oriented programming, any more than there is one univerally-agreed upon theory of the meaning of life.
Alan Kay seems to disagree with you anyway -- to quote from his HOPL II talk, "OOP is a late binding stategy for many things..." Given his attitude toward parsimony and generality, he clearly would have left out the "for many things" qualification if he considered it possible -- he qualified the statement because the qualification was necessary.
It's only because Stroustrop couldn't get that working when he was writing his semi-OOP preprocessor to C (C++, perhaps you've heard of it) that this key part of OOP started getting ignored.
Nonsense. It would have been substantially simpler to design C++ to use only late binding -- after all, he clearly had late binding working to have virtual functions at all, and once it was working, simply using it consistently would be simpler than using it but also allowing for early binding.
In chapter 1 of The Design and Evolution of C++ Bjarne outlines much of the original motivation for C++, and in doing so points out why late binding for everything would not have fit his goals, one of which was that (what eventually came to be called) C++ would "...produce programs that ran as fast as BCPL programs..." (section 1.1, page 21, for anybody who wants to read more). This became (and continues to be) one of the most fundamental ideas in the design of C++: you shouldn't pay for what you don't use. In this case, it applies very directly: you should only pay the speed penalty for late binding when you also need the flexibilty of late binding.
In addition, early binding allows a more direct expression of a design at a high level than is possible if only late binding is allowed. Specifically, early binding (i.e. a non-virtual function) expresses a class invariant, a concept that is virtually (no pun intended) impossible to express in Simula or Smalltalk, except via comments.
The world doesn't begin and end with what can be done easily in a C derivative language. Take a look at Smalltalk-72 to see what OOP was supposed to be.
The world doesn't begin and end with what can be done easily in an early version of Smalltalk whose design was based less on what was desirable, and more on what would fit into physically small machine using the technology of the early 1970's.
Windows has always been case-insensitive and case-preserving in the NT codebase
For what little it's worth, the NT codebase has always allowed the programmer to decide whether it should be case sensitive or not -- FILE_FLAG_POSIX_SEMANTICS gets you case-sensitivity.
For better or worse, the standard libraries for most compilers do not pass this flag in their implementations of fopen, ifstream::open, etc., so in most cases you can only get case sensitivity with direct OS calls, not via the standard library.
Sure, it makes life a little easier for lazy compiler writers and it's habit in people who've never bothered to learn any languages not derived from C but the point of a programming language is to make things easier for the human and not the compiler.
Doing case-insensitivity well is substantially more difficult than you suggest. From a purely English-speaking viewpoint, the problem is trivial. From some other viewpoints, it becomes less so. For an obvious example, to me it's obvious that 'b' and 'B' should compare equal to each other -- but to a native Russian speaker, it's equally obvious that they should compare as not equal to each other.
Once there's general agreement about how to do this in general, compilers will most likely implement those agreements, but as long as it's an open question, most compiler writers are (wisely, IMO) leaving it alone.
Other signs of C-blinders are thinking that three-part loop constructs are a good thing, that curly braces are actually either ergonomic or intuitive or that semicolons are how you end sentences;
Ending statements with semi-colons is hardly unique to C -- and given the number of purposes for which the period is already used, the semicolon is a relatively easy choice.
Presumably your mention of three-part loop construct is looking at C's for-loop. While it undoubtedly isn't anywhere close to perfect, it's still an awful lot closer than most of the alternatives. Just for a couple of examples, Pascal's was so limited it was useless for anything but the very simplest of loops. PL/I supported more of the flexibility allowed in C, but degenerated into unreadability for any but the most trivial of loops. Just for example, try to figure out what sequence of values is iterated through with this:
DO X = N, N+8 TO 20 WHILE (F<=MAX), N*2+1 BY X WHILE (F>MAX & N<200);
Granted, it's possible to do so with a bit of work, but it can be decidedly non-trivial -- and in fact, it's fairly easy to write self-conflicting conditions, so you need to know a lot about expression evaluation to be sure what will happen under some circumstances.
That, of course, brings up the next big problem: in quite a few languages, loop conditions are unique unto themselves, with different rules both for syntax and semantics than the equivalent written elsewhere -- so the programmer has to learn two or even three sets of (inevitably conflicting) rules about how to do essentially the same things. While the C programmer may need to learn a bit more up-front, once it's learned it can be applied throughout.
Those of use who've been around long enough to be sure we don't wear "C blinders" (I.e. we started programming long before C came along) can remember all sorts of other...interesting things in some languages. Just for a couple of examples, consider:
do 10 i = 1.10
in Fortran. Now if that was:
do 10 i = 1,10
it would be a do loop, equivalent to "for i = 1 to 10" in BASIC. Unfortunately, the simple typo of replacing the comma with a decimal point changes it entirely. In fact, it's a simple assignment of 1.10 to a variable named 'do 10 i' with is perfectly legal and legitimate, but enough to make temporarily reduce nearly anbody's sanity level.
First of all, releasing data on the CPU is nowhere close to enough for anybody to even think about cloning the console.
Second, if somebody did start cloning and selling consoles, Sony probably wouldn't mind a bit, as long as all the games were still sold through Sony.
Consoles are normally sold either barely breaking even or (more often) at a slight loss. All of the money is made on the games.
Later,
Jerry.
Re:How inclusive is the book?
on
GPU Gems 2
·
· Score: 1
I'd guess around half the code in the book will run directly on other current high-end video cards. Another third (or so) of the techniques apply to other cards, even if the code isn't directly usable on them.
The book also has a chapter written by a couple of guys from Apple summarizing their experiences with making their code work on both ATI and nVidia cards -- if you're interested in supporting both, this chapter alone might justify buying the book.
I think this comes close, but just misses pointing out a few things that are salient here:
1) comments need to be tailored to the audience and the intent of the code. If you're posting code to alt.comp.lang.learn.c-c++ (for one example) it's perfectly resonable to write a lot of comments that would be downright insulting under normal circumstances.
2) Short of getting ridiculous, self-documenting code only documents what it does, not WHY it does that. Comments should usually tell why.
3) IMO, the comment elsethread about commenting interfaces started out well, but then went astray. Commenting an interface is a good thing -- but you should NOT have to tell what the interface does, because if comments contribute to that, the interface has serious problems that need to be fixed. Variable names are the least of writing self-documenting code; good function names and (where applicable) class names are far more important -- the interface itself should make its intent obvious.
Comments on an interface _should_ be used to tell about those things that can't (reasonably) be made apparent otherwise, such as preconditions and limitations on the interface.
Slashdot Mirror
Most CMT simulations (at least that I've seen) have assumed larger caches. Most implementations don't match -- which seems to be a large part of why it's not working nearly as well in real-life as simulations.
Of course, the simulations also often assume a more or less optimal mix of compute- and I/O-bound threads, where improving thread-switching speed helps a lot. Again, real-world loads are rarely so cooperative.
--
The universe is a figment of its own imagination.
I prefer:
#define struct union /* reduce memory usage */
IMO, this fits the original definition more closely as well -- the comment's explanation sounds almost plausible (at least to some people).
--
The universe is a figment of its own imagination.
Yes, it is. For quite a long time, the patent office didn't even accept applications for patents on software, deeming them "nonstatuatory material" (i.e. not patentable), much like mathematical formulae.
The courts struck that down based (largely) on the basis of machinery with embedded processors, saying that the mere fact that a process (for example) happened to be carried out under software control didn't suddenly invalidate the patent. The original case was related to a machine for making tires. The process was patented, and somebody built a machine that did exactly what the patent described, but partly under software control. The court eventually decided that the patent applied anyway, because they couldn't find a meaningful way to differentiate them.
Even so, (at least in the US) technically there aren't patents on software per se anyway -- they patent is on something like a method or process (that might be implemented in software) or an apparatus that does something (again, perhaps under software control), or an "article of manufacture", etc. -- for example, on the CD-ROM containing the software, not on the software itself.
IMO, trying to separate between hardware and software is nearly impossible though -- there are simply too many "corner" cases that make such a separation difficult in either direction. If I pre-program a microcontroller to act exactly like a well-defined (but, for example, obsolete) piece of hardware, why should the fact that internally it's using code in a ROM have anything to do with anything? In the opposite direction, does something like a CPLD or FPGA fall under software or hardware?
That really only leaves two choices: allow patents (even on things that might be implemented partly or entirely in software) or else don't allow patents (at all).
For better or worse, at least in the US, that's not likely to happen anytime soon. First of all, eliminating patents would require a constitutional amendment, which is never easy. Second, a substantial portion of what the US exports is intellectual property, largely in the form of patent licenses. Given the US's trade balance, it seems highly unlikely (at least to me) that anybody's going to seriously contemplate something that would eliminate that entire business in one fell swoop.
--
The universe is a figment of its own imagination.
Hi Tom,
It's been a long time -- good to see you're still around.
I'm not sure which ATI chip set you have, but my laptop has a Mobility Radeon 7000, which definitely does have alpha-blending hardware. Elsethread you mentioned this as a possible driver problem, which may well be right. If you haven't already, it might be worth looking at http://dri.freedesktop.org/wiki/ for one possible source of drivers that might give you better hardware support. I don't have any really ancient hardware handy to test with, but as I said, I definitely get hardware alpha blending at least as far back as the Radeon 7000, which certainly isn't what you'd call particularly new. I haven't had any S3 hardware to test with for quite a while, but the DRI site at least claims to support some of it, and even some really old stuff (for the Virge) that's incomplete supports Alpha blending in hardware anyway.
--
The universe is a figment of its own imagination.
Transparent windows are pretty easy to implement without wasting much in the way of resources. Nearly any reasonably recent graphics card has alpha blending hardware.
There is a little bit of bloat in that you need to use an RGBA format instead of RGB -- but even this is a tradeoff, not a simple loss. It uses more memory, but along with giving you alpha blending, it (usually) speeds up processing in general, because the bits for one pixel fit nicely in a word, over a bus, etc., without constant shifting/rotating/swizzling. In fact, most people I've seen run in 32-bit color modes all the time, even though they almost never use the alpha blending it enables -- and the extra memory involved is on the grapics card anyway.
IOW, yes it uses extra resources -- but the resources it uses would just sit idle otherwise. The resource consumption involved is nearly meaningless unless you're running on something truly ancient that doesn't directly support it in hardware.
--
The universe is a figment of its own imagination.
While I agree that a good book (or three) on algorithms is necessary, this book does not qualify, at least IMO. I would recommend Introduction to Algorithms by Cormen, Leiserson, Rivest and Stein as one of many superior alternatives. It has a few problems as well (mostly excessive formality) but at least it has the information you need. Of course the old standby in this genre is to get all three volumes of Knuth, plus the "fasicles" of volume four that are coming out (supplemented as needed in areas he hasn't covered yet). If you can find a copy of Algorithms + Data Structures = Programs by Niklaus Wirth, it's a very good book as well (though I'm pretty sure it's been out of print for quite a while -- but getting your favorite used book store to search for ISBN 0-12-022418-9 may be worthwhile). As you might expect, this uses Pascal for its examples, but for this kind of book, the specific language used doesn't matter all that much.
If you want more detail about these books (such as why Sedgewick's is utterly worthless) see: http://tinyurl.com/d68kl.
Hmm...oddly enough, I don't have this book, and manage to get by fairly well -- IMO, if you want a book on software engineering, something by Grady Booch or Bertrand Meyer would be a better bet. Somewhere in here there should also be a mention of Structure and Interpretation of Computer Programs -- in fact, it might be the most important and useful of all -- even though it uses Scheme rather than C++.
--
The universe is a figment of its own imagination.
--
The universe is a figment of its own imagination.
While it's theoretically possible that a weapon might be derived from this research someday, but for a moment think about what this is really talking about.
It's a machine that can accelerate a tiny disc of metal very quickly, but only for a short distance, and AFAICT, it's all happening down inside of a big machine so about the biggest thing you could kill with it might be a cockroach.
Right now, as far as killing things goes, it's not a weapon -- it's just a $6+ million bug exterminator!
Hmm...bug extermination for only $6 millon or so. Maybe MS should buy a few dozen!
--
The universe is a figment of its own imagination.
You've modified c three times without any intervening sequence points, which gives undefined behavior. See http://dspace.dial.pipex.com/town/green/gfd34/art/ and click on "bloopers", or just Google for "nasal demons" (honest!)
Also note that if you don't insert spaces yourself, "c+++++c" is NOT tokenized as "c++ + ++c" either -- it's tokenized as "c++ ++" and then lexing will normally stop because what you have is illegal. Google for "maximum munch".
--
The universe is a figment of its own imagination.
See http://www.zetalink.biz/produ.html
--
The universe is a figment of its own imagination.
IMO, you've almost hit on an important point, but then missed it. The Intel compiler is currently available for Windows and Linux -- and it's a fair bet that relatively soon, it'll be available for OS X as well.
At least for portable code, Apple can just use the Intel compiler instead of re-implementing what it does.
--
The universe is a figment of its own imagination.
Yes -- Xilinx and Altera (and probably others as well) will let you download toolkits for free. They allow you to work in Verilog/VHDL or schematics (though most people use the latter primarily to see what the V* has produced).
If you only want one chip, you're probably best off using an FPGA or CPLD. Xilinx has a development kit (using a Digilent board) available for $100US. It has a 200 Kgate Spartan 3, which is plenty to build a variety of CPUs. If you really want to low-ball things, they have a $50US kit with something like a 50 Kgate CPLD. While that should be plenty for something like a Z80, it's still half the price for a quarter the gates...
Of course, Altera has some cheap development kits as well, but at least the last time I looked, their low-end kits didn't look (to me) like nearly as good of deals.
If you really want custom hardware made: well, the cheapest I know of for a one-off chip is around $10K. That's a lot better than the $100+ K just for maskwork to do conventional fabrication, but still way too high for most hobbyists. Below that, you're more or less stuck with an FPGA/CPLD or else hardwiring from individual gates.
Elsethread there was mention of the "big guys" with their Verilog tools not being able to do things like this. While opencores.org certainly isn't Intel, it also certainly has enough IP that putting together something on this order wouldn't really be a particularly huge challenge. They have a number of CPU cores, including some that emulate things like MIPS, so compilers aren't a major problem. Using the Wishbone SoC bus, connecting one of those to their Ethernet core should be fairly simple, and you're already about 90% done. Alternatively, you might want to look at the 10M Ethernet circuitry at fgpa4fun. The Ethernet core on opencores.org is only a MAC (so you'd need a separate PHY), but this outlines an on-chip PHY.
Those who are sufficiently serious that they don't like fpga4fun very well might prefer to look at the FPGA CPU site instead.
As you'd expect from the name, opencores.org is devoted to open source. The IP on the others varies, but IIRC, most of them are open to at least some degree as well.
This begs the question "what Object Oriented Programming theory?"
There is no one all-encompassing theory of object oriented programming, any more than there is one univerally-agreed upon theory of the meaning of life.
Alan Kay seems to disagree with you anyway -- to quote from his HOPL II talk, "OOP is a late binding stategy for many things..." Given his attitude toward parsimony and generality, he clearly would have left out the "for many things" qualification if he considered it possible -- he qualified the statement because the qualification was necessary.
It's only because Stroustrop couldn't get that working when he was writing his semi-OOP preprocessor to C (C++, perhaps you've heard of it) that this key part of OOP started getting ignored.
Nonsense. It would have been substantially simpler to design C++ to use only late binding -- after all, he clearly had late binding working to have virtual functions at all, and once it was working, simply using it consistently would be simpler than using it but also allowing for early binding.
In chapter 1 of The Design and Evolution of C++ Bjarne outlines much of the original motivation for C++, and in doing so points out why late binding for everything would not have fit his goals, one of which was that (what eventually came to be called) C++ would "...produce programs that ran as fast as BCPL programs..." (section 1.1, page 21, for anybody who wants to read more). This became (and continues to be) one of the most fundamental ideas in the design of C++: you shouldn't pay for what you don't use. In this case, it applies very directly: you should only pay the speed penalty for late binding when you also need the flexibilty of late binding.
In addition, early binding allows a more direct expression of a design at a high level than is possible if only late binding is allowed. Specifically, early binding (i.e. a non-virtual function) expresses a class invariant, a concept that is virtually (no pun intended) impossible to express in Simula or Smalltalk, except via comments.
The world doesn't begin and end with what can be done easily in a C derivative language. Take a look at Smalltalk-72 to see what OOP was supposed to be.
The world doesn't begin and end with what can be done easily in an early version of Smalltalk whose design was based less on what was desirable, and more on what would fit into physically small machine using the technology of the early 1970's.
Later, Jerry.
For what little it's worth, the NT codebase has always allowed the programmer to decide whether it should be case sensitive or not -- FILE_FLAG_POSIX_SEMANTICS gets you case-sensitivity.
For better or worse, the standard libraries for most compilers do not pass this flag in their implementations of fopen, ifstream::open, etc., so in most cases you can only get case sensitivity with direct OS calls, not via the standard library.
Sure, it makes life a little easier for lazy compiler writers and it's habit in people who've never bothered to learn any languages not derived from C but the point of a programming language is to make things easier for the human and not the compiler.
Doing case-insensitivity well is substantially more difficult than you suggest. From a purely English-speaking viewpoint, the problem is trivial. From some other viewpoints, it becomes less so. For an obvious example, to me it's obvious that 'b' and 'B' should compare equal to each other -- but to a native Russian speaker, it's equally obvious that they should compare as not equal to each other.
Once there's general agreement about how to do this in general, compilers will most likely implement those agreements, but as long as it's an open question, most compiler writers are (wisely, IMO) leaving it alone.
Other signs of C-blinders are thinking that three-part loop constructs are a good thing, that curly braces are actually either ergonomic or intuitive or that semicolons are how you end sentences;
Ending statements with semi-colons is hardly unique to C -- and given the number of purposes for which the period is already used, the semicolon is a relatively easy choice.
Presumably your mention of three-part loop construct is looking at C's for-loop. While it undoubtedly isn't anywhere close to perfect, it's still an awful lot closer than most of the alternatives. Just for a couple of examples, Pascal's was so limited it was useless for anything but the very simplest of loops. PL/I supported more of the flexibility allowed in C, but degenerated into unreadability for any but the most trivial of loops. Just for example, try to figure out what sequence of values is iterated through with this:
Granted, it's possible to do so with a bit of work, but it can be decidedly non-trivial -- and in fact, it's fairly easy to write self-conflicting conditions, so you need to know a lot about expression evaluation to be sure what will happen under some circumstances.
That, of course, brings up the next big problem: in quite a few languages, loop conditions are unique unto themselves, with different rules both for syntax and semantics than the equivalent written elsewhere -- so the programmer has to learn two or even three sets of (inevitably conflicting) rules about how to do essentially the same things. While the C programmer may need to learn a bit more up-front, once it's learned it can be applied throughout.
Those of use who've been around long enough to be sure we don't wear "C blinders" (I.e. we started programming long before C came along) can remember all sorts of other...interesting things in some languages. Just for a couple of examples, consider:
in Fortran. Now if that was: do 10 i = 1,10 it would be a do loop, equivalent to "for i = 1 to 10" in BASIC. Unfortunately, the simple typo of replacing the comma with a decimal point changes it entirely. In fact, it's a simple assignment of 1.10 to a variable named 'do 10 i' with is perfectly legal and legitimate, but enough to make temporarily reduce nearly anbody's sanity level.
For another example, let's look at:
in PL/I. To most people, this looks l
First of all, releasing data on the CPU is nowhere close to enough for anybody to even think about cloning the console.
Second, if somebody did start cloning and selling consoles, Sony probably wouldn't mind a bit, as long as all the games were still sold through Sony.
Consoles are normally sold either barely breaking even or (more often) at a slight loss. All of the money is made on the games.
Later, Jerry.
The book also has a chapter written by a couple of guys from Apple summarizing their experiences with making their code work on both ATI and nVidia cards -- if you're interested in supporting both, this chapter alone might justify buying the book.
This looks to me a lot like substituting comments for good coding. I'd rather see something like:
I think this comes close, but just misses pointing out a few things that are salient here: 1) comments need to be tailored to the audience and the intent of the code. If you're posting code to alt.comp.lang.learn.c-c++ (for one example) it's perfectly resonable to write a lot of comments that would be downright insulting under normal circumstances. 2) Short of getting ridiculous, self-documenting code only documents what it does, not WHY it does that. Comments should usually tell why. 3) IMO, the comment elsethread about commenting interfaces started out well, but then went astray. Commenting an interface is a good thing -- but you should NOT have to tell what the interface does, because if comments contribute to that, the interface has serious problems that need to be fixed. Variable names are the least of writing self-documenting code; good function names and (where applicable) class names are far more important -- the interface itself should make its intent obvious. Comments on an interface _should_ be used to tell about those things that can't (reasonably) be made apparent otherwise, such as preconditions and limitations on the interface.