people lined up at your doorstep throwing wads of $50's at your head for that exact same program - even though you haven't written a single line of code since - you're going to say "No, no, folks - keep your money! I shouldn't expect to keep getting money for something that's two years old!
That is the "finite virtue fallacy". It supposes that a person with even a minor mortal failing has no right to comment on what is good or bad.
Simply because someone profits from an existing system does not prohibit him from arguing against the same system. For example, the CEO of Amazon.com believes that software patents are wrong, but as long as they remain legal, his corporate duty is to continue profiting from them. It might be nice if everyone could afford to sacrifice themselves for their principles, but it's unreasonable to demand that as a baseline.
Rarely. Once your PC works fine, it probably won't develop problems unless you add hardware or do something boneheaded.
Boneheaded? Such as install a 2006 game, for example?
Just like Toyotas are cheaper that Ferraris. And for pretty much the same reasons.
Comparing PC gaming to a Ferrari does disservice to the PC game market.
Ferraris are a failure as a car, just like the Space Shuttle is a failure as an airplane. Certainly, it is drastically better on several obvious metrics, but the relatively low importance of those measures on which it excells means that the benefit doesn't come close to outweighing the cost.
So why don't PC game publishers let me split my 1280x720 pixel HDTV into four 640x360 windows for four players, all controlled by the same PC?
Hopefully the answer is obvious: there is zero customer demand.
Notice that you only pointed out Nintendo titles for your examples. Consider some non-splitscreen, single-player Nintendo fare, and try to come up with PC equivalents. You can't do it- there's nothing similar to Paper Mario, Metroid, Zelda, or even Resident Evil4.
There is minimal intersection between the people who'd drop even $1,000 on a gaming PC and those who'd enjoy a splitscreen game. You are apparently an oddball consumer. It is a little unfortunate but unsurprising that publishers won't cater to you personally.
Most of those things are done better by offline games. Although some games fall short, those aspects could be improved much quicker and easier in an offline game, if there was much demand for it.
Horrors! I've been playing an on-line game like I'd have played it if it were off-line. My god - where are the police when you need them?
It's not the police we should be looking for, but the Invisible Hand of economic efficiency.
By playing an online game as if it were offline, you are paying a lot of money for something you know you'll use only a little of. Instead of $50 + $15/month, you could have a solo game for $30.
Just look at the amount of effort that's put in. The majority of the design, programming, and testing effort goes into things that are irrelevant to you. (Balance between players? Network lag? Client-side cheating? That's irrelevant for an offline game). There's a whole major category of network infrastructure that you're paying for, but deriving little benefit from.
When I think of an MMORPG which uses the D&D brand, I'd expect it to use one of these iconic D&D settings
They are trying to force Eberron into becoming an iconic setting, by fiat. Eberron is now the "default world" for all the core D&D books.
So, D&D Online isn't making the mistake here... they are just following the misbegoten changes of the root franchise. (For those who haven't seen it, the main feature making Eberron inappropriate for the default D&D gameworld is that robots are available as ordinary PCs)
Planescape would really be a better setting... it would make the high availability of teleporters and miraculous ressurections.
I'm NOT a gigantic fan of grouping. I play MMOs for the unpredictability, the variety of content, NOT to make new friends and gain social interaction.
Then you'd be better off with a large-scale offline RPG. Seriously, if a player doesn't want to interact with a bunch of strangers / distant friends, why is the $15/month justified? $30 for NWN-Gold will open you up to a LOT of downloadable modules... on top of the included gameworld which is bigger than the existing WOW and DDO realms.
- Woohoo - I'm a wizard, I get 2 spells and then I might as well logoff for the day? How does that work in a realtime world?
You are correct in that those game aspects have to be totally changed to work well in an MMO (which implies that all the other rules are now unbalanced by a domino effect).
Two main changes alleviate that concern: 1. Mana point system. A beginning spellcaster has 150 points, and level 1 spells (combat stuff like burning hands) are 20 points. Means basically 7x the firepower. 2. It doesn't take 24 or even 12 hours to get the next "day's" spell allotment. Just find a designated resting bench, watch a progress bar for 30 sec or so, and it's carpe diem time. In a way, one can imagine that time has just been compressed, and that players off in instances are experiencing a faster timeflow than the rest of the world (like a reverse-version of FTL relativity)
Deaths: in MMOs, deaths are frequent and annoying but in PnP D&D
As one might expect, deaths are treated about the same as any other MMORPG (or classic MUD). They're at worst a time-wasting inconvenience and a forced trip back to the town. Maybe in a particularly hardcore game, you'll even lose some XP or item durability. DDO is no different. (And also as usual, the "raise dead" spell of high-ranking clerics essentially just removes that very marginal penalty)
At the same time, rational people also realize that nobody will ever invest the billions of dollars necessary in the sort of meaningful driver education on a skidpad and through static exercises.
This could be easily achieved to a decent extent with a simple governmental ban on using gamepads to steer in software like GTA:VC and Gran Turismo. With a legislative requirement to use racing wheels (and moderately accurate vehicle physics), the majority of males 18-35 will quickly learn to react to all kinds of high-speed emergencies.
Go ahead and read the ABS Q&A you linked: it says that on-average, ABS does reduce stopping distance. (Whether or not that was the main intention of the designers is beside the point)
Though I don't think ABS makes the stopping distance longer
Once again, read the Q&A and see that it sometimes does lengthen it. Hypothetically, a person who knew exactly what conditions to expect might prefer to occasionally turn it off.
if cars ever become fully automated, Minority Report style, we will have a lot less car accidents
But those accidents will be more lethal, because one little deviation will send you soaring off the side of the skyscraper, knocking off other cars in a terrifying chain-reaction.
So maybe they just had to do the plane-drawing algorithm in machine code. That's still tremendously difficult.
Absolutely not. Those games use OpenGL (or maybe sometimes directx). Even in 98, it was common for graphics-oriented courses to use OpenGL (often on real SGI hardware, though). Today, drawing 3d pixels in your own code isn't only excessively difficult, but can't possibly give as impressive a result as a cheap $29 3d accelerator card.
That sounded cool until I saw the 2nd game listed... It uses ripped sprites.
It is commonplace for game designers and programmers to rip art from older projects (their own, or commercially produced) while they are experimenting with gameplay and programming concepts. These people don't want to become artists, and the experiment is not about finding faster ways to draw cool pictures.
Ripping sprites is nothing to be ashamed of in this context.
To expect someone who enjoys something to know about it, and to know most of it, before enrolling?
Computer Science is not programming. CS courses do not teach you programming (except prehaps in a minor, remedial way).
CS/SE people consider programming to be so trivially easy that any good grad can learn another language in an intense weekend. When a prof says "Assignments for this course will be submitted in Haskell", you don't get to ask him to teach Haskell, or even what it is... you'd better be able to understand it on your own.
To expect someone who enjoys something to know about it, and to know most of it, before enrolling?
We'd also expect someone who enjoys English literature to know most of the English language before enrolling.
Then really there is no point to school if you are going in knowing all of the information.
Yes, it is true that if you only want to do programming, then a CS degree isn't for you. In the same vein, prospective car mechanics and plumbers don't need degrees in mechanical / hydraulic engineering.
On the SWG I played there was one crafter player who made good stuff for an good price. She was also easy to sell to offering an okay price with no hassle and not always demanding you rattle of every stat.
This demonstrates why a "player-run economy" is generally a bad idea (except in games that are supposed to be primarily focused on financial competition).
You (and many other players) used that PC like a vending machine. You put in money for the daily buffs you needed to play effectively, and then left to do your missions without her. Even though your interactions were brief, they were crucial, and when she left that grind you had nowhere else to turn.
Everything she provided could been done better by an NPC (or equivalently, a GM running a character). There's no good game design reason why the enjoyment of one paying customer should be conditional on the activities of some other customer who isn't even in the same party/guild/faction.
It seems that designers are gradually learning that the goal of building an "authentic" interacting simulationist world should be secondary to providing reliably fun play sessions. The increasing use of instancing supports this, but they'll still make more false starts before really taking it to heart.
Last I checked, this term is reserved for those game systems that sit by your TV.
Actually no, you've never checked, because there is nothing relating to "games" anywhere in the definition of console. Computer consoles have existed long before Nintendo or even Atari had an electronic product.
The definition, btw: "The portion of a computer or peripheral that houses the apparatus used to operate the machine manually and provides a means of communication between the computer operator and the central processing unit"
Typically, ignoramuses who have never heard of any kind of console aside from a "game console" will make an unjustified abbreviation, which is similar to how people who've never heard of any kind of "emulator" besides a "hardware emulator" go and say "Wine Is Not An Emulator".
If you don't like a particular installment of your favorite sci-fi/fantasy series, nothing lost.
Something's lost. The value of the original is diluted by low-quality extensions, especially under a copyright regime where the follow-on products are required to have been authorized by the original creator.
It has just become more difficult to convince someone that Bloodrayne is an entertaining and worthwhile action video-game, because the movie will have left such a bad impression on so many minds.
In a similar way, Matrix: Reloaded and Star Wars Ep1 retroactively harmed the earlier films.
More material is always good.
There is a finite amount of investment capital in the world. Spending money on stupid projects that are unlikely to benefit anyone is not "always good", because it means that more useful ideas are going unpursued.
I wouldn't advise anyone to run a mutual fund that invests in lotto tickets... but they're more likely to win Powerball than Uwe is to make a good movie.
The problem here is that as any fan of Star Wars would know, all of the stormtroopers are subserviant clones of Jango Fett and therefore property of the Empire.
Impossible. A Star Wars fan, by definition, could not have sat through Episode 1, or seen any of II or III at all.
Since all stormtroopers are clones of the same person, they would all be the same height.
Plenty of official Lucas-branded media prior to the release of Episode 2 explicitly said that Stormtroopers were recruited from the normal population.
Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller.
The fact that you even need to be aware of that consequence demonstrates a failing of the language. One of the intractable theoretical problems of C++ is that the programmer's choices in how she describes a concept are so coupled to the efficiency of the eventual machine code.
Ideally, you could program in a manner that provides the most understandable and modifable (ie, well-factored) implementation of the behavior, and leave low-level tuning of size/speed up to the compiler (possibly with hints in compiler switches or pragmas).
C++ doesn't nearly approach that ideal. You have 2 main languages mechanisms for writing generic functions: either virtual inheritance, or template functions. Those methods differ not only in the scope of applicable problems (only one can work on native types or 3rd-party classes), but also in how the outputted machine code will be structured. Inheritance means more CPU usage and some storage overhead, while templates mean code bloat (which can also be a speed drag, if it blows the cache).
With a good language, a library implementor would be able to decide on the look of the API without forcing such far-ranging consequences on the final executable. Sadly, the backwards-compatibility of the C++ build process means it can never be that good.
(Of course, the above problem isn't solvable in general, but I'm talking about a few specific and well-known tradeoffs)
and there's far less scope for deep optimisations without the exact type knowledge you have with templates,
The type knowledge isn't necessarily different. If the compiler were able to consider all source files when producing an executable (rather than producing multiple object files at intermediate stages) then it would have equal type knowledge with both approaches. The reason template code gets exact types even with current non-global compilers is that the programmer has had to manually specify what & where instantiations are needed.
a regular dictionary isn't always a reliable source when you're defining technical terms.
In the technical terminology of Computer Science, an emulator is some system which intentionally behaves like some other system. From a technical perspective, it doesn't matter at all if you are emulating hardware or software... conceptually, it's all the same thing.
The people who argue "Wine is not an emulator" are incorrectly using "emulator" as an abbreviation "hardware emulator", since that was the first place they heard of "emulator" programs.
That's similar to how some people act like "console" means a video-game machine, when really there are many other kinds of consoles.
An emulator is a replimentation, but it is not a mere reimplimentation of something. They are reimplimentations at different levels.
Funny how that is nowhere in the definition of "emulator", either in standard English, or the Computer Science / Software Engineering specialities.
So, you whole position depends on a factoid summoned from your personal authority...
If Wine weren't emulating Microsoft Windows, then whenever Windows was found to have a bug not mandated by Microsoft's published specifications, they wouldn't go ahead and copy it.
Normally it's with parts of hardware mimicked by software.
So what you're saying is that a "software emulator" is by definition impossible, and that "hardware emulator" is a redundant phrase. Alrighty then.
Thus it looks like this: printf("%s", someObject.toString().c_str())
To many programmers, the need to use those additional 16 characters everyplace you print something is itself symptomatic of a problem, and cout is valued for alleviating it.
So reentrancy isn't a problem. Dynamic memory still is
If you're willing to make toString non-reentrant, it has a much lesser need to use dynamic memory (especially if it returns a char* instead of a str::string, which you'd want to do anyhow if speed was important)
the primary factor that keeps insects from growing much larger than they do here on earth, is the oxygen level
There are other factors, and one was actually discovered back in the Renaissance. That is, muscular strength increases with height squared, but body weight increases with height cubed.
Take a 1 cm ant which can lift 25 times its own weight (as is typical). If it magically grew to 10 cm long, it could only carry itself plus 1.5 other ants. (Compare how little ants carry around leaves bigger than they are, while large dung beetles can barely roll a ball of around their own weight) And if it expands to a full meter long, it could only lift 1/4 of it's weight, making it totally immobile.
had a bit of BASIC experience before moving to C++, and cout is a lot closer to PRINT than printf is (somewhat ironically given the names),
C++0x will finally bring the long-awaitedoperator" "() feature into C++, so the next version of cout will look even more like the old BASIC PRINT. No more << between variables; just type them out one after another.
I don't think the committee has decided if operator() will be replaced with operator" "() or operator,() yet, though. They've already rejected operator""(), which is a shameful lack of vision.
never worked out for me that I could derive from a class and override its functions without having an intimate knowledge of how the base class worked. The 'has-a' relationship seems much better if you want to treat the base class like a black box
Doesn't work. In normal times, when Child is-a Parent, then Foo(Parent*) can be passed either a Child or Parent and operate on it transparently.
For use with printf, you create something like string MyClass::toString(). For cout, you create an operator<< with the right types. The big advantage of cout here is that its interface is part of the standard, so if a class implements it you don't have to guess its name.
cout has multiple speed advantages over printf. First, cout is overall more amenable to optimization, because the compiler knows the types from the typesystem, rather than the program parsing a formatter string at runtime. Second, any toString function you write will probably use a hefty bit of dynamic memory, or be non-reentrant.
Even so, the syntax of printf is nicely more compact, and the speed is not hugely important, so one may wish for a "C++ aware" printf. Such a function could work by adding an additional format specifier (say %P), which indicates that the argument is a pointer to a class derived from PrintfCompatible. PrintfCompatible would have a single pure virtual toString function.
With that in place, you could freely say
printf("My personal fav object is %P\n", &favorite); no matter what kind of class you had written.
If you're using gcc and -Werror, then printf() is actually pretty type safe. Gcc understands printf syntax and can check the arguments
That goes back to Bjarne's goal of providing user-created systems the same power as native language features. If you write your own class highly resembling cout, it will enjoy all the typechecking the official cout does. But implement your own printf analog, and gcc won't know to check the format string for type information.
(Hypothetically, a compiler could be smart enough to statically analyze the code to my_printf and notice that a "%c" in the string means that the input needs to be safely usable as a char, but that'd be highly ambitious)
[then an assertation] You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.
A good compiler can validate many assertions before runtime. There's no reason assert(0) couldn't be flagged by a compiler, and other situations evaluating to assert(0) can be caught by static analysis as well.
Of course, due to the requirement to be backwards-compatible with the C build system, real C++ compilers are rarely good enough to make these fairly easy checks.
operators were pretty much invented for programming. +, *, etc.
In my kindergarten * meant "peek down at the bottom of the page"..
Slashdot Mirror
people lined up at your doorstep throwing wads of $50's at your head for that exact same program - even though you haven't written a single line of code since - you're going to say "No, no, folks - keep your money! I shouldn't expect to keep getting money for something that's two years old!
That is the "finite virtue fallacy". It supposes that a person with even a minor mortal failing has no right to comment on what is good or bad.
Simply because someone profits from an existing system does not prohibit him from arguing against the same system. For example, the CEO of Amazon.com believes that software patents are wrong, but as long as they remain legal, his corporate duty is to continue profiting from them. It might be nice if everyone could afford to sacrifice themselves for their principles, but it's unreasonable to demand that as a baseline.
Rarely. Once your PC works fine, it probably won't develop problems unless you add hardware or do something boneheaded.
Boneheaded? Such as install a 2006 game, for example?
Just like Toyotas are cheaper that Ferraris. And for pretty much the same reasons.
Comparing PC gaming to a Ferrari does disservice to the PC game market.
Ferraris are a failure as a car, just like the Space Shuttle is a failure as an airplane. Certainly, it is drastically better on several obvious metrics, but the relatively low importance of those measures on which it excells means that the benefit doesn't come close to outweighing the cost.
So why don't PC game publishers let me split my 1280x720 pixel HDTV into four 640x360 windows for four players, all controlled by the same PC?
Hopefully the answer is obvious: there is zero customer demand.
Notice that you only pointed out Nintendo titles for your examples. Consider some non-splitscreen, single-player Nintendo fare, and try to come up with PC equivalents. You can't do it- there's nothing similar to Paper Mario, Metroid, Zelda, or even Resident Evil4.
There is minimal intersection between the people who'd drop even $1,000 on a gaming PC and those who'd enjoy a splitscreen game. You are apparently an oddball consumer. It is a little unfortunate but unsurprising that publishers won't cater to you personally.
4) The story line is compelling
Most of those things are done better by offline games. Although some games fall short, those aspects could be improved much quicker and easier in an offline game, if there was much demand for it.
Horrors! I've been playing an on-line game like I'd have played it if it were off-line. My god - where are the police when you need them?
It's not the police we should be looking for, but the Invisible Hand of economic efficiency.
By playing an online game as if it were offline, you are paying a lot of money for something you know you'll use only a little of. Instead of $50 + $15/month, you could have a solo game for $30.
Just look at the amount of effort that's put in. The majority of the design, programming, and testing effort goes into things that are irrelevant to you. (Balance between players? Network lag? Client-side cheating? That's irrelevant for an offline game). There's a whole major category of network infrastructure that you're paying for, but deriving little benefit from.
When I think of an MMORPG which uses the D&D brand, I'd expect it to use one of these iconic D&D settings
They are trying to force Eberron into becoming an iconic setting, by fiat. Eberron is now the "default world" for all the core D&D books.
So, D&D Online isn't making the mistake here... they are just following the misbegoten changes of the root franchise. (For those who haven't seen it, the main feature making Eberron inappropriate for the default D&D gameworld is that robots are available as ordinary PCs)
Planescape would really be a better setting... it would make the high availability of teleporters and miraculous ressurections.
I'm NOT a gigantic fan of grouping. I play MMOs for the unpredictability, the variety of content, NOT to make new friends and gain social interaction.
Then you'd be better off with a large-scale offline RPG. Seriously, if a player doesn't want to interact with a bunch of strangers / distant friends, why is the $15/month justified? $30 for NWN-Gold will open you up to a LOT of downloadable modules... on top of the included gameworld which is bigger than the existing WOW and DDO realms.
- Woohoo - I'm a wizard, I get 2 spells and then I might as well logoff for the day? How does that work in a realtime world?
You are correct in that those game aspects have to be totally changed to work well in an MMO (which implies that all the other rules are now unbalanced by a domino effect).
Two main changes alleviate that concern:
1. Mana point system. A beginning spellcaster has 150 points, and level 1 spells (combat stuff like burning hands) are 20 points. Means basically 7x the firepower.
2. It doesn't take 24 or even 12 hours to get the next "day's" spell allotment. Just find a designated resting bench, watch a progress bar for 30 sec or so, and it's carpe diem time. In a way, one can imagine that time has just been compressed, and that players off in instances are experiencing a faster timeflow than the rest of the world (like a reverse-version of FTL relativity)
Deaths: in MMOs, deaths are frequent and annoying but in PnP D&D
As one might expect, deaths are treated about the same as any other MMORPG (or classic MUD). They're at worst a time-wasting inconvenience and a forced trip back to the town. Maybe in a particularly hardcore game, you'll even lose some XP or item durability. DDO is no different. (And also as usual, the "raise dead" spell of high-ranking clerics essentially just removes that very marginal penalty)
At the same time, rational people also realize that nobody will ever invest the billions of dollars necessary in the sort of meaningful driver education on a skidpad and through static exercises.
This could be easily achieved to a decent extent with a simple governmental ban on using gamepads to steer in software like GTA:VC and Gran Turismo. With a legislative requirement to use racing wheels (and moderately accurate vehicle physics), the majority of males 18-35 will quickly learn to react to all kinds of high-speed emergencies.
ABS is not designed to make the car stop faster.
Go ahead and read the ABS Q&A you linked: it says that on-average, ABS does reduce stopping distance. (Whether or not that was the main intention of the designers is beside the point)
Though I don't think ABS makes the stopping distance longer
Once again, read the Q&A and see that it sometimes does lengthen it. Hypothetically, a person who knew exactly what conditions to expect might prefer to occasionally turn it off.
if cars ever become fully automated, Minority Report style, we will have a lot less car accidents
But those accidents will be more lethal, because one little deviation will send you soaring off the side of the skyscraper, knocking off other cars in a terrifying chain-reaction.
So maybe they just had to do the plane-drawing algorithm in machine code. That's still tremendously difficult.
Absolutely not. Those games use OpenGL (or maybe sometimes directx). Even in 98, it was common for graphics-oriented courses to use OpenGL (often on real SGI hardware, though). Today, drawing 3d pixels in your own code isn't only excessively difficult, but can't possibly give as impressive a result as a cheap $29 3d accelerator card.
That sounded cool until I saw the 2nd game listed... It uses ripped sprites.
It is commonplace for game designers and programmers to rip art from older projects (their own, or commercially produced) while they are experimenting with gameplay and programming concepts. These people don't want to become artists, and the experiment is not about finding faster ways to draw cool pictures.
Ripping sprites is nothing to be ashamed of in this context.
To expect someone who enjoys something to know about it, and to know most of it, before enrolling?
Computer Science is not programming. CS courses do not teach you programming (except prehaps in a minor, remedial way).
CS/SE people consider programming to be so trivially easy that any good grad can learn another language in an intense weekend. When a prof says "Assignments for this course will be submitted in Haskell", you don't get to ask him to teach Haskell, or even what it is... you'd better be able to understand it on your own.
To expect someone who enjoys something to know about it, and to know most of it, before enrolling?
We'd also expect someone who enjoys English literature to know most of the English language before enrolling.
Then really there is no point to school if you are going in knowing all of the information.
Yes, it is true that if you only want to do programming, then a CS degree isn't for you. In the same vein, prospective car mechanics and plumbers don't need degrees in mechanical / hydraulic engineering.
On the SWG I played there was one crafter player who made good stuff for an good price. She was also easy to sell to offering an okay price with no hassle and not always demanding you rattle of every stat.
This demonstrates why a "player-run economy" is generally a bad idea (except in games that are supposed to be primarily focused on financial competition).
You (and many other players) used that PC like a vending machine. You put in money for the daily buffs you needed to play effectively, and then left to do your missions without her. Even though your interactions were brief, they were crucial, and when she left that grind you had nowhere else to turn.
Everything she provided could been done better by an NPC (or equivalently, a GM running a character). There's no good game design reason why the enjoyment of one paying customer should be conditional on the activities of some other customer who isn't even in the same party/guild/faction.
It seems that designers are gradually learning that the goal of building an "authentic" interacting simulationist world should be secondary to providing reliably fun play sessions. The increasing use of instancing supports this, but they'll still make more false starts before really taking it to heart.
Last I checked, this term is reserved for those game systems that sit by your TV.
Actually no, you've never checked, because there is nothing relating to "games" anywhere in the definition of console. Computer consoles have existed long before Nintendo or even Atari had an electronic product.
The definition, btw: "The portion of a computer or peripheral that houses the apparatus used to operate the machine manually and provides a means of communication between the computer operator and the central processing unit"
Typically, ignoramuses who have never heard of any kind of console aside from a "game console" will make an unjustified abbreviation, which is similar to how people who've never heard of any kind of "emulator" besides a "hardware emulator" go and say "Wine Is Not An Emulator".
If you don't like a particular installment of your favorite sci-fi/fantasy series, nothing lost.
Something's lost. The value of the original is diluted by low-quality extensions, especially under a copyright regime where the follow-on products are required to have been authorized by the original creator.
It has just become more difficult to convince someone that Bloodrayne is an entertaining and worthwhile action video-game, because the movie will have left such a bad impression on so many minds.
In a similar way, Matrix: Reloaded and Star Wars Ep1 retroactively harmed the earlier films.
More material is always good.
There is a finite amount of investment capital in the world. Spending money on stupid projects that are unlikely to benefit anyone is not "always good", because it means that more useful ideas are going unpursued.
I wouldn't advise anyone to run a mutual fund that invests in lotto tickets... but they're more likely to win Powerball than Uwe is to make a good movie.
The problem here is that as any fan of Star Wars would know, all of the stormtroopers are subserviant clones of Jango Fett and therefore property of the Empire.
Impossible. A Star Wars fan, by definition, could not have sat through Episode 1, or seen any of II or III at all.
Since all stormtroopers are clones of the same person, they would all be the same height.
Plenty of official Lucas-branded media prior to the release of Episode 2 explicitly said that Stormtroopers were recruited from the normal population.
Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller.
The fact that you even need to be aware of that consequence demonstrates a failing of the language. One of the intractable theoretical problems of C++ is that the programmer's choices in how she describes a concept are so coupled to the efficiency of the eventual machine code.
Ideally, you could program in a manner that provides the most understandable and modifable (ie, well-factored) implementation of the behavior, and leave low-level tuning of size/speed up to the compiler (possibly with hints in compiler switches or pragmas).
C++ doesn't nearly approach that ideal. You have 2 main languages mechanisms for writing generic functions: either virtual inheritance, or template functions. Those methods differ not only in the scope of applicable problems (only one can work on native types or 3rd-party classes), but also in how the outputted machine code will be structured. Inheritance means more CPU usage and some storage overhead, while templates mean code bloat (which can also be a speed drag, if it blows the cache).
With a good language, a library implementor would be able to decide on the look of the API without forcing such far-ranging consequences on the final executable. Sadly, the backwards-compatibility of the C++ build process means it can never be that good.
(Of course, the above problem isn't solvable in general, but I'm talking about a few specific and well-known tradeoffs)
and there's far less scope for deep optimisations without the exact type knowledge you have with templates,
The type knowledge isn't necessarily different. If the compiler were able to consider all source files when producing an executable (rather than producing multiple object files at intermediate stages) then it would have equal type knowledge with both approaches. The reason template code gets exact types even with current non-global compilers is that the programmer has had to manually specify what & where instantiations are needed.
Molestation is not a capital offense, therefore bail cannot be refused.
That's a complete non-sequitor. Bail is possible in capital cases, and can be denied for non-capital offenses too.
a regular dictionary isn't always a reliable source when you're defining technical terms.
In the technical terminology of Computer Science, an emulator is some system which intentionally behaves like some other system. From a technical perspective, it doesn't matter at all if you are emulating hardware or software... conceptually, it's all the same thing.
The people who argue "Wine is not an emulator" are incorrectly using "emulator" as an abbreviation "hardware emulator", since that was the first place they heard of "emulator" programs.
That's similar to how some people act like "console" means a video-game machine, when really there are many other kinds of consoles.
An emulator is a replimentation, but it is not a mere reimplimentation of something. They are reimplimentations at different levels.
Funny how that is nowhere in the definition of "emulator", either in standard English, or the Computer Science / Software Engineering specialities.
So, you whole position depends on a factoid summoned from your personal authority...
If Wine weren't emulating Microsoft Windows, then whenever Windows was found to have a bug not mandated by Microsoft's published specifications, they wouldn't go ahead and copy it.
Normally it's with parts of hardware mimicked by software.
So what you're saying is that a "software emulator" is by definition impossible, and that "hardware emulator" is a redundant phrase. Alrighty then.
Thus it looks like this: printf("%s", someObject.toString().c_str())
To many programmers, the need to use those additional 16 characters everyplace you print something is itself symptomatic of a problem, and cout is valued for alleviating it.
So reentrancy isn't a problem. Dynamic memory still is
If you're willing to make toString non-reentrant, it has a much lesser need to use dynamic memory (especially if it returns a char* instead of a str::string, which you'd want to do anyhow if speed was important)
the primary factor that keeps insects from growing much larger than they do here on earth, is the oxygen level
There are other factors, and one was actually discovered back in the Renaissance. That is, muscular strength increases with height squared, but body weight increases with height cubed.
Take a 1 cm ant which can lift 25 times its own weight (as is typical). If it magically grew to 10 cm long, it could only carry itself plus 1.5 other ants. (Compare how little ants carry around leaves bigger than they are, while large dung beetles can barely roll a ball of around their own weight) And if it expands to a full meter long, it could only lift 1/4 of it's weight, making it totally immobile.
had a bit of BASIC experience before moving to C++, and cout is a lot closer to PRINT than printf is (somewhat ironically given the names),
C++0x will finally bring the long-awaited operator" "() feature into C++, so the next version of cout will look even more like the old BASIC PRINT. No more << between variables; just type them out one after another.
I don't think the committee has decided if operator() will be replaced with operator" "() or operator,() yet, though. They've already rejected operator""(), which is a shameful lack of vision.
never worked out for me that I could derive from a class and override its functions without having an intimate knowledge of how the base class worked. The 'has-a' relationship seems much better if you want to treat the base class like a black box
Doesn't work. In normal times, when Child is-a Parent, then Foo(Parent*) can be passed either a Child or Parent and operate on it transparently.
For use with printf, you create something like string MyClass::toString(). For cout, you create an operator<< with the right types. The big advantage of cout here is that its interface is part of the standard, so if a class implements it you don't have to guess its name.
cout has multiple speed advantages over printf. First, cout is overall more amenable to optimization, because the compiler knows the types from the typesystem, rather than the program parsing a formatter string at runtime. Second, any toString function you write will probably use a hefty bit of dynamic memory, or be non-reentrant.
Even so, the syntax of printf is nicely more compact, and the speed is not hugely important, so one may wish for a "C++ aware" printf. Such a function could work by adding an additional format specifier (say %P), which indicates that the argument is a pointer to a class derived from PrintfCompatible. PrintfCompatible would have a single pure virtual toString function.
With that in place, you could freely say
printf("My personal fav object is %P\n", &favorite);
no matter what kind of class you had written.
If you're using gcc and -Werror, then printf() is actually pretty type safe. Gcc understands printf syntax and can check the arguments
That goes back to Bjarne's goal of providing user-created systems the same power as native language features. If you write your own class highly resembling cout, it will enjoy all the typechecking the official cout does. But implement your own printf analog, and gcc won't know to check the format string for type information.
(Hypothetically, a compiler could be smart enough to statically analyze the code to my_printf and notice that a "%c" in the string means that the input needs to be safely usable as a char, but that'd be highly ambitious)
[then an assertation] You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.
A good compiler can validate many assertions before runtime. There's no reason assert(0) couldn't be flagged by a compiler, and other situations evaluating to assert(0) can be caught by static analysis as well.
Of course, due to the requirement to be backwards-compatible with the C build system, real C++ compilers are rarely good enough to make these fairly easy checks.
operators were pretty much invented for programming. +, *, etc.
In my kindergarten * meant "peek down at the bottom of the page"..