I was able to use my experience implementing C++ name lookup rules to make a less complex one for D:<p>There's no notion of a "primary" template. Templates are looked up like functions are.<p>C++ has rather complex function overloading rules that differ substantially from template overloading rules. The former is a hierarchical list of rules, the latter is based on partial ordering. D uses partial ordering for both.<p>D doesn't need argument dependent lookup, because it has modules.<p>D lookup sees all the declarations in a module at once, not just ones prior to the point of use.<p>The end result works pretty much the same, and hardly anyone notices the difference. Except for that last point - in C and C++, the order of declarations is inverted. The private functions come first, the public ones last, because lookup is dependent on the lexical order. D code is written with the public ones first, private ones last.
I usually try to get away with reading as little of the manual as possible until I absolutely have to. Articles like this really help cavemen like me because this is leaps and bounds better than reading the actual c++ standard!
C++ resolves certain kinds of tricky function calls via a remote procedure call that sends an SMTP mail to the ISO committee, and waits for a reply. (It's compile time though, no biggie.)
It's curious how the C++ standard is written with a bunch of rules, rather than an algorithm. The algorithmic version in the article is much clearer to programmers. You'd think the C++ standards committee would write the standard for programmers instead of for -- I don't even know who it's for. Bureaucrats? Tax lawyers? SF Zoning regulation enforcers?
What has always fascinated me of C++ is how incredibly complex, yet wild, it is. You can do basically everything, you can create horrible monsters and discover beautiful patterns backed by strong type safety. It might not be for everyone, but yet I find it can be as rewarding as it is frustrating. You always learn something, and you can always dig yourself out of any hole, it just requires effort and skill.
Unrelated to C++, but the diagrams (svg) looks nice. Are these created from text format or via some diagram tool, because if it is from text, it's nice to use in architecture diagram (asciidoc/markdown), etc and version control with git.<p>PlantUML works well for sequence diagrams, but for the rest, the output is not pleasing to look at.
Advanced function resolution technology is one of the main reasons I use C++. The combination of being statically typed yet allowing users to create elaborate function dispatch hierarchies is unmatched.
Rule of thumb: If your code has ambiguities that make you reach for the details of name resolution rules, or depend on some finer point within them, then - seriously consider differentiating the names.<p>In the example in the article - I would go to some trouble to avoid having both:<p><pre><code> namespace galaxy {
void blast(Asteroid* ast, float force);
}
</code></pre>
and<p>template <typename T> void blast(T* obj, float force);<p>either blasting asteroids happens in the context of galaxies, or it doesn't. If there are _different kinds_ of blasting of asteroids - very well, make that explicit.<p>Also,<p>bool blast(Target target);<p>would be somewhat confusing, since people may expect `blast()` to not return anything and will neglect to check the returned value. And wouldn't it make more sense to just have a default amount of force for the blast? ... again, if it's a different kind of blast, don't name both functions the same.<p>PS:<p>* "Better is a good name than fine oil" (that's a biblical proverb).
* Don't be a smart-ass when naming! You'll smile for a second, others will cry for years.
* Don't be stingy with a few more characters in your name - we can handle it.
> , it should at least be possible to implicitly convert each argument to its corresponding parameter type.<p>Oh no! You just got burned (maybe). Make sure you turn on your compiler's warnings to find bogus-but-legal implicit conversions.
This is a good article in terms of context, but I found it much easier to understand how C++ does class functions when I first saw this in a disassembly output. I guess I'm a more visual learner that has a fairly hard time following a lot of text.
Or use a good IDE which would have something like "right click -> jump to declaration" and it will show you what/where the function is implemented. Or at least that's what I do to keep up my productivity instead of wondering at the marvels of overloading / namespaces that export same function names.