Recently infected? Feels more like a primordial specimen that couldn't step out of the initial pool.

No, they don't. They take an aggregate of a singular shared opinion by some set of like-minded people, but they don't represent an aggregated set of opinions. Note the plurality in opinions.

Petition sites such as change.org or even the White House's site are not democratic in nature and they should not be construed as "votes" from the voting populace. First, there is no guarantee the signatures are valid or even from the US. Second, there is no mechanism to vote against, or to otherwise say something to the effect of "no, I think this is a bad idea". So, you only measure the yeas, but have no meter of the nays. For argument sake, and assuming rough numbers: White House is requiring 250,000 signatures to consider a petition? US estimated 2013 population is 316,128,839. So, that ends up being 0.079% of the population needs to ascent to the petition to be considered, with no way to voice countering options or dissent, except with an opposing petition. Personally, I think a better mechanism would be a vote up/down mechanism and consider the net. Yes, I recognize only recording the yeas is the very nature of a petition, but I think the way these petitions are being represented is more as an opinion poll of what *everyone* wants, which is not true. If that's how you're going to represent it, you should give everyone an opportunity to actually express their view, not just that of those that are reinforcing your opinion/view.

I, personally, define bad code (in this context), from the perspective of code generated by the compiler, as code that does not perform in an expected manner as dictated by the higher-level language lacking any sort of unspecified or undefined behavior failing to produce the expected result. In a most ridiculous example, if I had int i = 3 * 7; printf("%d", i); and anything other than 21 was output, there's some bad code present. Suboptimal does not mean bad or erroneous, if it produces the correct result. Suboptimal but correct would be a target for manual inline assembly optimization, if it is sufficiently inefficient. Bad with incorrect result might also be a target for manual assembly if a resolution from the compiler vendor could not be completed, or would otherwise be unfeasible.

Definitely correct, and an oversight on my part. To my part, I've not first-hand observed a compiler generating bad or erroneous code, but was more thinking back to Linus's recent tirade about GCC 4.8. When I have seen the compiler behaving badly, it's usually been in the form of internal compiler errors. When I do encounter these, I do as much research as I reasonably can, and try and distill a minimal reproduction. Last such ICE I saw was in GCC 4.1.2 a few years ago (yes, my employer at the time was that far behind). The Ops team wanted to push a "small" update to my dev server, which I think was running Rhel 5.4 at the time to fix a completely unrelated issue. After the update, I noticed it also updated GCC to a newer point release of 4.1.2 and an unmodified code base started to fail with an ICE. A bit of investigation narrowed it down to, in C++ code, defining an anonymous namespace at the global scope (perfectly legal, but caused an ICE in that particular GCC version). Turns out it had already been reported, fixed and already released in a later version, so my Ops team had very little work to do to fix it.

If you have the time to write the algorithm in assembly, then you have the time to write it in the high level language (I'd imagine for anything but the most trivial of operations, you're probably looking at a minimum of 5x-10x longer to write and verify the algorithm by hand in assembly vs C or C++. I'd also wager my estimate may be an order of magnitude or more low. I'd also expect a large variance in the extra time relative to the experience and familiarity of the architecture of the developer/engineer doing the inline assembly.). The additional benefit of this, as you mentioned, but I failed to: is that you have it there for regression/comparison (assuming, of course, the compiler is generating functionally correct assembly, to begin with). Additionally, having both the assembly & high level implementations affords you the ability to quickly, if sub-optimally, support new architectures.

I disagree with nothing you've said here, or in your initial reply to me. One word of caution: I'd discourage mixing inline assembly with "regular" C/C++ code. Most compilers (last I've looked) immediately bail on attempting to optimize any function that contains inline assembly. I honestly don't know if you have an inline asm function how that plays in - it's just not something I deal with regularly. Last time I wrote/modified any inline assembly was to correct a x86->x64 compatibility problem roughly 6 years ago.

What do you think intrinsics are? They are nothing but very thinly wrapped C functions, often marked inline, over the underlying instructions. The major downside here is you have no choice over register allocation, if you're making a number of calls, this could become an issue.

This is generally true, but when you've measured and proven the compiler is generating sub optimal code, it may be time to hand-optimize in assembly. Compilers don't always generate better code than a human. In general, if you have performance critical code, I find it better to write it in C/C++ first, then examine the compiler optimized assembly. IIF it is shown to be sub optimal, then you optimize by hand. Compilers are also finicky. One algorithm it may optimize it well, but make a slight change in a high level language and sometimes the compiler optimizer gets confused and generates horridly different and rather un-optimized code. Different compilers may also optimize differently, so it may be ideal to do the assembly by hand to get uniform performance across compilers. In general, if performance is *that* critical to you, you need to examine by hand those critical sections to verify the compiler is doing what you expect it to do. This isn't even to mention that compilers target the lowest common denominator of the architecture you specify. i.e. if you target x86, most compilers will not utilize any SSE or SIMD instructions unless separately and explicitly enabled.

There are days where I do not have mod points, and this ^^^^^^^^ is it.

Before I posted this, I read through the roughly 60 posts that were here. If your child is interested in the lore and mechanics of gaming, I think the prime focus should be on creativity and writing. I don't think you can necessarily "teach" creativity, but I think you can encourage it. I would probably suggest a lot of reading of fiction from as great an expansive base of styles and genres as you can. Through exposure to a variety of material, they may find something they like and build/expand upon something they like. Very little is truly a brand new idea. Most fiction is an adaptation/twist/extension on a previous idea.

If your kid wants to both write the story behind the game and the code that makes it happen, large AAA games are not what you want to strive towards. There tends to be a strict separating of responsibilities.

If your child is insistent upon that, as far as development goes, a large number of people have already post some great links to development resources. A lot of those may be over the head of a child, though, let alone a seasoned non-game developer./p?

Personally, my inclination to watch "the Interview" increased more and more as the hacking went on and on. I am disappoint that I will not be able to see it likely now, in the theater. I will, however purchase it, in the very likely soon DVD/BluRay release.

I don't have a problem with a long/lengthy article being broken into a series (so long as there's a view as single page). Lately, I've gotten my choice Dobbs articles via redit & RSS, and they come in as just "Part 1", Part 2", etc. Not even "Part 1/9". I understand that, because they're probably publishing them as they receive them/write them and arguably don't even know how many parts there will be (which is probably due to an arbitrary editorial decision of number of lines/paragraphs). But, what I want is: on a 30-minute train ride, can I digest an article, not can I read a 5 minute snippet, then remember where that snippet left off a few weeks ago, and then a few weeks further yet remember those previous 2 snippets I read. I can really get behind a multisegment such as "we're going to design a scripting language interpreter", and every section is a logical conclusion of a part of it. But to beak mid-stream as a lot of the newish articles seam to do in order to "make you come back next week" is asinine and extremely frustrating from a user perspective, especially from a software developer perspective. I have this problem *now*. I do not want to come back next week to see how the second have can be solved.

From a C++ perspective, the only lately useful articles are from Andrew Koenig, but how the release of the articles is done has pissed me off so much I removed it from my feeds. His most recent article series, is at part 9: Abstractions for Binary Search. How about write an article that can be released in a single piece and consumed as such. Trying to consume parts of something every few weeks is an ineffective learning tool. There doesn't seem to be any more single articles. The interesting ones are broken up into multiple parts released every week or two. FUCK THAT. Give me an article that I can read, start to finish. Don't make me come back next week. I'm a developer. I'm already being torn six ways to sundown by various issues, I don't need a publication compounding that. Give me single, solitary articles that have all the content in a single page and I'm happy (it also makes the googling easier).

This is not true, at least not initially. And your example of LLVM (and clang) completely disregards its history. LLVM/clang are only relatively recently self-hosting (can be used to build themselves). LLVM & clang are written in C++ and for a long time relied upon an external C++ compiler (typically gcc) to be built.