Zao

If you want to do runtime x86 and x86_64 code generation properly (and yes, there's use cases for it), I would recommend using Xbyak. Nice little C++ DSL to generate machine code at runtime, complete with labels, jumping to them and all sorts of nice stuff.

Let's state in plain text what the outer shell of the algorithm does:
For each offset i in the string - take successively larger substrings of even length from that offset, until the end of the string is reached.
i is the left index of the substring, inclusive.
j is the right index of the substring, inclusive. j+1 is the right index of the string, exclusive

We cannot immediately use j in our expressions, as we want to both find out if a substring is even and the substring(off,n) function takes an absolute count n of characters.

We can set up an equation to find the length from i and j, looking for "what number must we add to i to get the index of one character to the right of j":
i + len = j + 1
len = j + 1 - i
len = j - 1 + 1

It will most likely make you less desirable for some people and/or studios, compared to an unadorned human. Get the wrong interviewer and you might be racking up some negative points due to their personal opinions and ideals, even subconciously.

In general though, this industry tends to be quite used to strange-looking misfits. Just look at the people in an average art department and you'll see lots of strange stuff.

Although if new things are never tried, nothing is ever advanced.

Trying arbitrary permutations of things without a decent mathematical foundation is not only unproductive, but counter-productive as you cannot really reason about the behavior and properties of the "approximation" you have produced.

This reflects in your confused statements (now some edited away) about just simply applying scaling factors and misuse of terms.

Things like the Carmack sqrt approximation have a foundation in mathematics and architecture (Newton-Rhapson iterations and IEEE754 vs. integer interaction), while your approach just substitutes a function with something with completely different properties and proclaim it to be The Next Best Things without a proper analysis of it.

Heck, a simple mesh plot of your function would have revealed the massive oscillations and regions of infinite results.

Could you please "normalize" the two vectors <1,0,0> and <-1,1,0> for me?

Long story short, name lookup rules do not care about access. Only after a name is found is the access considered, and then it's too late to do anything about that the name is unusable. If you want to refer to the type, either qualify it explicitly or consider using protected inheritance (which I believe will be sufficient to provide access to the typename).

One interesting thing about this kind of lookup is that MSVC10 will allow your use of a private base in a class template, but Intel 12.0 will not. If you want to be portable, you should therefore qualify typenames that occur in a base.

With the usual three matrices of world/view/projection, the view matrix is used to orientate and place the camera relative to the world, while the world matrix is used to orientate and place objects in the world. It's all just convention though, the math turns out the same way.

I would personally go with modifying the view matrix as you typically have one world matrix per object, but only a few view matrices in total. The imprecision that KulSeran outlines can be worth having in mind, but for game worlds of reasonable scale, it's generally not a problem.

An alternative to a template project would be to make a Property Sheet, which is a collection of project settings which when added to a project augments or overrides the base settings for the project.
I have property sheets for the most diverse of things, from things like adding include directories, library directories and libraries for third party libraries to things like changing the runtime library variant, changing the output directory, adding common sets of preprocessor definitions, etc.

Near the Solution Explorer pane, you have a Property Manager view where you can modify and add property sheet files to a project.

As some may have hinted to above, the default comparator for a std::map is std::less<Key>, which defaults to operator <, which for pointers just compares addresses.
As mentioned, string literals may be folded together in static storage, ending up comparing equal by coincidence.

The proper solution here if you really must use char const* as your key is to provide a comparator to your std::map, which would do a string comparison with strcmp or a similar function.
Of course, by using raw pointers you run into ownership issues, as you have no way of properly handling the memory the pointers point to. Changing the key type to std::string would most probably be a Good Thing.

Note that operator [] on a std::map default-constructs a value if the key could not be found and inserts it into the container. If you do not desire that behavior, use the find(key) member function which returns an iterator to a key-value pair if the key was found, or the end() iterator if it was not found.