yuushi

These require some background in C++ before you pick them up, however.

It doesn't matter, optimized or not, the amount of work this entails is ridiculous. Writing a C++11 compiler requires intimate knowledge of the standard (which is a massive, hard to read tome), implementing pretty much all of the standard library from the ground up, and honestly, good luck writing all of that - that's all the containers (set, vector, list, map, unordered_map, multimap, unordered_multimap, forward_list, stack, deque, tuple), algorithms, time and regex libraries (chrono and regex), threading and thread models, type_traits and so on (actually, I just realized, they have it listed on the right hand side).

Honestly, it's worded very poorly. "Compliant with the latest 2011 standard (C++11)" suggests all of this. I have a hard time believing this isn't some kind of joke - there's literally no-one alive that could write all of this in the timeframe of a course.

I guess we'll just have to agree to disagree then. Perhaps you are a far more conscientious programmer than many out there; the number of buffer overflow exploits would suggest so. C++ doesn't make you immune to such things, but it does give you the tools to make such things less likely to occur. Further, I like compiler-enforced type safety. For when C was created, utilization of void* was a brilliant idea. Language design has moved on since then, and as much as many people really hate template-based C++ code, I honestly welcome it in comparison.

Except it has absolutely no type safety whatsoever. With modern-style C++, you can do the same thing in exactly 1 line:

  std::sort(begin(array), end(array), [](int a, int b) { return a < b; });

Versus:

    qsort(array, MAX_VAL, sizeof(int), compare);

With compare as defined before. I mean, sure, it's just sorting and it's a tiny example, but to me it shows a lot about why I prefer C++ over C: typesafety, readability, reduced possibility of buffer overflows, reduced possibility of segfaults based on incorrect element access, speed thanks to code inlining vs function pointers...

How is it strawman C? If you want to use qsort, which anyone who has used C for any amount of time has, it's something you've written many times.

And this is what I don't really understand. Python or Ruby are excellent in the domain you talk about, but I would always, always reach for C++ over C if given the choice. The C++ standard library for me alone makes this such a simple choice. A lot of C code to me just looks horribly ugly these days - stuff like:

  int compare(const void *a, const void *b)
  {
      return *((int*)a) < *((int*)b);
  }

Yuck.

Except the analogy to Python lacks one critical point: C++ headers and Python imports do not work in nearly the same way. Do not EVER use a "using namespace <foo>" in a header file; any code that #include's such a header will pull this in.

In .cpp files it's ok (and almost required if you're using boost, unless you want boost::foo:bar::type everywhere). It still requires a bit of thought, though.

Indeed. And there are numerous reasons why C++ code can be/is significantly faster; firstly code inlining for code that would be required to use function pointers in C (ala qsort vs std::sort), secondly, things such as expression templates for things such as Matrix libraries.

That being said, the section containing the proof is starred if I remember. I imagine most people, even those reading CLRS, skip over it.

I still use it as well. I didn't realise it was something people laughed at - WMP takes up too much screen estate, iTunes has far too much bloat, and I don't need a music player with the complexity and learning curve of emacs.

Even if it is a natural phenomenon, am I alone in thinking that it is still interesting?

He should be disbarred. Trying to sue the charities themselves, which aren't even involved in this squabble? Ridiculous. How anyone with a functioning brain could come to the conclusion that this is the best course of action baffles me.

I disagree heavily with your argument. If the student is struggling with fractions and long division, I don't think you can blame schools "pandering to the slowest student" for such a problem. If they are struggling so much with basic concepts, I'd have to argue that they are the slow students.

> We don't see these results in adults in other countries because they don't burn out their students at such an early age.

If you've looked at education in other countries, I don't understand how you can say this. Many places push their students far harder than the US (for example, Singapore, Japan, South Korea). Rote memorization is pushed far harder as well. How is the material that is taught any less "useless" in the eyes of students in these countries?

I think culture definitely comes into play here. I'm not going to say incompetent teachers don't exist or that there isn't too much bureaucracy in schools; there clearly is, however, laying the blame entirely at their feet is being dishonest. I think culture and parental expectations play a larger part than many people want to admit.

Yes, it is 1/3. Given a series of partial sums (which in turn form an infinite sequence), then if the infinite sequence converges to some number B, the infinite sum likewise converges to the same number B.

It's exactly like saying lim as x -> 1 of 2x -> 2. You don't write it that way. You write it as lim as x -> 1 of 2x = 2.