Is reading library implementations a wasted or well spent time ?

Question

I'm reading STL and Qt implementation now. The bits I need. And I ask question about things I don't understand. And I get some negative comments about that.

I consider it a well spent time. In both cases I'm learning usable idioms. If some code seems to be overcomplicated (very often the case) I learn the reasons of it. I learn how to design new classes that will work well with a particular framework.

I takes a lot of time and of course I can understand that I could spent the time coding or reading some stuff on the net on the subject.

Do you read library code or is documentation enough for you?

Answer 1

I read library if I'm interested in how I may implement something similar myself, but I think it's not too useful to simply "read library code". It all depends on how useful it will be.

The other problem is that you may be reading code that isn't necessarily the be all and end all of how to do it.

STL is quite horrid to read IMO :P

Answer 2

I read library code more for a look at how other's write code, and if there are ways to improve my code or in some rare cases the library code. Also, you can gain an insight into better ways to use the code based on the underlying implementation.

I think that it definitely helps you understand some fundamental programming foundations in a practical matter. However, I think a good book would be a fine addition to reading the actual code in the library. The book will give you concepts and theory as well as some practical application in a much easier to understand as well as being more quickly comprehensible.

Answer 3

Is reading library implementations a wasted or well spent time?

I once spent many months writing an assembler and text editor in assembly: was that time wasted, or well spent?

Do you read library code or is documentation enough for you?

I do (or have done) both, but there's much more code for which I've just read the documentation than whose implementation I've read.

I read books too: which are (unlike code) specifically designed to teach techniques.

Answer 4

There is plenty to learn from studying the implementation of a (well-written) library. But read it for learning purposes, not as documentation.

In the case of the STL (which you asked about before), you should never rely on its implementation details in your code. Your previous question implied that you were reading the source code because the documentation "did not provide enough information", and in those cases, no, you're wasting your time. Or even worse, you're actively sabotaging your code by relying on implementation details that are not guaranteed by the library. And that's why you got negative reactions. The STL is carefully designed so that the documentation tells you everything you need to know, and to allow flexibility for the underlying implementation.

So (at least for a well-defined standard library like the STL), feel free to read the code if you think you can learn from it as a programmer. But don't rely on it as documentation.

With less well-specified libraries, it may be necessary to study the source code in order to use the library.

On a side note, typical STL implementation code is not written to be pretty, or to be "good C++ code".

Keep in mind that:

• It is (usually) written with a specific compiler in mind, so it can rely on non-portable extensions and implementation-defined behavior that normal C++ code should not rely on
• It is not written to be read, or to be readable. Once again, the one and only authoritative source of information about your STL implementation is the documentation (most of which is defined in the C++ standard).
• A number of special rules apply for the standard library (not just the STL) - parts of it should be available in both the global namespace and std. Parts of it must be callable from C as well as C++. All identifiers used must be taken from special classes of names (generally, leading underscore followed by capital letters, or double leading underscore), to avoid conflicts with names defined in user code.
• They have to react to a number of #defines and configuration options (for example MSVC allows the user to define _SECURE_SCL, _HAS_ITERATOR_DEBUGGING and a number of other macros to control iterator checking, optional bounds checking on vectors and a number of other features.

STL code is typically not pretty, it is not what you should consider well-written code (or at least, if you wrote that kind of code in your application, your code would not be well written. As shown above, the STL implementers had a very different set of requirements than you, as a user of the library)