Deriving from string is perfectly valid, although it's better to derive from basic_string which is what a string is anyway...
It is absolutely not valid! The string (and basic_string) class does not have a virtual destructor. If your new class is deleted via a pointer to the base class, undefined behavior will result. That is right, the behavior is undefined (although usually your subclasses destructor is just not called).
Very, very bad thing.
Why is it bad to have a function that takes a string???
But there is nothing inherently costly about array bounds checking. Modern processors are designed to implement it efficiently. In a well-designed template library, the overhead of array bounds checking should be less than a factor of 2.
I fail to see the logic here.
On an x86, an array can be indexed with one instruction (actually, the indexing can be used in any operation).
So to say:
a = v[1];
would just generate something like
mov DS:[ebp+12, 4, 1], eax mov eax, ebp+8
Whereas with bounds checking you have have to introduce another register to hold the index, along with possible redirects and atleast 2 comparisions.
Best case senario, you have 3 additional instructions and a redirect resulting in a factor of 4 overhead plus the possible cache miss from the redirect.
Put that all in a tight loop, and bounds checking will kill performance.
Now, if the compiler isn't smart enough to inline the now much more complicated operator, your also going to pay for a function call. That would be the kiss of death.
If you're never going to give the user a pointer to the base class, then what's the harm in deriving from an STL class? Seems to save a lot of typing to me.
Your playing with fire there pal... Instead of using inheritence, just simply return a vector iterator from a private member. Works just as well. Besides, the users going to have to static cast the reference in order to get to your methods. That opens the door to storing off a pointer, and subsequently, deleting the base pointer.
I understand your point, but its just bad design. The problem is that this is a bug that most people wouldn't recognize so your really taking a gamble.
Agreed. The using directive is simply a directive that tells the compiler to import all the names from std.
It's equivalent to the import directive in java. As far as I'm concerned, the only time that using shouldn't be used to import the std namespace is when a conflict is likely to occur (most environments have coding standards making collision almost impossible).
*The STL makes no guarantees that it checks for errors (bounds checking, using a pointer into the wrong collection, etc.), and it is designed in such a way that error checking is quite costly.
Bounds checking is absolutely evil. An STL vector will perform exactly the same as a standard C array. If bounds checking was introduced, a vector would be between 3 and probably 20 times slower depending on the inliner.
Bounds checking is the programming equivalent of training wheels. They seem like a good idea at first, but you should get rid of them as soon as possible.
The number of abstract data types IN NO WAY AFFECTS CODE SIZE. Sorry to say it loudly but too many people here keep repeating that.
It may *appear* that way when working with STL but that is only because of the debugging information. Using templates will increase the amount of debug information in the executable (for each instance of the template) but it does not increase code size in any noticable manner.
Note: Ok, there are some methods that do get regenerated per-data type but the overhead is small and STL uses extensive inlining so this is almost meaningless.
1. It uses templates. I know the name implies this but I can't stand the way C++ implements templates. Templates are created at compile-time which removes any advantages of generics in the first place.
As compared to what language??? C++ templates are one of the best features of the language. Yes, they are a different concept, but embrace it, change is good.
I have no idea what you are talking about regarding templates being created at compile-time as being a bad thing. That's what generic programming is all about!!! Its the compiler generating classes so that you don't have to. It has to be done at compile time. I'd love to hear an example of a language that implements some kind of generic stuff at runtime.
2. While it may reduce developer time, it doesn't reduce code bloat. Templates are huge wasters of memory. This is because C++ creates a brand new class for *each* type of the template you use. So if memory consumption is an issue for you (like it is with me) then stay away.
Having additional classes only uses more memory at compile time. It makes absolutely no difference at runtime. The executable size increases only because of debug information. Stripping out the debug info will dramatically reduce executable size.
3. Template are *not* portable. Each compilier has varying support for templates. Yes the *new* compiliers support *most* of the STL but if a developer wants to get to those older models on the shelves... stay away.
ANSI C is *not* portable either for the most part. Remember, C++ is a young language with a young standard. Of course its not as portable as C, but its still more portable than any other solution (MFC, RougeWave, etc).
4. Using templates is verbose especially when you decide to throw inheritence in there. Template may look cool but they can get complicated really quickly (i.e. using the STL map template while inheriting from it)
YOU SHOULD NEVER INHERENT FROM AN STL CONTAINER. Period. There is no good reason to do this. If your design calls for it, then you have a bad design. Besides, STL containers do not have to have virtual destructors so you are introducing potential memory leaks if you inherent from them (this was made part of the standard on purpose).
5. Fragile Base Class. This is a C++ problem but it very much applies to the STL. If you build anything upon the STL and they add a virtual function... good-bye binary compatibility.
The STL does not have virtual functions. Nothing to worry about there. Remember, STL is standardized so there is no need to worry about stuff like that.
I fight extremely hard to not use the STL as there are other well-tested non-templated implementations of what the STL has.
For instance??? You are doing yourself an extreme disservice by avoiding STL.
# verbose type syntax: When you use the containers, like (say) std::vector, you have to declare your iterators as:
std::vector::iterator i;
Of course, this is a bit exaggerated. If your using STL frequently, then you can just use a:
using namespace std;
And typedefs should definitely be used not just to save typing but to allow different containers to be used without massive search-and-replace. I would argue that this is a feature if anything.
Easy way to solve this problem known as the "swap trick." This will work with any container (and strings) and is the only way to guarentee a reduction in capacity.
vector v(10000);//reserve bunch of memory //even though size is 0
vector().swap(v);//swap the elements from an //empty temporary including //swapping capacity
The last book in Myers effective triology goes into a great number of details about the pitfalls of STL
One thing to be wary of (as many have pointed out) is the different implementations of STL. GCC pre-3.x is pretty non-standard (although not necessarily bad). MSVC pre-6.x is absolutely horrendous (from what I gather, this is more of a legal issue than MS's fault).
Some of the wackiest things though IMHO are:
- Never use vector! It's a horrible specialization and is not even a container. Very, very bad.
- Allocators are for the most part evil. Be very wary of them.
BTW: There is a book Efficient C++ that says a lot of bad things about STL. This book absolutely sucks and is full of nothing but crap. While the examples aren't forged, they are examples of how not to use STL. Unfortunately, the book presents non-STL solutions that aren't even as fast as the proper STL solution. Long and the short of it is, make sure you (and your developers) are very familiar with STL and be aware of bad information about it.
There is a quasi-quantum idea to it though. Light isn't a part of classical mechanics technically.
Quantum mechanics encapsulates the old mechanics and the mechanics of sub-atomic particles. At any rate, I don't think this would have been thought of without quantum mechanics but then again, I was a little puzzled too when he said it was quantum mechanics (remember, classical mechanics is a special case of quantum mechanics).
I've worked in both a very secure environment and as a developer developing security software. The number one concern is absolutely always internal theft.
Take a look at high security environments like the FBI, CIA, or NSA. Is there an outer security threat to these places? Not really. These places are smart enough to have their internal networks physically seperated from the internet.
The threat to these types of companies are internal. That is why they spend an aweful lot of energy on ethics training and on internal policing. All it takes is for one bad employee to do a lot of damage.
It's definitely not FUD, although by the same token, it isn't anything new.
You would expect that since, say, 1980 or so, when numerical calculating power greatly in excess of the human brain became available (and I set it at 1980, not 1960-70, just to be conservative)
Hold your horses there pal. Give a little respect where its due. The human brain is far more powerful than any piece of hardware out there.
Consider the fact that the brain processes two seperate high resolution images and generates depth by comparing them in real-time 12-16 hours a day, plus stores a large portion (some argue all) of the incoming images. The difference between brains and computers are that computers can be programmed much faster than a brain (at least, in a direct means). There are mathemagicians out there that can crunch numbers just as fast as any computer can.
The flaw in your reasoning is that computers are not superior to the human brain, for now at least.
that a computer could easily trounce a human in any game involving only tactics.
Be careful with the word easily. Remember, programmers are only human too. A human must first master the game before he can write a program to beat anyone. There has to be a "perfect solution" as there is in tic-tac-toe found. A computer can assist in finding the perfect solution, but a programmer has to at least give it direction.
is the strategy that a human chess player would use also based on these millions of tiny tactical evaluations, only so subtle that he's not aware they're going on in the vast electrochemistry of his brain?
More or less. At least, this is the current thinking. The brain is just a big-ole circuit that produces an output when given inputs. The neat thing about the brain is that its output can be used again as inputs to allow the path to be optimized. Computers currently can't really do that.
making computers that can function like minds, or simply working really well with computers, I leave to you.
This is the basis of artificial intellegence research. I do believe though that we will need to advance more in biomechanics before we can do anything worthwhile in AI since it isn't particularily easy to replicate the ability for organic compounds to evolve and recreate themselves.
Then again, what we really should be asking is not how do we replicate biology, but what is it that is more effecient than biology for performing calculations?
As is the American economy heavily dependent on China. Perhaps even more so.
Yeah, that is why I said they were codependent:)
If the Chinese economy was only dependent on America, then there would be _alot_ of change in China since America would have a lot of leverage in things like human rights issues and such. Remember, China is the largest communist country and we are the country that fought so hard to rid the world of communism.
Of course, economics is the greatest political factor (the situation in China almost seems to prove Marx's theory at least).
Theoretically, China could get raw cash from anyplace that has it.
Something like 26% of the World Domestic Product comes from the US. There isn't another country in the world that could supply China with the kind of business that the US does.
Where else can the US and Japan get all their electronics manufactured (at the volume and prices that we need) besides China?
China isn't the largest producer of electronics IIRC. Instead, China is known for producing more retail oriented items (clothing, and especially little plastic thingies).
Taiwan and Singapore produce an aweful lot of electronic components...
Ever looked into who Germany's major trade partners were just prior to WWI?
Good point, but I think there is a much greater codependency between the US and China than say the US and pre-WWI Germany.
In fact, look how long it took for the US to enter WWI. Why? Because we were making a killing from it. It took a direct economic threat (the sinking of US trading ships) to get us involved.
The US and China have a "most-favored nation" agreement and there is almost no tariff on trade between the two countries. China is the US's primary source of very cheap labor.
Are chinese citizens planning on attacking the US? Sure, so are American citizens.
Has the chinese government considered the possibility of cyber-attacking the US? Sure, just like we considered the possibility of dropping nukes on half the world recently.
Is the chinese government actively planning to attack the US? Not if they have even the remotest bit of sense in the world.
The chinese economy is _heavily_ dependent on the American economy. An attack on America would effectively be an attack on their own economy. The codependence of our economies is probably the only reason all-out-war hasn't broken out between us.
Remember though, money is absolutely the most powerful influence in diplomacy and there isn't much that could come in the way of the massive amounts of money being exchanged between China and the US.
BTW: As far as the whole "open, blantantly" thing is concerned, Thoreau's great act of Civil Disobedience was far from any of these.
He came into town one day to pick up his shoes that were being repaired. The town tax-collector asked him to pay his poll-tax which he had no paid in 6 years. He refused because he wished to refuse allegiance to a state that would wage an immoral war against Mexico and keep 6 million of its citizens in the bondage of slavery. So, the tax-collector threw him in jail. He sat in jail quietly overnight, was released in the morning, got his shoes, and went back into the woods.
There was no great public event, or grand protest. He simply refused to obey a law that he felt would cause him to violate his morality, took the punishment for it, and went about his business.
Civil disobedience requires putting yourself out in the open, blatantly violating the law and likely getting arrested.
If you go by the commonly bastardized version of Civil Disobedience used to justify various forms of activism. The term was really coined though by Henry David Thoreau in his essay, "On the Duty of Civil Disobedience" and can be summarized best by the following passage:
If the injustice is part of the necessary friction of the machine of government let it go, let it go; perchance it will wear smooth, certainly the machine will wear out. If the injustice has a spring or a pulley or a rope or a crank exclusively for its own use, perhaps you may consider whether the remedy will be worse than the evil. But if it is of such a nature that it requires you to be the agent of injustice to another then I say break the law. Let your life be a counter-friction to stop the machine. What I must do is to see, at any rate, that I do not lend myself to the wrong which I condemn.
Civil Disobedience is about maintaining both order and individual autonomy in a state. Do not confuse civil disobedience with other forms of protest (such as satya agraha, or truth force) where violations of the law are justified in that "the ends justify the means."
Civil Disobedience comes into play only when an individual is trying to preserve his moral beliefs. Non-violent protests are not examples of civil disobedience.
amoral
adj : without moral standards or principles;
"a completely amoral person"
[syn: unmoral] [ant: moral, immoral]
Not to be confused with:
immoral
adj 1: violating principles of right and wrong
[ ant: moral, amoral]
The former suggests that something has absolutely no relation to morality, which I believe activism doesn't. Activism is self-serving. An activist is neither moral, since he is not trying to do right, nor is he immoral, since he is not trying to do wrong. Therefore, the activist is amoral, or is acting outside the scope of morality.
Perhaps the poster wouldn't have responded so negatively had he actually understood the English language...
ATI only releases a portion of the specs to a small group of developers who have signed an NDA.
ATI does not release specs for features that are unique to ATIs cards.
So for stuff like hardware iDCT and TV-OUT, ATI has released absolutely no specifications to anyone.
Not to mention the fact that they do not like to give their specs out much so you end up with like 3 people who actually have the specs and everyone else has to reverse engineer the drivers to figure anything out.
I've got an ATI Radeon in my machine, my gf has an ATI Radeon in her Windows 2000 box, and I can confidently say that the Linux drivers are far better than those for Windows, probably because ATI didn't write them. ATI (unlike nVidia) have been very good about releasing specs to the community.
This is because the special ATI hardware optimizations integrate better with X than they do with Windows. Of course, this is only possible with > X4 since that's when all the XVideo stuff was introduced.
BTW: ATI does not provide specs to the community. They provide only a portion of their specifications to a very small number of developers who have signed an NDA. The aspects of their cards that they feel are important to their bussiness model (i.e. TV-Out, hardware iDCT) they have released nothing for.
Slashdot Mirror
Deriving from string is perfectly valid, although it's better to derive from basic_string which is what a string is anyway...
It is absolutely not valid! The string (and basic_string) class does not have a virtual destructor. If your new class is deleted via a pointer to the base class, undefined behavior will result. That is right, the behavior is undefined (although usually your subclasses destructor is just not called).
Very, very bad thing.
Why is it bad to have a function that takes a string???
Better than having undefined behavior IMVHO.
BTW: Using to bring methods into the scope of a derived class is depriecated.
The new syntax is to simply to declare the operation signature.
Old Style:
class MyClass : private A {
using void method_from_A();
};
New Style:
class MyClass : private A {
void method_from_A();
};
But there is nothing inherently costly about array bounds checking. Modern processors are designed to implement it efficiently. In a well-designed template library, the overhead of array bounds checking should be less than a factor of 2.
I fail to see the logic here.
On an x86, an array can be indexed with one instruction (actually, the indexing can be used in any operation).
So to say:
a = v[1];
would just generate something like
mov DS:[ebp+12, 4, 1], eax
mov eax, ebp+8
Whereas with bounds checking you have have to introduce another register to hold the index, along with possible redirects and atleast 2 comparisions.
Best case senario, you have 3 additional instructions and a redirect resulting in a factor of 4 overhead plus the possible cache miss from the redirect.
Put that all in a tight loop, and bounds checking will kill performance.
Now, if the compiler isn't smart enough to inline the now much more complicated operator, your also going to pay for a function call. That would be the kiss of death.
If you're never going to give the user a pointer to the base class, then what's the harm in deriving from an STL class? Seems to save a lot of typing to me.
Your playing with fire there pal... Instead of using inheritence, just simply return a vector iterator from a private member. Works just as well. Besides, the users going to have to static cast the reference in order to get to your methods. That opens the door to storing off a pointer, and subsequently, deleting the base pointer.
I understand your point, but its just bad design. The problem is that this is a bug that most people wouldn't recognize so your really taking a gamble.
Get new gurus.
Agreed. The using directive is simply a directive that tells the compiler to import all the names from std.
It's equivalent to the import directive in java. As far as I'm concerned, the only time that using shouldn't be used to import the std namespace is when a conflict is likely to occur (most environments have coding standards making collision almost impossible).
*The STL makes no guarantees that it checks for errors (bounds checking, using a pointer into the wrong collection, etc.), and it is designed in such a way that error checking is quite costly.
Bounds checking is absolutely evil. An STL vector will perform exactly the same as a standard C array. If bounds checking was introduced, a vector would be between 3 and probably 20 times slower depending on the inliner.
Bounds checking is the programming equivalent of training wheels. They seem like a good idea at first, but you should get rid of them as soon as possible.
The number of abstract data types IN NO WAY AFFECTS CODE SIZE. Sorry to say it loudly but too many people here keep repeating that.
It may *appear* that way when working with STL but that is only because of the debugging information. Using templates will increase the amount of debug information in the executable (for each instance of the template) but it does not increase code size in any noticable manner.
Note: Ok, there are some methods that do get regenerated per-data type but the overhead is small and STL uses extensive inlining so this is almost meaningless.
Stupid HTML
1. It uses templates. I know the name implies this but I can't stand the way C++ implements templates. Templates are created at compile-time which removes any advantages of generics in the first place.
As compared to what language??? C++ templates are one of the best features of the language. Yes, they are a different concept, but embrace it, change is good.
I have no idea what you are talking about regarding templates being created at compile-time as being a bad thing. That's what generic programming is all about!!! Its the compiler generating classes so that you don't have to. It has to be done at compile time. I'd love to hear an example of a language that implements some kind of generic stuff at runtime.
2. While it may reduce developer time, it doesn't reduce code bloat. Templates are huge wasters of memory. This is because C++ creates a brand new class for *each* type of the template you use. So if memory consumption is an issue for you (like it is with me) then stay away.
Having additional classes only uses more memory at compile time. It makes absolutely no difference at runtime. The executable size increases only because of debug information. Stripping out the debug info will dramatically reduce executable size.
3. Template are *not* portable. Each compilier has varying support for templates. Yes the *new* compiliers support *most* of the STL but if a developer wants to get to those older models on the shelves... stay away.
ANSI C is *not* portable either for the most part. Remember, C++ is a young language with a young standard. Of course its not as portable as C, but its still more portable than any other solution (MFC, RougeWave, etc).
4. Using templates is verbose especially when you decide to throw inheritence in there. Template may look cool but they can get complicated really quickly (i.e. using the STL map template while inheriting from it)
YOU SHOULD NEVER INHERENT FROM AN STL CONTAINER. Period. There is no good reason to do this. If your design calls for it, then you have a bad design. Besides, STL containers do not have to have virtual destructors so you are introducing potential memory leaks if you inherent from them (this was made part of the standard on purpose).
5. Fragile Base Class. This is a C++ problem but it very much applies to the STL. If you build anything upon the STL and they add a virtual function... good-bye binary compatibility.
The STL does not have virtual functions. Nothing to worry about there. Remember, STL is standardized so there is no need to worry about stuff like that.
I fight extremely hard to not use the STL as there are other well-tested non-templated implementations of what the STL has.
For instance??? You are doing yourself an extreme disservice by avoiding STL.
# verbose type syntax: When you use the containers, like (say) std::vector, you have to declare your iterators as:
std::vector::iterator i;
Of course, this is a bit exaggerated. If your using STL frequently, then you can just use a:
using namespace std;
And typedefs should definitely be used not just to save typing but to allow different containers to be used without massive search-and-replace. I would argue that this is a feature if anything.
Easy way to solve this problem known as the "swap trick." This will work with any container (and strings) and is the only way to guarentee a reduction in capacity.
//reserve bunch of memory
//even though size is 0
//swap the elements from an
//empty temporary including
//swapping capacity
vector v(10000);
vector().swap(v);
The last book in Myers effective triology goes into a great number of details about the pitfalls of STL
One thing to be wary of (as many have pointed out) is the different implementations of STL. GCC pre-3.x is pretty non-standard (although not necessarily bad). MSVC pre-6.x is absolutely horrendous (from what I gather, this is more of a legal issue than MS's fault).
Some of the wackiest things though IMHO are:
- Never use vector! It's a horrible specialization and is not even a container. Very, very bad.
- Allocators are for the most part evil. Be very wary of them.
BTW: There is a book Efficient C++ that says a lot of bad things about STL. This book absolutely sucks and is full of nothing but crap. While the examples aren't forged, they are examples of how not to use STL. Unfortunately, the book presents non-STL solutions that aren't even as fast as the proper STL solution. Long and the short of it is, make sure you (and your developers) are very familiar with STL and be aware of bad information about it.
There is a quasi-quantum idea to it though. Light isn't a part of classical mechanics technically.
Quantum mechanics encapsulates the old mechanics and the mechanics of sub-atomic particles. At any rate, I don't think this would have been thought of without quantum mechanics but then again, I was a little puzzled too when he said it was quantum mechanics (remember, classical mechanics is a special case of quantum mechanics).
This actually isn't just FUD.
I've worked in both a very secure environment and as a developer developing security software. The number one concern is absolutely always internal theft.
Take a look at high security environments like the FBI, CIA, or NSA. Is there an outer security threat to these places? Not really. These places are smart enough to have their internal networks physically seperated from the internet.
The threat to these types of companies are internal. That is why they spend an aweful lot of energy on ethics training and on internal policing. All it takes is for one bad employee to do a lot of damage.
It's definitely not FUD, although by the same token, it isn't anything new.
I guess by first, they really mean second.
And as for worrying about what the FBI will do, I imagine that the FBI will just let the NSA (National Security Agency) do their jobs.
Sorry, normally I don't complain but sometimes I just can't help it.
You would expect that since, say, 1980 or so, when numerical calculating power greatly in excess of the human brain became available (and I set it at 1980, not 1960-70, just to be conservative)
Hold your horses there pal. Give a little respect where its due. The human brain is far more powerful than any piece of hardware out there.
Consider the fact that the brain processes two seperate high resolution images and generates depth by comparing them in real-time 12-16 hours a day, plus stores a large portion (some argue all) of the incoming images. The difference between brains and computers are that computers can be programmed much faster than a brain (at least, in a direct means). There are mathemagicians out there that can crunch numbers just as fast as any computer can.
The flaw in your reasoning is that computers are not superior to the human brain, for now at least.
that a computer could easily trounce a human in any game involving only tactics.
Be careful with the word easily. Remember, programmers are only human too. A human must first master the game before he can write a program to beat anyone. There has to be a "perfect solution" as there is in tic-tac-toe found. A computer can assist in finding the perfect solution, but a programmer has to at least give it direction.
is the strategy that a human chess player would use also based on these millions of tiny tactical evaluations, only so subtle that he's not aware they're going on in the vast electrochemistry of his brain?
More or less. At least, this is the current thinking. The brain is just a big-ole circuit that produces an output when given inputs. The neat thing about the brain is that its output can be used again as inputs to allow the path to be optimized. Computers currently can't really do that.
making computers that can function like minds, or simply working really well with computers, I leave to you.
This is the basis of artificial intellegence research. I do believe though that we will need to advance more in biomechanics before we can do anything worthwhile in AI since it isn't particularily easy to replicate the ability for organic compounds to evolve and recreate themselves.
Then again, what we really should be asking is not how do we replicate biology, but what is it that is more effecient than biology for performing calculations?
As is the American economy heavily dependent on China. Perhaps even more so.
:)
Yeah, that is why I said they were codependent
If the Chinese economy was only dependent on America, then there would be _alot_ of change in China since America would have a lot of leverage in things like human rights issues and such. Remember, China is the largest communist country and we are the country that fought so hard to rid the world of communism.
Of course, economics is the greatest political factor (the situation in China almost seems to prove Marx's theory at least).
Theoretically, China could get raw cash from anyplace that has it.
Something like 26% of the World Domestic Product comes from the US. There isn't another country in the world that could supply China with the kind of business that the US does.
Where else can the US and Japan get all their electronics manufactured (at the volume and prices that we need) besides China?
China isn't the largest producer of electronics IIRC. Instead, China is known for producing more retail oriented items (clothing, and especially little plastic thingies).
Taiwan and Singapore produce an aweful lot of electronic components...
Ever looked into who Germany's major trade partners were just prior to WWI?
Good point, but I think there is a much greater codependency between the US and China than say the US and pre-WWI Germany.
In fact, look how long it took for the US to enter WWI. Why? Because we were making a killing from it. It took a direct economic threat (the sinking of US trading ships) to get us involved.
The US and China have a "most-favored nation" agreement and there is almost no tariff on trade between the two countries. China is the US's primary source of very cheap labor.
Yeah, IMHO, this is all bullshit.
Are chinese citizens planning on attacking the US? Sure, so are American citizens.
Has the chinese government considered the possibility of cyber-attacking the US? Sure, just like we considered the possibility of dropping nukes on half the world recently.
Is the chinese government actively planning to attack the US? Not if they have even the remotest bit of sense in the world.
The chinese economy is _heavily_ dependent on the American economy. An attack on America would effectively be an attack on their own economy. The codependence of our economies is probably the only reason all-out-war hasn't broken out between us.
Remember though, money is absolutely the most powerful influence in diplomacy and there isn't much that could come in the way of the massive amounts of money being exchanged between China and the US.
BTW: As far as the whole "open, blantantly" thing is concerned, Thoreau's great act of Civil Disobedience was far from any of these.
He came into town one day to pick up his shoes that were being repaired. The town tax-collector asked him to pay his poll-tax which he had no paid in 6 years. He refused because he wished to refuse allegiance to a state that would wage an immoral war against Mexico and keep 6 million of its citizens in the bondage of slavery. So, the tax-collector threw him in jail. He sat in jail quietly overnight, was released in the morning, got his shoes, and went back into the woods.
There was no great public event, or grand protest. He simply refused to obey a law that he felt would cause him to violate his morality, took the punishment for it, and went about his business.
That is Civil Disobedience.
If you go by the commonly bastardized version of Civil Disobedience used to justify various forms of activism. The term was really coined though by Henry David Thoreau in his essay, "On the Duty of Civil Disobedience" and can be summarized best by the following passage:Civil Disobedience is about maintaining both order and individual autonomy in a state. Do not confuse civil disobedience with other forms of protest (such as satya agraha, or truth force) where violations of the law are justified in that "the ends justify the means."
Civil Disobedience comes into play only when an individual is trying to preserve his moral beliefs. Non-violent protests are not examples of civil disobedience.
amoral
adj : without moral standards or principles;
"a completely amoral person"
[syn: unmoral] [ant: moral, immoral]
Not to be confused with:
immoral
adj 1: violating principles of right and wrong
[ ant: moral, amoral]
The former suggests that something has absolutely no relation to morality, which I believe activism doesn't. Activism is self-serving. An activist is neither moral, since he is not trying to do right, nor is he immoral, since he is not trying to do wrong. Therefore, the activist is amoral, or is acting outside the scope of morality.
Perhaps the poster wouldn't have responded so negatively had he actually understood the English language...
FUD, FUD, FUD, FUD *to the SPAM theme*
ATI only releases a portion of the specs to a small group of developers who have signed an NDA.
ATI does not release specs for features that are unique to ATIs cards.
So for stuff like hardware iDCT and TV-OUT, ATI has released absolutely no specifications to anyone.
Not to mention the fact that they do not like to give their specs out much so you end up with like 3 people who actually have the specs and everyone else has to reverse engineer the drivers to figure anything out.
I've got an ATI Radeon in my machine, my gf has an ATI Radeon in her Windows 2000 box, and I can confidently say that the Linux drivers are far better than those for Windows, probably because ATI didn't write them. ATI (unlike nVidia) have been very good about releasing specs to the community.
This is because the special ATI hardware optimizations integrate better with X than they do with Windows. Of course, this is only possible with > X4 since that's when all the XVideo stuff was introduced.
BTW: ATI does not provide specs to the community. They provide only a portion of their specifications to a very small number of developers who have signed an NDA. The aspects of their cards that they feel are important to their bussiness model (i.e. TV-Out, hardware iDCT) they have released nothing for.