Yeah, the interview doesn't exactly paint her in any better of a light than people already hold her in. In her own words she basically states she's racist and sexist with a possible religious bias:
“Not too bad,” she said. She thought more and shook her head decisively. “He’s a white male. I’m a black Jewish female. He was saying things that could be inferred as offensive to me, sitting in front of him.
(emphasis mine). The way that's phrased, to me, states that she was not offended, but chose to manufacture offense via the photo & tweets, and that resulted in real world damage to peoples lives. Not just to the two men, but their families, as well.
While I do think that a lot of the stuff that was done and said to her after this incident are despicable, it doesn't make her any less of a hurtful, spiteful, vindictive, hypocritical, hateful excuse of a human being. Additionally, her comment about Downs Syndrome is just...disturbing.
Section 10. Prohibited inquiry. (a) It is unlawful for a post-secondary school to request or require a student or his or her parent or guardian to provide a password or other related account information in order to gain access to the student's account or profile on a social networking website or to demand access in any manner to a student's account or profile on a social networking website.
That seem's pretty straight forward: it is unlawful to request or require dissemination of a password.
What I suspect you object to is this:
(2) monitor usage of the post-secondary school's electronic equipment and the post-secondary school's electronic mail without requesting or requiring a student to provide a password or other related account information in order to gain access to the student's account or profile on a social networking website.
What I read this to mean (and I'm not a lawyer, of course), is without approval or consent, they may monitor school-provided equipment and provided email. i.e., if you utilize your school's email service, they may read that at will, without your consent. Note the possessive in "post-secondary school's electronic mail". This seems pretty plain to me they are not allowed to monitor, say your gmail access (unless they have a man-in-the-middle setup and you access it utilizing the school's network, read: electronic equipment).
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.
This is usually just plain wrong. I have extremely seldom ever seen "at" used in production code. Why? Because it's usually duplicating a bounds check you've already done. If you're going to naively randomly access a location into a vector without checking if it's within bounds, sure, but that's kind of a nasty smell (also, are you handling the exception that may/will occur?). Most vector accesses occur something like looping from 0 until (but not including size), or using begin/end (either the free functions or the members). At best, the optimizer might be able to deduce you're never modifying the size of the vector during a loop and elide the repeated bounds check. At worst, you're evaluating "if ((_M_end - _M_start) <= i) throw std::out_of_range();" on every iteration.
Regarding point #4, forward declarations aren't to save compilation time or declare linkage. Yes, they can be used to do both, but the prime function is to, well, declare a name and just enough information to be somewhat useful before it is used (i.e. reduce very simple otherwise circular-references). I can forward-declare 'struct A', but I cannot instantiate/allocate it until it is defined (need to know the size, layout, etc.). You can declare a pointer to 'struct A', because well, you know the size of the pointer. Same reason you can't define "struct A { struct A a; };", but you can define "struct A {struct A* p_a; };".
Regarding "#ifdefs", yeah, there shouldn't really be a need for them in this day and age, but they won't go away due to legacy code. If you removed them, you'd break every single codebase in the world. Not going to happen. Additionally, due to the historical lack of variadic macros, there are numerous libraries that rely upon multiple inclusion of the same header to fake variadic macros. If you assumed a "#pragma once", you'd break various Boost libraries as well as even some STL implementations. Headers guarded with ifdef's can only safely be precompiled and reused if any and all preprocessor defines referenced are identical across all usages and inclusion order of every & all predecessor headers is exactly the same for all usages, otherwise you very well may violate the one-definition-rule.
Stellar rays prove fibbing never pays. Embezzlement is another matter.