E.g. adding strings and complex numbers both have obvious expected meanings. Writing to a stream is nothing like shifting
Shifting is nothing like being incomprably smaller than another number.... but that's what "<<" means. (And furthermore, multiplication is unrelated to footnoting)
But the first case would in fact be extremely simple to implement:
Actually, it's exactly as difficult as the second case. I gave the same problem twice in different guises. You can't be sure that ++ really means to add 1. There could be an overloaded operator++ involved, and it might do absolutely anything. In light of that possibility, the concerns are exactly the same as when a non-const reference is passed to an arbitrary function.
Luckily, languages implementing properties don't have that kind of insanity, so the issue is moot.
Since the topic was a proposal to add "property" to C++, it certainly wasn't moot.
(Final note: calling C++ "elaborate" may be going a bit too far, Smalltalk, Ruby or Python seem much more "elaborate" to me.)
I intentionally chose to call it "elaborate" because although there are languages which are more powerful and flexible, C++ has more explicitly different features in its specification (instead of allowing more of the features to be a natural consequence of fundamental capabilities). Inheritance, templates, operator-overloading, and exceptions don't flow naturally out of the primitive structures; they are all separate features.
I was particularly thinking of the functional languages like Lisp, which have more expressive power than C++, and from smaller language definitions.
I'll agree that Perl and ADA are possibly more elaborate than C++ (depending on how you measure).
IMHO that's rather unfair. When Visual C++ 6 was released,
The fair complaint is that Microsoft waited more than 7 years between compiler releases. VC6 was justly maligned by people stuck using it into the 200Xs. There was no reason several simplistic compiler changes couldn't have been issued prior to the full VC7 rollout.
AC: 1. C++ IS a superset of C. C came up short in certain areas. C++ tried to fix that and from TFA it is still evolving.
Back when C++ was first released, "int virtual;" was a valid declaration in C. But of course, that variable name is illegal in C++. Therefore since we've seen at least one sample where valid C code doesn't work in C++, C++ is not a superset. (There are also more substantial ways it is not a superset, which I won't detail)
More generally, no language which introduces a new keyword is a superset of the older language, because it breaks those programs which already used that keyword as a custom identifier.
Also, you can avoid the NULL case (which is a giant hole in preventing runtime errors) by passing by value or reference only.
How do you think NULL is a weakness? The inability of C++'s references to be set to Null (like a Java reference can) is one of the biggest reasons C++ programs muse use so many pointers instead of references.
Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java
That sounds very suspicious. C++ references cannot substitute for either Java references or C++ pointers. To fill those roles, they need to be reseatable, and be able to have a NULL value. (Which is equivalent to OPTION datatypes in some functional languages... the ability to talk about a value which might not be present is semantically important)
your favorite code completition mechanism shows the identifiers you may write behind the dot. But: what comes then? Some ( and ) as in a method? Or nothing as in a property?
File a bug report on your IDE. It already parsed the class definition to know what the member variables are named, so it should also know if they are properties or methods, and be able to insert any needed parentheses on its own.
And in doing so, violates just about every sane property of every other container type in the language.
The reason it must do that (as you probably know) is because the CPU's pointers are not capable of addressing individual bits. Addresses can only point to whole bytes.
Interestingly, this means that the choice to add a special vector into a library is analogous to the argument for adding a "property" keyword to C++ (discussed elsewhere in this thread). In both cases, a situation is created where the programmer may temporarily think she is accessing actual variables in a structure, but the illusion cannot be maintained.
You can tell that vector is fake by trying to take the address of one of its elements (which fails because sizeof(bool)>sizeof(bit)). Likewise, using "property" to masquerade a function-call as a variable fails when the user asks for the address of the "variable".
They could use the PROPERTY macro to build their classes, and in the event that a variable turns out to need side-effect code run before/after it is read/written, that macro can be replaced with manually-editted getter/setter functions.
Every single example I've ever seen either indicates seemingly-random exceptions should be thrown, or unexpected delays should occur.
That bridge was already crossed back when operator-overloading was first allowed. Your example statement "a = a + b" might be invoking operator+() and operator=(), which could randomly throw exceptions or take a long time to complete.
The bigger objection to properties is that they do a poor job of emulating true public member variables. The goal of properties is that they allow necessary side effects to happen when a member is changed. But how could the following code work if x was an int "property"?
void foo(int *p){ *p = 20;};
void bar(){
int i = 10;
foo(&i);
G g;
foo(&g.x);
}
How is foo() able to cause a side effect when passed &g.x, but not when it gets &i? Unless that question can be answered satisfactorilly, properties won't fit well in C++.
meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that
I don't think that properties could hide the nature of attributes very convincingly in an elaborate language like C++. They work in the case of
M.x = 10;//property, or public var? Can't tell but probably fail for
SetCursor(M.x++, M.y++);//fine with public var and
LimitToRange(&M.x, 0, 640);//also fine with public var
Prehaps there's a way to implement properties to handle those cases, but it won't be a simple fix, and I doubt C++ linkers have enough authority to handle it.
the power of some of the C++ GUI's out there, QT is probably best of breed
I deny that Qt is actually C++. Code which uses Qt in the intended manner (as opposed to a completely ugly mess) must first be run through a non-C++ precompiler to expand out concepts like signals and slots.
It is rather ironic that Bjarne's homepage cites KDE as a major example of C++, when evidently C++ wasn't good enough for them to write in. (Note that expanding C++ inside the language, like boost does, is not comprable to using an external precompiler)
No parameters-by-name function calls", seems like a nice idea, but also seems fundamentally incompatible with va_args style variable length arguement lists unless
There's no real conflict there. Classic variable-argument functions will just be disallowed from being called with parameter-by-name syntax. (Note that parameter-by-name is essentially a more flexible version of the usual system of default argument values)
I suppose that... would take precidence and would inhibit the use of named args.
Not likely. "..." is considered as dangerous and obselete by the C++ commitee. It is so steadfastly non-typesafe that they want nothing to do with it.
Your suggestion doesn't work, for reasons which should be obvious. First of all, numbers in curly braces are ambiguous; they could be either an array initializer or an initializer for any struct with that many members. And second, arrays don't carry around their size.
The suggestion can work- it just implies a few other minor language extensions, which should be obvious. First, numbers in curly braces should represent whatever type is valid in that context- or if there are two valid types, then they should mean "array" unless specifically prefixed with the name of a struct.
Second, arrays could easily carry around their size. In practice, typical malloc systems do have them carry their size, but in an inaccessible space. However, since the arrays in question are of fixed compile-time length, the size can be known even easier.
AC: For example, class(should be "static") methods don't define a "this" variable (again, because the class doesn't exist). Yet without a "this" variable, dynamic dispatch is not available inside class methods.
So naturally, any method which is virtual static would have a this_class pointer implicitly available, which instead of pointing to any specific object, just tells which vtable is in effect for the function-call.
Also, I can see some potential difficulties with parameters-by-name. The biggest one is that it will break code of the form
It would only introduce ambiguity if an syntax is chosen that already has a valid meaning in existing programs. You demonstrated one such syntax, but there are many other possibilities. For example, name arguments could be accomplished with
foo(title:= "This is a different title");//pascal-style assignment operator
That's actually the best approach I can think of, because:= isn't valid anyplace else in C++. Although it's somewhat desirable to use a familiar-looking syntax for new situations, as you point out, that cannot be done without occasionally producing ambiguity with existing code (Just like you can never make a new keyword without breaking SOME programs. Why, my old C++ code broke when they came out with "or" as a keyword. Lousy continentals with their accented vowels...)
Can you expand on how you would write the constructor for, say, a list class that can take a composite literal as a parameter?
Hopefully Bjarne will notice this (or already has, and just didn't want to go into such detail for a brief article). A "sequence constructor" should really just be a single-argument constructor which happens to take an array-argument. Like
vector<T>::vector<T>(const T &ar[]) {
set_size(array_length(ar));//assuming a language addition
for (int i=0;i<array_length(ar);++i) _v[i]=ar[i];
}
Also, the concept should be compatible with the implicit keyword, so that a function which takes a vector<int> could be given an array-literal.
I know (isn't it obvious?). What I mean is that "what is the problem with 'auto' so as that we don't have it yet".
auto will reduce code maintenance is many common situations. Most famously is the cases of iterators:
for (auto i=c.start();!i.done();++i) foo(*i); With auto, c can be changed to different kinds of containers (from an array to a linked list) without needing to modify the code which uses it. Without auto, you'd need to declare c as something like "vector<Molecule>::iterator", which is harder to read and maintain.
The auto keyword looks to be the most surefire of these proposed extensions, as it is both useful and easy for compilers to support.
No garbage collection. Come on C++ guys! how many times have we got to
As someone else has probably already told you, the article says GC is being added to C++.
system, and no one has used C++ for any hardcore military project. Where is
The onboard computers of the new F-35 JSF combat airplane are all C++. As are existing Army air-defense missiles. (A factoid mentioned on Bjarne's homepage, also linked from TFA)
In other words it is very hard to write automated code browsing tools or refactoring tools for C and C++ because you can't parse a given source file
Some might say that a command like "gcc -E" would solve this, as it runs the preprocessor stage only, creating a file which other tools can parse. However, that's not a real solution, because the preprocessor depends on -D macros set from the makefile / environment-vars / build-script, which may be arbitrarily complex.
As usual, powerful and flexible software has the pitfall that it cannot be sanely analyzed by another program.
Savannahs are possibly the least hospitable habitat on the face of the earth for the reasons you've mentioned.
Hello? Artic ice cap? Open seas?
Its the one type of natural habitat that I can think of that features natural predators.
Hello? Polar bears, mako sharks?
Plus, back when homo sapiens first evolved, the "big predators" of Africa were a lot less deadly. Back then they were often stupid, and a person could walk right up with a broken stick and stab a huge animal through the neck. The dumb ones died out from that victimization, and the ones which survive today are more suspicious and agressive towards humans. Evolution in action.
On the flip side, the savannah is an especially good setting for rapid evolution to
The savannah is nicer than any place with a winter climate. In Africa, any naked human you set down will still be alive 12 hours later (barring animal attacks). In Europe's January, a person without the training to build fire and already-prepared animal hides is dead in 12 hours, no question.
I was talking about poor African nations. Someplace like Zambia or the Congo. The people of South Africa have around 15x the wealth of Zambians (Namibia has 8x the wealth)
The truely poor would love to reach the point where unfair competition is a significant concern. Until that time, cheap food is why they're still alive.
PS. I should've been more specific though, because food is only one kind of subsidized agriculture. Nonfood subsidies like textiles do hurt poor nations countries.
but the concept of subpixel rendering for LCDs is general enough to apply to any image with sharp edges
No. It only applies well to objects that are all-black or all-white. Say that R means red-on and r is red-off. Then, subpixel rendering takes advantage of the fact that solid white is rendered on LCD as RGBRGBRGB (for 3 horizontal pixels). A horizontal line from 0.66 to 1.33 could be drawn as rgBRGBRgb.
That technique works because white/black objects use the 3 color elements in equal proportion. The program is free to stop the chain of RGB at any point, knowing that the shape still looks white. Any non-greyscale image will have bias towards one of the components, meaning that subpixel rendering would create a left or right tendency in the percieved visual. (Reddish things are leaning a partial-pixel to the left, blueish things lean to the right).
If the shape were colored (unlike text, which the viewer knows is almost always solid black), then a transition from figure to ground is not readily distinguishable from a texture pixel in a different color.
but the concept of subpixel rendering for LCDs is general enough to apply to any image with sharp edges.
If Quake involved sharp edges somewhere...
And what is the silhouette of a polygon in a Quake model?
They don't have significant silhouettes, unless the player has replaced the skin and terrain texture maps with high-contrast fullbright colors, which was a common cheat in years past.
If the game in question were not Quake, but instead some monochrome line-rendered shooter like PencilWhipped, subpixel rendering could work, just as it does for text.
For non-human hominids, their is no efficiency gain for bipedalism.
Those studies don't look at the full picture. Another important metric is energy per height. That is, bipedalism allows you to be higher off the ground than any other (non-flying) animal of the same mass, which is important for long-range navigation between water sources in broad, grassy plains.
Indeed, the first meaningful divergence between proto-humans and other apes was bipedalism, which maximized visual range in non-arboreal environments.
And after that, you factor in that only bipeds can carry liquids, which effectively allows much more efficient travel (since there's less constraint to stay near watering holes, other routes are opened). Those 3 together put bipedalism into the lead.
He couldn't have brought back spaghetti, only noodles.
Spagetti is a subcategory of noodle. And tomatoes are not one of the required ingredients for spagetti: all you need for homemade spagetti is wheat, eggs, and salt.
Nope. The farm subsidies of the USA do not harm African nations. There are some moderately poor countries (mostly South America + Southeast Asia) whose domestic agricultural workers suffer because subsidized USA crops are unfair competition.
But overall, poor African nations benefit from crop subsidies, because the artificially-depressed crop price allows them to import more food. They'd have to become significantly wealthier for subsidies to become a problem for them.
Slashdot Mirror
E.g. adding strings and complex numbers both have obvious expected meanings. Writing to a stream is nothing like shifting
Shifting is nothing like being incomprably smaller than another number.... but that's what "<<" means. (And furthermore, multiplication is unrelated to footnoting)
But the first case would in fact be extremely simple to implement:
Actually, it's exactly as difficult as the second case. I gave the same problem twice in different guises. You can't be sure that ++ really means to add 1. There could be an overloaded operator++ involved, and it might do absolutely anything. In light of that possibility, the concerns are exactly the same as when a non-const reference is passed to an arbitrary function.
See also this comment for a longer example of the implications of C++ property. And this comment, while you're here.
Luckily, languages implementing properties don't have that kind of insanity, so the issue is moot.
Since the topic was a proposal to add "property" to C++, it certainly wasn't moot.
(Final note: calling C++ "elaborate" may be going a bit too far, Smalltalk, Ruby or Python seem much more "elaborate" to me.)
I intentionally chose to call it "elaborate" because although there are languages which are more powerful and flexible, C++ has more explicitly different features in its specification (instead of allowing more of the features to be a natural consequence of fundamental capabilities). Inheritance, templates, operator-overloading, and exceptions don't flow naturally out of the primitive structures; they are all separate features.
I was particularly thinking of the functional languages like Lisp, which have more expressive power than C++, and from smaller language definitions.
I'll agree that Perl and ADA are possibly more elaborate than C++ (depending on how you measure).
IMHO that's rather unfair. When Visual C++ 6 was released,
The fair complaint is that Microsoft waited more than 7 years between compiler releases. VC6 was justly maligned by people stuck using it into the 200Xs. There was no reason several simplistic compiler changes couldn't have been issued prior to the full VC7 rollout.
AC: 1. C++ IS a superset of C. C came up short in certain areas. C++ tried to fix that and from TFA it is still evolving.
Back when C++ was first released, "int virtual;" was a valid declaration in C. But of course, that variable name is illegal in C++. Therefore since we've seen at least one sample where valid C code doesn't work in C++, C++ is not a superset. (There are also more substantial ways it is not a superset, which I won't detail)
More generally, no language which introduces a new keyword is a superset of the older language, because it breaks those programs which already used that keyword as a custom identifier.
Also, you can avoid the NULL case (which is a giant hole in preventing runtime errors) by passing by value or reference only.
How do you think NULL is a weakness? The inability of C++'s references to be set to Null (like a Java reference can) is one of the biggest reasons C++ programs muse use so many pointers instead of references.
Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java
That sounds very suspicious. C++ references cannot substitute for either Java references or C++ pointers. To fill those roles, they need to be reseatable, and be able to have a NULL value. (Which is equivalent to OPTION datatypes in some functional languages... the ability to talk about a value which might not be present is semantically important)
your favorite code completition mechanism shows the identifiers you may write behind the dot. But: what comes then? Some ( and ) as in a method? Or nothing as in a property?
File a bug report on your IDE. It already parsed the class definition to know what the member variables are named, so it should also know if they are properties or methods, and be able to insert any needed parentheses on its own.
And in doing so, violates just about every sane property of every other container type in the language.
The reason it must do that (as you probably know) is because the CPU's pointers are not capable of addressing individual bits. Addresses can only point to whole bytes.
Interestingly, this means that the choice to add a special vector into a library is analogous to the argument for adding a "property" keyword to C++ (discussed elsewhere in this thread). In both cases, a situation is created where the programmer may temporarily think she is accessing actual variables in a structure, but the illusion cannot be maintained.
You can tell that vector is fake by trying to take the address of one of its elements (which fails because sizeof(bool)>sizeof(bit)). Likewise, using "property" to masquerade a function-call as a variable fails when the user asks for the address of the "variable".
properties... What is wrong with:
Moreover, people who demand "property" support in the C++ language should consider building it themselves. As a dense 1-line macro, even!
#define PROPERTY(T, N) private: T N##_;public:const T& N()const{return N##_;};void Name(const T& t){N##_=t;};
They could use the PROPERTY macro to build their classes, and in the event that a variable turns out to need side-effect code run before/after it is read/written, that macro can be replaced with manually-editted getter/setter functions.
Every single example I've ever seen either indicates seemingly-random exceptions should be thrown, or unexpected delays should occur.
That bridge was already crossed back when operator-overloading was first allowed. Your example statement "a = a + b" might be invoking operator+() and operator=(), which could randomly throw exceptions or take a long time to complete.
The bigger objection to properties is that they do a poor job of emulating true public member variables. The goal of properties is that they allow necessary side effects to happen when a member is changed. But how could the following code work if x was an int "property"?
void foo(int *p){ *p = 20;};
void bar(){
int i = 10;
foo(&i);
G g;
foo(&g.x);
}
How is foo() able to cause a side effect when passed &g.x, but not when it gets &i? Unless that question can be answered satisfactorilly, properties won't fit well in C++.
meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that
I don't think that properties could hide the nature of attributes very convincingly in an elaborate language like C++. They work in the case of
M.x = 10;//property, or public var? Can't tell
but probably fail for
SetCursor(M.x++, M.y++);//fine with public var
and
LimitToRange(&M.x, 0, 640);//also fine with public var
Prehaps there's a way to implement properties to handle those cases, but it won't be a simple fix, and I doubt C++ linkers have enough authority to handle it.
the power of some of the C++ GUI's out there, QT is probably best of breed
I deny that Qt is actually C++. Code which uses Qt in the intended manner (as opposed to a completely ugly mess) must first be run through a non-C++ precompiler to expand out concepts like signals and slots.
It is rather ironic that Bjarne's homepage cites KDE as a major example of C++, when evidently C++ wasn't good enough for them to write in. (Note that expanding C++ inside the language, like boost does, is not comprable to using an external precompiler)
No parameters-by-name function calls", seems like a nice idea, but also seems fundamentally incompatible with va_args style variable length arguement lists unless
... would take precidence and would inhibit the use of named args.
There's no real conflict there. Classic variable-argument functions will just be disallowed from being called with parameter-by-name syntax. (Note that parameter-by-name is essentially a more flexible version of the usual system of default argument values)
I suppose that
Not likely. "..." is considered as dangerous and obselete by the C++ commitee. It is so steadfastly non-typesafe that they want nothing to do with it.
Your suggestion doesn't work, for reasons which should be obvious. First of all, numbers in curly braces are ambiguous; they could be either an array initializer or an initializer for any struct with that many members. And second, arrays don't carry around their size.
The suggestion can work- it just implies a few other minor language extensions, which should be obvious. First, numbers in curly braces should represent whatever type is valid in that context- or if there are two valid types, then they should mean "array" unless specifically prefixed with the name of a struct.
Second, arrays could easily carry around their size. In practice, typical malloc systems do have them carry their size, but in an inaccessible space. However, since the arrays in question are of fixed compile-time length, the size can be known even easier.
AC: For example, class(should be "static") methods don't define a "this" variable (again, because the class doesn't exist). Yet without a "this" variable, dynamic dispatch is not available inside class methods.
So naturally, any method which is virtual static would have a this_class pointer implicitly available, which instead of pointing to any specific object, just tells which vtable is in effect for the function-call.
Also, I can see some potential difficulties with parameters-by-name. The biggest one is that it will break code of the form
:= "This is a different title");//pascal-style assignment operator
:= isn't valid anyplace else in C++. Although it's somewhat desirable to use a familiar-looking syntax for new situations, as you point out, that cannot be done without occasionally producing ambiguity with existing code (Just like you can never make a new keyword without breaking SOME programs. Why, my old C++ code broke when they came out with "or" as a keyword. Lousy continentals with their accented vowels...)
It would only introduce ambiguity if an syntax is chosen that already has a valid meaning in existing programs. You demonstrated one such syntax, but there are many other possibilities. For example, name arguments could be accomplished with
foo(title
That's actually the best approach I can think of, because
Can you expand on how you would write the constructor for, say, a list class that can take a composite literal as a parameter?
Hopefully Bjarne will notice this (or already has, and just didn't want to go into such detail for a brief article). A "sequence constructor" should really just be a single-argument constructor which happens to take an array-argument. Like
vector<T>::vector<T>(const T &ar[]) {
set_size(array_length(ar));//assuming a language addition
for (int i=0;i<array_length(ar);++i) _v[i]=ar[i];
}
Also, the concept should be compatible with the implicit keyword, so that a function which takes a vector<int> could be given an array-literal.
I know (isn't it obvious?). What I mean is that "what is the problem with 'auto' so as that we don't have it yet".
auto will reduce code maintenance is many common situations. Most famously is the cases of iterators:
for (auto i=c.start();!i.done();++i) foo(*i);
With auto, c can be changed to different kinds of containers (from an array to a linked list) without needing to modify the code which uses it. Without auto, you'd need to declare c as something like "vector<Molecule>::iterator", which is harder to read and maintain.
The auto keyword looks to be the most surefire of these proposed extensions, as it is both useful and easy for compilers to support.
No garbage collection. Come on C++ guys! how many times have we got to
As someone else has probably already told you, the article says GC is being added to C++.
system, and no one has used C++ for any hardcore military project. Where is
The onboard computers of the new F-35 JSF combat airplane are all C++. As are existing Army air-defense missiles. (A factoid mentioned on Bjarne's homepage, also linked from TFA)
In other words it is very hard to write automated code browsing tools or refactoring tools for C and C++ because you can't parse a given source file
Some might say that a command like "gcc -E" would solve this, as it runs the preprocessor stage only, creating a file which other tools can parse. However, that's not a real solution, because the preprocessor depends on -D macros set from the makefile / environment-vars / build-script, which may be arbitrarily complex.
As usual, powerful and flexible software has the pitfall that it cannot be sanely analyzed by another program.
Savannahs are possibly the least hospitable habitat on the face of the earth for the reasons you've mentioned.
Hello? Artic ice cap? Open seas?
Its the one type of natural habitat that I can think of that features natural predators.
Hello? Polar bears, mako sharks?
Plus, back when homo sapiens first evolved, the "big predators" of Africa were a lot less deadly. Back then they were often stupid, and a person could walk right up with a broken stick and stab a huge animal through the neck. The dumb ones died out from that victimization, and the ones which survive today are more suspicious and agressive towards humans. Evolution in action.
On the flip side, the savannah is an especially good setting for rapid evolution to
The savannah is nicer than any place with a winter climate. In Africa, any naked human you set down will still be alive 12 hours later (barring animal attacks). In Europe's January, a person without the training to build fire and already-prepared animal hides is dead in 12 hours, no question.
I have been to Africa (Namibia, South Africa)
I was talking about poor African nations. Someplace like Zambia or the Congo. The people of South Africa have around 15x the wealth of Zambians (Namibia has 8x the wealth)
The truely poor would love to reach the point where unfair competition is a significant concern. Until that time, cheap food is why they're still alive.
PS. I should've been more specific though, because food is only one kind of subsidized agriculture. Nonfood subsidies like textiles do hurt poor nations countries.
but the concept of subpixel rendering for LCDs is general enough to apply to any image with sharp edges
No. It only applies well to objects that are all-black or all-white. Say that R means red-on and r is red-off. Then, subpixel rendering takes advantage of the fact that solid white is rendered on LCD as RGBRGBRGB (for 3 horizontal pixels). A horizontal line from 0.66 to 1.33 could be drawn as rgBRGBRgb.
That technique works because white/black objects use the 3 color elements in equal proportion. The program is free to stop the chain of RGB at any point, knowing that the shape still looks white. Any non-greyscale image will have bias towards one of the components, meaning that subpixel rendering would create a left or right tendency in the percieved visual. (Reddish things are leaning a partial-pixel to the left, blueish things lean to the right).
If the shape were colored (unlike text, which the viewer knows is almost always solid black), then a transition from figure to ground is not readily distinguishable from a texture pixel in a different color.
but the concept of subpixel rendering for LCDs is general enough to apply to any image with sharp edges.
If Quake involved sharp edges somewhere...
And what is the silhouette of a polygon in a Quake model?
They don't have significant silhouettes, unless the player has replaced the skin and terrain texture maps with high-contrast fullbright colors, which was a common cheat in years past.
If the game in question were not Quake, but instead some monochrome line-rendered shooter like PencilWhipped, subpixel rendering could work, just as it does for text.
For non-human hominids, their is no efficiency gain for bipedalism.
Those studies don't look at the full picture. Another important metric is energy per height. That is, bipedalism allows you to be higher off the ground than any other (non-flying) animal of the same mass, which is important for long-range navigation between water sources in broad, grassy plains.
Indeed, the first meaningful divergence between proto-humans and other apes was bipedalism, which maximized visual range in non-arboreal environments.
And after that, you factor in that only bipeds can carry liquids, which effectively allows much more efficient travel (since there's less constraint to stay near watering holes, other routes are opened). Those 3 together put bipedalism into the lead.
He couldn't have brought back spaghetti, only noodles.
Spagetti is a subcategory of noodle. And tomatoes are not one of the required ingredients for spagetti: all you need for homemade spagetti is wheat, eggs, and salt.
First World agricultural subsidies,
Nope. The farm subsidies of the USA do not harm African nations. There are some moderately poor countries (mostly South America + Southeast Asia) whose domestic agricultural workers suffer because subsidized USA crops are unfair competition.
But overall, poor African nations benefit from crop subsidies, because the artificially-depressed crop price allows them to import more food. They'd have to become significantly wealthier for subsidies to become a problem for them.
For more info