So if you find yourself saying "that's not fair" or "this should be against the law", you paint yourself into a corner where you don't really believe in free speech.
Canadians don't believe in free speech.
<sarcasm> See, we're a tolerant bunch -- a ruling democratic majority decides what's right, and the rest tolerates it. How dare any undemocratic, intolerant, idiot spout satire?
Canada is the pinnacle of oppression, particularly of dissenting speech (just look at the list of banned books). Here, the art of white supremacist placing of "niggers" in their place, and the "noble" Nazi mission of removing "kikes", has been elevated to a sophisticated, peaceful, non-violent supression -- the victims here are not distinguished by race, or religion, but by intelligence and productivity, reduced to being tax-slaves to support the bloated state, and majority of welfare slackoffs. Many even buy the tolerance bullshit to the point of dying for lack of funds to pay for necessary surgery -- them having been taxed away for "health care". What kind of "health care" has waiting lists for diagnostic procedures that are not resource-starved (as opposed to organ transplants)?. What kind of health care system rejects living organ doners (kidneys, lungs) that are matches but not relatives? What kind of tax code encourages daycare for children and discourages one parent from staying at home (the decision should be a tax-neutral parental one)? Of course daycare is preferred to parental care: the earlier to brainwash the future tax-slaves, the better!
Only in (Quebec,) Canada can the Chief of the Cree nation be sued for libel for noting, truetfully, that the government flooded much of their property with hydroelectric development projects because it was "unflattering" to speak the truth.
Americans: want to see a nation of sheep? Come to Canada and watch. This is what you will get if you permit socialism to continue to creep in your nation. Canadian attitudes are a dangerous disease. Forget Iraq. Bomb the shit out of Canada, before you learn what nationalized health care is like, and pay 50% income taxes for "free" services you can't get because you were "rich enough" to pay the taxes to support them (read up on "clawback" in the Canadian tax code).
</sarcasm>
I was born in Canada, lived 5-1/2 years in the U.S.A., and know who's got their act together. It isn't the "great white north".
Canada used to be rated #1 among the best places to live. It slipped to #8, and is now around #16. It's easy to live well when you live off the credit secured by the labour of tax-slaves. But, when the credit is maxed out, you suffer the consqeuences. For all its faults, stupidities, and excesses, the U.S. retains a far greater understanding and appreciation of liberty.
I agree with your observations, but note one error (at least as it applied in even recent history in Canada -- jurisdictional issues asside, the fact that it does not apply universally is interesting): Reproductive capability is clearly irrelevant, as it's not a prerequisite for heterosexual marriage
I'm not sure about present law, but until recently, in Canada, a marriage was not legal, unless it was consumated, the specific wording of the law requiring that "semen be deposited in the vagina", i.e. even mere intercourse was not sufficient to consumate the marriage.
Now it is equally interesting that Canada is in the throws of legalizing marriages among homosexuals, for many of the reasons you outine (i.e. there is no legal basis not to, and sufficient basis to require permitting it), so this consumation law is a bit quaint.
However, I am not aware that it has been struck down, or rescinded.
This is getting off topic... the original claim was that no terrorist acts ever succeeded on American soil prior to 9/11/2001. But your observation deserves a response.
Of course, the U.S. action of nuking Japan can be considered terrorism... I suppose all war can be considered terrorism and vice versa, with the differences between the two terms largly legal and semantic. If you want greater evidence against the U.S. as "bad guy", just think of the carpet bombing of Germany. No argument.
But, getting back to the nuking of Hiroshima and Nagasaki... these were industrial towns, and fair game in a declared war. Same goes for the carpet bombing of Germany, though both could be argued to be excesses.
Still, there is a difference between an air raid siren preceeding the arrival of enemy bombers over a military town from a nation that has declared war, and the surprise of an unexpected attack, that indescriminately targets civilian, industrial, or military targets alike. The latter qualifies as terrorism in my book. It is not "fair play" as far as war goes.
The distinction between a "legal" war and a terrorist act, by that standard is murky indeed, and I would not debate whether the U.S. has played the part of terrorist. However, the victor gets to write the history books, and I find the U.S. record in the regard is no worse than any other nation with which they have had conflicts.
While I would prefer that the U.S. exit Iraq as expeditiously as possible, and Saddam Hussein and henchmen be tried as fairly as possible in an Iraqui milleu, it would be naive to think that the U.S. will not try to retain as much of a regional presence as it can get away with. Any other occupier would act similarly. But, even if the U.S. remains indefinately, I can not see this any worse than the previous regime, and certainly better for Americans (as long as they can stomach the stream of body bags).
No US citizens have died from foreign terrorism on U.S. soil EVER... until GWB
I beg to differ.
Six Americans died in the U.S.A. during WWII when a Japanese balloon laden with explosives exploded when the unfortunate people found it -- Japan had been sending such balloons for a while, with the intent that their contents explode above or on top of American locations. With the exception of this one, they had no successes and abandoned the program.
Now, you could argue that this was not terrorism since Japan had formally declared war on the U.S.A., but the balloons, hitting random targets, were intended to frighten and demoralize the American citizenry, and show how far reaching Japan's offensive could get. I'd call that state-supported terrorism.
Frankly the term terrorism is rather silly: all war is terrifying and demoralizing the enemy via fear and uncertainty is a common tactic. The only difference between war and terrorism is that the former is initiated by a recognized state and the latter isn't. With state supported terrorism, even that line is becoming blured.
When I moved into my recent home, I had to rewire all over again (2xCat5 and 2xRG6/U to 8 drops and an extra 2xCat5e and 2xRG6/U to four of those drops. Unlike my last house in a subvurb of Dallas, this one has a basement.
I ended up wall mounting an open-frame Swingline picked up on Ebay (while the frame is 19", it's designed to wallmount on studs 16" or 19" apart). I got some patch panels from Ebay as well, and some ordered direct from Leviton. The rack also houses a 32 port 100 Mb/s switch. Non-rackmountable hardware (DSL modem/router, and satellite multiswitch) were wallmounted on plywood panels.
The rack is mounted on the wall in the basement, with cabling access to the first floor, and access to the second floor is achieved via a Panduit raceway on the back wall of the attached garrage: the raceway ends at the wall between the garrage (close to it's peak) and an inside second story closet. From there it's s snap to route cables up to the attic and down each inside wall to modular and coax outlets.
One thing you want to watch for is that the rails are pre-threaded to accept machine screws. Otherwise you will need lots of nuts. The prethreading adds $$$ (as it isn't cheap to tap that many holes) but is well worth it.
At the time, RMS himself gave this lecture (very inexpensively, I might add: expenses plus a small speaker's fee), and while the FSF's legal staff is more qualified to address the legal ramifications of the GPL, it was a presentation I very much enjoyed.
We carried shoeboxes full of punched cards over to the card reader. Woe unto those unfortunate souls who dropped theirs.
Yes, life was brutal until someone got the brilliant idea of using columns 73 to 80 for card sequence numbers that the Fortran compiler conveniently ignored.
Beware the 029 card punch, for the CDC 6600 only liked cards punched on the 026 card punch.:D gets ya every time!
Calling the Roku device (about which I submitted an earlier article to/. almost a month ago, but which got rejected -/me rubs the rump of his ego) a media player is a bit of a misnomer since, as others have disdainfully pointed out, it does not sport a CD/DVD drive for media playback or a hard drive for PVR functionality. Fair enough.
But, the beauty of the device is that it is silent and provides a great thin client for accessing content stored on remote servers in the home -- where the noisy fans and hard drives are.
Disclaimer: I work for ATI, closely with the chip on which the device is based.
In my last undergrad year, I had to take a course, "Advanced Digital Systems" (or something like that - Comp 426, IIRC), but the course included writing a hard disk driver for a small O/S (Flex), and was to be compared against a reference design.
Trouble was, there was no reference design, and I ended up getting coopted to write one over Christmas break '81-'82.
The 10 megger 8" hard drive we had was cool, though.
... a 300 baud direct-connect beast made by Hayes. Plunked down some CA$420 at the time.
I didn't have a computer (yet), but it was a joy to type the appropriate AT commands from my MIME I video terminal (complete with lower case character set!) instead of having to dial the phone.
Before I had a real computer (a homebrew SWTPC 6809-based clone running Flex), and WAY before I had an IBM PC clone, I built a 6809-based SBC with 4K EPROM, 2K RAM (IIRC, it may have been more, but not much), and three serial ports. I wrote a monitor program for it so I could enter code, in hex, by hand (later, I would write a cross-assembler on Concordia University's CYBER 835 mainframe in Pascal, that spewed out S1S9 records that the monitor could read).
One of the first programs (hand assembled at the time), was a "RAM-dialer": it would control the Hayes Smartmodem to repeatedly dial one of a set of numbers until it got a data connection -- see in those days most BBSes had one phone line. Bliss!
The pointer to a NUL-terminated sequence of chars is only sometimes a text string, you idiot. A char* variable may be pointing to a buffer of binary data, and I would be positively pissed if a > b did a lexicographical compare in this case.
*cough* void* *cough*.
I reiterate that char * is idiomatically used to represent the base of a C-style string, and is the type of string literals (which, admitedly, can be converted to std::string, easily enough, but then you run into exactly the problem to which you object). Perhaps you have never dealt with legacy code.
In any case, an existing program which overloads char* to point to various kinds of pseudo-opaque data already has the problem you describe -- defining operator>(const char *, const char *) makes them no worse. Not defining it, or defining it to throw an exception could catch this, of course, but you'll likely find that this causes you far more pain than type-safety, when dealing with legacy code which is already fast and loose, typewise. If the genie ain't gonna get back into the bottle, might as well learn to live with it.
That is not, of course, an argument to use this in new code.
This is so fucking lame. Again, if you have a const char*, there is no way to tell from the type : const char* that you have a string of text.
Guess what. There's no way to tell that a const Foo* points to a Foo, either, or that any pointer points to to ab object of the type claimed, or idiomatically implied. Casts are your enemy with regard to type-safety, and there are a million ways from Sunday to "fuck", as you would say, with the type-safety of a piece of code. <static_cast>, <dynamic_casr>, and <reinterpret_cast> help a bit, but RTTI makes code fat, and you aren't gonna make plain old casts go away.
If you're going to live with C++, it is important to realize that type-safety really is a myth, with the compiler serving as a watchful servant, rather than a draconian master: if you want to shoot yourself in the foot, you can. C++ offers you a multitude of fully-automatic weapons for the purpose as opposed to C's handgun.
Decades of history say that a char * is, much more likely than not, a pointer to a string (legacy C code written for compiler that didn't support void, excepted). Better to presume that it is, and try to remove the pesky exceptions when cleaning code up, than struggle against that inertia.
Your are correct about the first form of partial specialization. I wasn't thinking about this form because, as you said, it doesn't apply to functions.
Thanks for taking the time to follow up. I am equally guilty of having forgotten about the second form of template specialization you described, that is, where some template formal types are related to others.
You have to be careful with functions with the term specialization. The word is overloaded (no pun intended). It can mean (1) template specialization or (2) in dealing with overloaded functions, the compiler chooses the more "specialized" form.
Ah! This explains my failure to understand you at first (and, less charitably, think you completely wrong -- good thing I assumed we had a semantic disconnect, and discarded that unflattering opinion).
I still haven't verified whether full template specialization of non-member functions is supported. It (as would partial template specialization) be useful: what if you wanted to have multple alternate function implementations that did not vary as a function of parameter types (which overloading provides)? Sometimes, you really do want the compiler to pick the correct kind of Foo(), regardless of whether it is overloaded, formal-parameter wise. To wit: the instantiation of an overloaded (or not) non-member function depends on several types, only some of which may matter at run-time (those of it's parameters). In particular, the lack of partial template non-member function specialization prevents selection of different function implementations with identical parameter signatures to coexist at run time, or even be uniquely selected at compile time.
Of course, member template functions suffer no such restrictions. I suppose a workaround to simulate non-member partially specialized functions would be to encapsulate the function in a template class, and partially specialize that, as required. In fact, if the class provided a static () operator (Hmm. Are static member operators supported?), this would dovetail nicely:
template <typename T, typename U> class Foo
{ public:
static T &operator(){int i, U& u} {... }
};
template <typename T> class Foo<T, unsigned long>
{ public:
static T &operator(){int i} {... }
};
So, we could have::Foo<T, U>(7, u) ==::Foo<T>(7)
Dunno if that's legal. Time to ask my compiler and, if the result if fruitful, check the standard to see if it's portable.
Again, there is no partial specialization what so ever in his examples. Partial specialization involves pointers and references to unknown types. Of which there is none in the examples. Partial specialization does not mean part of full specialization.
WQe are not talking about the same thing. Consider the class template:
template <typename T, typename U> class X {... };
This can be partially specialised thus:
template <typename U> class X<int, U> {... };
and fully thus:
class X<int, long> {... };
or
template <> class X<int, long> {... };
though, technically the last example above is an explicit specialization, whereas the one above it is a full specialization.
You're talking about cases like
template <typename T> class X<T, T&> {... }
which are also partial template specializations.
But, I reiterate, you can't partially specialize member functions or non-member functions in the same way -- you can only totally specialize member functions and use overloading for non-member functions to similar effect. I recall that the syntax for non-member functions allows a fully-specialized template syntax to be used (instead of simple signature overloading), but I may be mistaken there.
The first would be a full specialization and the latter a simple overload. Something in my mind tells me that the full specialization function syntax is, in fact, legal, though I don't have the time to try it now.
See Alaxandrescu, Andrei, "Modern C++ Design", Addison-Wesley, New York, 2001, pp. 26-28.
Eh? The second line is a partial specialization syntax of the function template, that just happens to not leave any type parameters left -- that is, it is fully specialized, and equivalent to the last line.
You are correct that partial specialization does not exist for function templates, only class templates, of course, but that doesn't mean the syntax can't be considered. Perhaps I should have been clearer.
If partial function template specialization were supported via the intuative syntax, both would be equivalent.
At first glance, both are correct: the former is a partial specialization that just happens to be full, and the latter is classic full template specialization syntax. The latter was a part of the language first.
I have NO idea what the hell is going on unless I trawl through reams of
definitions to find out what the templates were set to and how the operator was overloaded
...unless you understand the types A and B, and the meaning of operator+(const A&, const B&).
If A and B represented arbitrary precision numbers, it would be perfectly natural to use operator+ for their addition.
The counter to your objection is that if you don't understand the types in a program, you've got no business messing with objects of those types. That is not an argument against user-defined objects or operator overloading, but one for proper architecture with no extraneous types or templates.
Basically, these mechanisms make it easier to use the implementation language to express code architecture and design pattern models -- programming at a higer level of abstraction if you will, but programming nevertheless. The trouble is that many so-called "programmers" lack the skill to do this and get miffed.
But partial application and closures are a extremely painful in C++.
Not surprising, since the two-level nature of C++, via templates is more of an accident rather than a design. There are better languages out there that support these facilities in a clean fashion.
Nevertheless, these are extremely useful and poweful techniques. Every language has it's "dark and ugly" side -- think about the macro hackery you need to support parallel arrays in C.
Indeed. The pointer to NUL-terminated sequence of characters is sooo idiomatically a string from the "C days", that it's probably more understandable to preserve that idiom than not. Heck, that's the only way to implement string literals without the use of an object, and we know how much we love our string literals.
I suppose if I were to implement the template, I'd have a greater member function that throws an exception when passed a pointer, with a partial specialization that works for pointers to chars (unsigned chars, const chars, const unsigned chars). The only grief with this approach is that you can't partially specialize non-member function templates and must resort to a class.
Look folks, it's called a function pointer. We've had those in "C" for a long long time, so don't act like you invented it.
A functor is far more than a "function pointer".
A functor lets you fix none, all, or some of the parameters that are to be passed to the function via the pointer to it. This has practial applications. For example, an editor with an "undo" function that dispatches based on queued functors of edit operations, can also implement the "undo" by mapping that queue of functors to a nre queue of functors that do the "undo"ing. Try doing that with a function pointer.
Also, because one has the opportunity to bind the function to it's parameters at different times, they don't all have to be known at the same time.
I've put functors to good use when dispatching encapsulated function calls with queues of functions to call when those calls result in later callbacks in a multithreaded system -- there being a relationship in the dispatched functors and the callback parameters. You really should read Modern C++ Design to develop an appreciation for these techniques. They aren't obvious at first.
Frankly, if you want to see what templates and partial specialization can really do, go get Andrei Alexandrescu's book "Modern C++ Design".
I second that recommendation. Any one chapter is worth the price of the book. I thought I was exploiting templates to the point of torturing my compiler. Boy, was I wrong!
Why should I care if the language makes it an object or a function as long as it does what I want when I call it?
If a function is a first class object, then you can (a) queue it for later execution, (b) manage an ordered list of functions for execution, (c) partially qualify the parameters for later execution, with the remainder specified at call (i.e. dispatch) time. Read up on functors some time.
This is a perfect example of how NOT to use the expressive power of C++.
Oh, I wholeheartedly disagree!
Any junior programmer I encountered who was interested in generic programming would get my greatest support, and gentle guidance. I might not permit his initial attempts in production code, but I wouldn't stifle his interest either. How the hell else is a programmer supposed to mature their art?
Yes, it's real easy to fuck yourself up a million ways from Sunday, and none of them good, when you try to exploit a language mechanism that provides a two level language, with selective binding, but the power is immense. Just look at the use of C++ template metaprogramming for compile-time optimization -- it solves the cost of abstraction problem.
The syntax sucks, of course, and that makes it hard to comprehend, but that's to be expected when the Turing completeness of a language facility comes not by design, but by accident.
Ideally, in any project architects define the desirable coding abstractions, senior programmers implement the support for them, and more junior programmers code using them -- there is no more need for a junior programmer to understand template arcana than there is for them to understand the building of glibc (which is a either a horrid abuse of make, or a beautiful hack, depending on your point of view -- xargs is your friend).
When you strive to reducing all the code your team writes to that understandable by the lowest common denominator of skill available, you compress the scale of productivity exhibited by your team members greatly. Given that coding productivities can vary by an order of magnitude within a team (some have said, this really isn't something you want to do.
Instead you should build layers of abstraction, including meta languages within your code, giving the difficult implementations to the senior members, and the simpler ones (considering also the abstractions you've built) to more junior ones.
Part of the problem with your complaint is that you continue to see pointers to NUL-terminated character arrays instead of strings, right down to your pseudo-Hungarian notation. The whole idea is not to compare pointers, but strings, with the pointer implementation of a handle to the first character of the string a string implementation detail, ideally hidden.
Well let me help ease your mind. Canadians, overall, and with exceptionally few exceptions, do not like or personally promote prison rape.
Ah, but they do! What else can one conclude if a province-run organization (the Ministry of Transport of Ontario) runs radio ads suggesting prison rape is an acceptable punishment for drunk drivers?
If you believe Canada, and by extention, the Province of Ontario is a free democracy, then surely this must represent the will of the people.
Either that, or Canada is not as free as one would believe, and the state can run roughshod over basic human rights. Either conclusion supports the fact that it is a vile place to live.
And, although this is only personal opinion, I would not like it if anyone, personally or through some agency, did. Those who I've asked recently appear to agree with me. So rest assured that a pro prison-rape attitude is not a commonly shared opinion amongst Canadians.
Then Canadians are at odds with the Government of Ontario. But, I do not see widespread complaint, as one would expect in the face of a repressive regime. Is fear of state reprisal so strong?
Whomever made that commercial should be deported, but once again, that's just my opinion. To sum it up, prison rape is very bad.
If it were a matter of a private party making such an ad, I would be less inclined to condemn the citizenry (though I have many other observations that cause me to despise Canada). In fact, I have a pretty thick skin when it comes to promotion of private views which I do not share. However, it is intolerable that the state should make light jest of the breaking of it's own laws. That suggests that application of the law is at the state's whim and that justice is not blind.
Also, I think you will be glad to know, that there are many Canadians who believe in ideas such as privatizing healthcare, changing the way that employment insurance and welfare work, and many other facets of how our government runs. I'm sure I could introduce you to a large group of social safety net hating Canadians as well.
Where the heck are they then? I have found little public opposition to socialism in Canada. Not beliving in walking away from a fight I served formally in the Libertarian Party of Canada (as an elected member of it's internal judiciary board, the Ethics Committee). However, I found that it was far more effective to leave and deny the leaches tax revenue from my earnings -- I was happier turning over less to the American government, evil in its own way, but far easier for me to stomach.
All opinions welcome, that's what makes democracy work. Vive le difference!
An opinion that the state should encourage, make fun of, or leverage, the breaking of it's own laws has no place in a civilized society. One may have the opinion that killing another is acceptable (and generally is, in very restricted circumstances, i.e. when one's own life is in imminent danger), and debate this. But to hold the opinion that murder, that is, the illegal taking of another life is acceptable, is an affront to the rule of law. The closest one can come is to suggest that certain actions that are considered murder, perhaps, should not be.
But the analogy here would be that prison rape should not be a crime, but an acceptable punishment, at least for drunk drivers. A society that silently accepts it's own democratic government's advocacy of such a view is definately sick.
I can also introduce you to people born in many other countries who are new Canadians who have a whole slew of differing and opposing ideas.
This does not fall into the realm of opposing ideas acceptable under the rule of law: arguing to change the law is one thing, but this is an argument to trample the law.
I've even managed to find people born in Canada with all sorts of strange variations on life. I'm sure I could find some people who live in Canada you would find less despicab
I remember the case. I am not suggesting that Canadian prisons are worse than their U.S. counterparts, but rather that the practice is so accepted that it is used as a deterrent in state-funded anti-drunk-driving radio advertisments.
That same Canadian judge should be equally appalled at the domestic situation.
Slashdot Mirror
Canadians don't believe in free speech.
<sarcasm> See, we're a tolerant bunch -- a ruling democratic majority decides what's right, and the rest tolerates it. How dare any undemocratic, intolerant, idiot spout satire?
Canada is the pinnacle of oppression, particularly of dissenting speech (just look at the list of banned books). Here, the art of white supremacist placing of "niggers" in their place, and the "noble" Nazi mission of removing "kikes", has been elevated to a sophisticated, peaceful, non-violent supression -- the victims here are not distinguished by race, or religion, but by intelligence and productivity, reduced to being tax-slaves to support the bloated state, and majority of welfare slackoffs. Many even buy the tolerance bullshit to the point of dying for lack of funds to pay for necessary surgery -- them having been taxed away for "health care". What kind of "health care" has waiting lists for diagnostic procedures that are not resource-starved (as opposed to organ transplants)?. What kind of health care system rejects living organ doners (kidneys, lungs) that are matches but not relatives? What kind of tax code encourages daycare for children and discourages one parent from staying at home (the decision should be a tax-neutral parental one)? Of course daycare is preferred to parental care: the earlier to brainwash the future tax-slaves, the better!
Only in (Quebec,) Canada can the Chief of the Cree nation be sued for libel for noting, truetfully, that the government flooded much of their property with hydroelectric development projects because it was "unflattering" to speak the truth.
Americans: want to see a nation of sheep? Come to Canada and watch. This is what you will get if you permit socialism to continue to creep in your nation. Canadian attitudes are a dangerous disease. Forget Iraq. Bomb the shit out of Canada, before you learn what nationalized health care is like, and pay 50% income taxes for "free" services you can't get because you were "rich enough" to pay the taxes to support them (read up on "clawback" in the Canadian tax code). </sarcasm>
I was born in Canada, lived 5-1/2 years in the U.S.A., and know who's got their act together. It isn't the "great white north".
Canada used to be rated #1 among the best places to live. It slipped to #8, and is now around #16. It's easy to live well when you live off the credit secured by the labour of tax-slaves. But, when the credit is maxed out, you suffer the consqeuences. For all its faults, stupidities, and excesses, the U.S. retains a far greater understanding and appreciation of liberty.
I'm not sure about present law, but until recently, in Canada, a marriage was not legal, unless it was consumated, the specific wording of the law requiring that "semen be deposited in the vagina", i.e. even mere intercourse was not sufficient to consumate the marriage.
Now it is equally interesting that Canada is in the throws of legalizing marriages among homosexuals, for many of the reasons you outine (i.e. there is no legal basis not to, and sufficient basis to require permitting it), so this consumation law is a bit quaint.
However, I am not aware that it has been struck down, or rescinded.
Of course, the U.S. action of nuking Japan can be considered terrorism... I suppose all war can be considered terrorism and vice versa, with the differences between the two terms largly legal and semantic. If you want greater evidence against the U.S. as "bad guy", just think of the carpet bombing of Germany. No argument.
But, getting back to the nuking of Hiroshima and Nagasaki... these were industrial towns, and fair game in a declared war. Same goes for the carpet bombing of Germany, though both could be argued to be excesses.
Still, there is a difference between an air raid siren preceeding the arrival of enemy bombers over a military town from a nation that has declared war, and the surprise of an unexpected attack, that indescriminately targets civilian, industrial, or military targets alike. The latter qualifies as terrorism in my book. It is not "fair play" as far as war goes.
The distinction between a "legal" war and a terrorist act, by that standard is murky indeed, and I would not debate whether the U.S. has played the part of terrorist. However, the victor gets to write the history books, and I find the U.S. record in the regard is no worse than any other nation with which they have had conflicts.
While I would prefer that the U.S. exit Iraq as expeditiously as possible, and Saddam Hussein and henchmen be tried as fairly as possible in an Iraqui milleu, it would be naive to think that the U.S. will not try to retain as much of a regional presence as it can get away with. Any other occupier would act similarly. But, even if the U.S. remains indefinately, I can not see this any worse than the previous regime, and certainly better for Americans (as long as they can stomach the stream of body bags).
I beg to differ.
Six Americans died in the U.S.A. during WWII when a Japanese balloon laden with explosives exploded when the unfortunate people found it -- Japan had been sending such balloons for a while, with the intent that their contents explode above or on top of American locations. With the exception of this one, they had no successes and abandoned the program.
Now, you could argue that this was not terrorism since Japan had formally declared war on the U.S.A., but the balloons, hitting random targets, were intended to frighten and demoralize the American citizenry, and show how far reaching Japan's offensive could get. I'd call that state-supported terrorism.
Frankly the term terrorism is rather silly: all war is terrifying and demoralizing the enemy via fear and uncertainty is a common tactic. The only difference between war and terrorism is that the former is initiated by a recognized state and the latter isn't. With state supported terrorism, even that line is becoming blured.
I ended up wall mounting an open-frame Swingline picked up on Ebay (while the frame is 19", it's designed to wallmount on studs 16" or 19" apart). I got some patch panels from Ebay as well, and some ordered direct from Leviton. The rack also houses a 32 port 100 Mb/s switch. Non-rackmountable hardware (DSL modem/router, and satellite multiswitch) were wallmounted on plywood panels.
The rack is mounted on the wall in the basement, with cabling access to the first floor, and access to the second floor is achieved via a Panduit raceway on the back wall of the attached garrage: the raceway ends at the wall between the garrage (close to it's peak) and an inside second story closet. From there it's s snap to route cables up to the attic and down each inside wall to modular and coax outlets.
One thing you want to watch for is that the rails are pre-threaded to accept machine screws. Otherwise you will need lots of nuts. The prethreading adds $$$ (as it isn't cheap to tap that many holes) but is well worth it.
At the time, RMS himself gave this lecture (very inexpensively, I might add: expenses plus a small speaker's fee), and while the FSF's legal staff is more qualified to address the legal ramifications of the GPL, it was a presentation I very much enjoyed.
Yes, life was brutal until someone got the brilliant idea of using columns 73 to 80 for card sequence numbers that the Fortran compiler conveniently ignored.
Beware the 029 card punch, for the CDC 6600 only liked cards punched on the 026 card punch. :D gets ya every time!
But, the beauty of the device is that it is silent and provides a great thin client for accessing content stored on remote servers in the home -- where the noisy fans and hard drives are.
Disclaimer: I work for ATI, closely with the chip on which the device is based.
In my last undergrad year, I had to take a course, "Advanced Digital Systems" (or something like that - Comp 426, IIRC), but the course included writing a hard disk driver for a small O/S (Flex), and was to be compared against a reference design.
Trouble was, there was no reference design, and I ended up getting coopted to write one over Christmas break '81-'82.
The 10 megger 8" hard drive we had was cool, though.
I didn't have a computer (yet), but it was a joy to type the appropriate AT commands from my MIME I video terminal (complete with lower case character set!) instead of having to dial the phone.
Before I had a real computer (a homebrew SWTPC 6809-based clone running Flex), and WAY before I had an IBM PC clone, I built a 6809-based SBC with 4K EPROM, 2K RAM (IIRC, it may have been more, but not much), and three serial ports. I wrote a monitor program for it so I could enter code, in hex, by hand (later, I would write a cross-assembler on Concordia University's CYBER 835 mainframe in Pascal, that spewed out S1S9 records that the monitor could read).
One of the first programs (hand assembled at the time), was a "RAM-dialer": it would control the Hayes Smartmodem to repeatedly dial one of a set of numbers until it got a data connection -- see in those days most BBSes had one phone line. Bliss!
Ah, the nostalgia of the early to mid 1980s.
I suppose the relative risks depend on where you live.
*cough* void* *cough*.
I reiterate that char * is idiomatically used to represent the base of a C-style string, and is the type of string literals (which, admitedly, can be converted to std::string, easily enough, but then you run into exactly the problem to which you object). Perhaps you have never dealt with legacy code.
In any case, an existing program which overloads char* to point to various kinds of pseudo-opaque data already has the problem you describe -- defining operator>(const char *, const char *) makes them no worse. Not defining it, or defining it to throw an exception could catch this, of course, but you'll likely find that this causes you far more pain than type-safety, when dealing with legacy code which is already fast and loose, typewise. If the genie ain't gonna get back into the bottle, might as well learn to live with it.
That is not, of course, an argument to use this in new code.
This is so fucking lame. Again, if you have a const char*, there is no way to tell from the type : const char* that you have a string of text.
Guess what. There's no way to tell that a const Foo* points to a Foo, either, or that any pointer points to to ab object of the type claimed, or idiomatically implied. Casts are your enemy with regard to type-safety, and there are a million ways from Sunday to "fuck", as you would say, with the type-safety of a piece of code. <static_cast>, <dynamic_casr>, and <reinterpret_cast> help a bit, but RTTI makes code fat, and you aren't gonna make plain old casts go away.
If you're going to live with C++, it is important to realize that type-safety really is a myth, with the compiler serving as a watchful servant, rather than a draconian master: if you want to shoot yourself in the foot, you can. C++ offers you a multitude of fully-automatic weapons for the purpose as opposed to C's handgun.
Decades of history say that a char * is, much more likely than not, a pointer to a string (legacy C code written for compiler that didn't support void, excepted). Better to presume that it is, and try to remove the pesky exceptions when cleaning code up, than struggle against that inertia.
Thanks for taking the time to follow up. I am equally guilty of having forgotten about the second form of template specialization you described, that is, where some template formal types are related to others.
You have to be careful with functions with the term specialization. The word is overloaded (no pun intended). It can mean (1) template specialization or (2) in dealing with overloaded functions, the compiler chooses the more "specialized" form.
Ah! This explains my failure to understand you at first (and, less charitably, think you completely wrong -- good thing I assumed we had a semantic disconnect, and discarded that unflattering opinion).
I still haven't verified whether full template specialization of non-member functions is supported. It (as would partial template specialization) be useful: what if you wanted to have multple alternate function implementations that did not vary as a function of parameter types (which overloading provides)? Sometimes, you really do want the compiler to pick the correct kind of Foo(), regardless of whether it is overloaded, formal-parameter wise. To wit: the instantiation of an overloaded (or not) non-member function depends on several types, only some of which may matter at run-time (those of it's parameters). In particular, the lack of partial template non-member function specialization prevents selection of different function implementations with identical parameter signatures to coexist at run time, or even be uniquely selected at compile time.
Of course, member template functions suffer no such restrictions. I suppose a workaround to simulate non-member partially specialized functions would be to encapsulate the function in a template class, and partially specialize that, as required. In fact, if the class provided a static () operator (Hmm. Are static member operators supported?), this would dovetail nicely:
template <typename T, typename U> class Foo { public: static T &operator(){int i, U& u} { ... }
};
template <typename T> class Foo<T, unsigned long> { public: static T &operator(){int i} { ... }
};
So, we could have ::Foo<T, U>(7, u) == ::Foo<T>(7)
Dunno if that's legal. Time to ask my compiler and, if the result if fruitful, check the standard to see if it's portable.
WQe are not talking about the same thing. Consider the class template:
template <typename T, typename U> class X { ... };
This can be partially specialised thus:
template <typename U> class X<int, U> { ... };
and fully thus:
class X<int, long> { ... };
or template <> class X<int, long> { ... };
though, technically the last example above is an explicit specialization, whereas the one above it is a full specialization.
You're talking about cases like
template <typename T> class X<T, T&> { ... }
which are also partial template specializations.
But, I reiterate, you can't partially specialize member functions or non-member functions in the same way -- you can only totally specialize member functions and use overloading for non-member functions to similar effect. I recall that the syntax for non-member functions allows a fully-specialized template syntax to be used (instead of simple signature overloading), but I may be mistaken there.
So,
template <typename T, typename U> void f(T t, U u) { ... }
void f(int t, long u)<int, long> { ... }
as opposed to simply
void f (int t, long u) { ... }
The first would be a full specialization and the latter a simple overload. Something in my mind tells me that the full specialization function syntax is, in fact, legal, though I don't have the time to try it now.
See Alaxandrescu, Andrei, "Modern C++ Design", Addison-Wesley, New York, 2001, pp. 26-28.
You are correct that partial specialization does not exist for function templates, only class templates, of course, but that doesn't mean the syntax can't be considered. Perhaps I should have been clearer.
If partial function template specialization were supported via the intuative syntax, both would be equivalent.
At first glance, both are correct: the former is a partial specialization that just happens to be full, and the latter is classic full template specialization syntax. The latter was a part of the language first.
The counter to your objection is that if you don't understand the types in a program, you've got no business messing with objects of those types. That is not an argument against user-defined objects or operator overloading, but one for proper architecture with no extraneous types or templates.
Basically, these mechanisms make it easier to use the implementation language to express code architecture and design pattern models -- programming at a higer level of abstraction if you will, but programming nevertheless. The trouble is that many so-called "programmers" lack the skill to do this and get miffed.
Not surprising, since the two-level nature of C++, via templates is more of an accident rather than a design. There are better languages out there that support these facilities in a clean fashion.
Nevertheless, these are extremely useful and poweful techniques. Every language has it's "dark and ugly" side -- think about the macro hackery you need to support parallel arrays in C.
I suppose if I were to implement the template, I'd have a greater member function that throws an exception when passed a pointer, with a partial specialization that works for pointers to chars (unsigned chars, const chars, const unsigned chars). The only grief with this approach is that you can't partially specialize non-member function templates and must resort to a class.
A functor is far more than a "function pointer".
A functor lets you fix none, all, or some of the parameters that are to be passed to the function via the pointer to it. This has practial applications. For example, an editor with an "undo" function that dispatches based on queued functors of edit operations, can also implement the "undo" by mapping that queue of functors to a nre queue of functors that do the "undo"ing. Try doing that with a function pointer.
Also, because one has the opportunity to bind the function to it's parameters at different times, they don't all have to be known at the same time.
I've put functors to good use when dispatching encapsulated function calls with queues of functions to call when those calls result in later callbacks in a multithreaded system -- there being a relationship in the dispatched functors and the callback parameters. You really should read Modern C++ Design to develop an appreciation for these techniques. They aren't obvious at first.
I second that recommendation. Any one chapter is worth the price of the book. I thought I was exploiting templates to the point of torturing my compiler. Boy, was I wrong!
If a function is a first class object, then you can (a) queue it for later execution, (b) manage an ordered list of functions for execution, (c) partially qualify the parameters for later execution, with the remainder specified at call (i.e. dispatch) time. Read up on functors some time.
Oh, I wholeheartedly disagree!
Any junior programmer I encountered who was interested in generic programming would get my greatest support, and gentle guidance. I might not permit his initial attempts in production code, but I wouldn't stifle his interest either. How the hell else is a programmer supposed to mature their art?
Yes, it's real easy to fuck yourself up a million ways from Sunday, and none of them good, when you try to exploit a language mechanism that provides a two level language, with selective binding, but the power is immense. Just look at the use of C++ template metaprogramming for compile-time optimization -- it solves the cost of abstraction problem.
The syntax sucks, of course, and that makes it hard to comprehend, but that's to be expected when the Turing completeness of a language facility comes not by design, but by accident.
Ideally, in any project architects define the desirable coding abstractions, senior programmers implement the support for them, and more junior programmers code using them -- there is no more need for a junior programmer to understand template arcana than there is for them to understand the building of glibc (which is a either a horrid abuse of make, or a beautiful hack, depending on your point of view -- xargs is your friend).
When you strive to reducing all the code your team writes to that understandable by the lowest common denominator of skill available, you compress the scale of productivity exhibited by your team members greatly. Given that coding productivities can vary by an order of magnitude within a team (some have said, this really isn't something you want to do.
Instead you should build layers of abstraction, including meta languages within your code, giving the difficult implementations to the senior members, and the simpler ones (considering also the abstractions you've built) to more junior ones.
Part of the problem with your complaint is that you continue to see pointers to NUL-terminated character arrays instead of strings, right down to your pseudo-Hungarian notation. The whole idea is not to compare pointers, but strings, with the pointer implementation of a handle to the first character of the string a string implementation detail, ideally hidden.
Ah, but they do! What else can one conclude if a province-run organization (the Ministry of Transport of Ontario) runs radio ads suggesting prison rape is an acceptable punishment for drunk drivers?
If you believe Canada, and by extention, the Province of Ontario is a free democracy, then surely this must represent the will of the people.
Either that, or Canada is not as free as one would believe, and the state can run roughshod over basic human rights. Either conclusion supports the fact that it is a vile place to live.
And, although this is only personal opinion, I would not like it if anyone, personally or through some agency, did. Those who I've asked recently appear to agree with me. So rest assured that a pro prison-rape attitude is not a commonly shared opinion amongst Canadians.
Then Canadians are at odds with the Government of Ontario. But, I do not see widespread complaint, as one would expect in the face of a repressive regime. Is fear of state reprisal so strong?
Whomever made that commercial should be deported, but once again, that's just my opinion. To sum it up, prison rape is very bad.
If it were a matter of a private party making such an ad, I would be less inclined to condemn the citizenry (though I have many other observations that cause me to despise Canada). In fact, I have a pretty thick skin when it comes to promotion of private views which I do not share. However, it is intolerable that the state should make light jest of the breaking of it's own laws. That suggests that application of the law is at the state's whim and that justice is not blind.
Also, I think you will be glad to know, that there are many Canadians who believe in ideas such as privatizing healthcare, changing the way that employment insurance and welfare work, and many other facets of how our government runs. I'm sure I could introduce you to a large group of social safety net hating Canadians as well.
Where the heck are they then? I have found little public opposition to socialism in Canada. Not beliving in walking away from a fight I served formally in the Libertarian Party of Canada (as an elected member of it's internal judiciary board, the Ethics Committee). However, I found that it was far more effective to leave and deny the leaches tax revenue from my earnings -- I was happier turning over less to the American government, evil in its own way, but far easier for me to stomach.
All opinions welcome, that's what makes democracy work. Vive le difference!
An opinion that the state should encourage, make fun of, or leverage, the breaking of it's own laws has no place in a civilized society. One may have the opinion that killing another is acceptable (and generally is, in very restricted circumstances, i.e. when one's own life is in imminent danger), and debate this. But to hold the opinion that murder, that is, the illegal taking of another life is acceptable, is an affront to the rule of law. The closest one can come is to suggest that certain actions that are considered murder, perhaps, should not be.
But the analogy here would be that prison rape should not be a crime, but an acceptable punishment, at least for drunk drivers. A society that silently accepts it's own democratic government's advocacy of such a view is definately sick.
I can also introduce you to people born in many other countries who are new Canadians who have a whole slew of differing and opposing ideas.
This does not fall into the realm of opposing ideas acceptable under the rule of law: arguing to change the law is one thing, but this is an argument to trample the law.
I've even managed to find people born in Canada with all sorts of strange variations on life. I'm sure I could find some people who live in Canada you would find less despicab
That same Canadian judge should be equally appalled at the domestic situation.