4 ms·
When I was doing heavy common lisp work, this was just a non-issue. If I wanted to understand how a library call would perform, I'd just press the magic button
by MichaelSalib 14y ago
When I was doing heavy common lisp work, this was just a non-issue. If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look.
This was much easier than manually tracing through the layers of template and preprocessor indirection underlying even simple STL constructs.
It is possible that this sort of standardization was vitally important given the incredibly poor quality of C++ implementations traditionally available, but in languages with better communities with higher standards for implementations and documentation, this really seems like a solution in search of a problem.
- Someone 14y ago"If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look." That tells you how your implementation works. It tells you nothing about how other implementations (or the next version of your compiler) do things. The point is that, with C++, the standard proscribes the O(...) of algorithms. Yes, implementations can and will be broken, but given that writing a C++ compiler requires planning, I think it is unlikely that 'wrong choice of algorithm' will make it into any deliverable (counterexamples welcome)