How do you learn other C++ libraries?
I would like to hear your way and mindset about approaches or tools to learn various C++ libraries.
surely not everybody learns the same way (I'll share mine later), I'm sure there is valuable information which you can share to help improve the way to most effectively learn.
Let me first describe my problem:
Often learning code that somebody else wrote, I'm faced with so much frustration I just can't put the amount of frustration here into this post.
I usually first google out what is "the best library" for specific purpose.
Then often I just give up from "the best" and go explore alternative libraries, reason being search for better documentation as No1 or better looking/more modern/standard compatible code as No2.
then of course often there is no better library or better documentation, so I usually go back again and continue learn previous library because that's what according to google and other people opinions is *the best library*.
I don't want to criticize any library and it's documentation, but you will agree with me that only a small amount of libraries have good documentation.
now here is my way to learn code, (the question I often asked myself)
How do people learn huge code bases knowing that documentation does not cover all the code (or documentation is horrible)? Just *HOW*?
I come to conclusion long time ago that reading the actual code line by line is the way to go, although it's the hardest way.
Thankfully IDE can help you out by using "goto definition" and similar IDE tools.
also some of the code bases have good code comments, which are awesome way to speed this process up, usually there is no need for documentation in that case.
But problem remains the same as with online documentation and that is there very few libraries that have good code comments.
I see a lot of developers are against over commenting code, some will say:
I just can't believe majority would say that, then how the heck do you learn?
is reading code line by line, like if you're compiler truly the only way?
Another approach in addition to reading the code I use is this:
I have about 10K bookmarks in my browser, when I need some info that I was previously over but forgot detail I just go search my bookmarks, quick and effective.
otherwise google is your best friend, but yes googling out takes time, especially if library does not have big community. same applies to forums.
btw, I consider forums and mailing list to be way to slow for my learning pace.
Your tools
What are your techniques to learn? what tools you use?
what is you main weapon? (ie. mailing list, forums, google, IDE tools, team work, code samples, existing projects etc..)
surely not everybody learns the same way (I'll share mine later), I'm sure there is valuable information which you can share to help improve the way to most effectively learn.
Let me first describe my problem:
Often learning code that somebody else wrote, I'm faced with so much frustration I just can't put the amount of frustration here into this post.
I usually first google out what is "the best library" for specific purpose.
Then often I just give up from "the best" and go explore alternative libraries, reason being search for better documentation as No1 or better looking/more modern/standard compatible code as No2.
then of course often there is no better library or better documentation, so I usually go back again and continue learn previous library because that's what according to google and other people opinions is *the best library*.
I don't want to criticize any library and it's documentation, but you will agree with me that only a small amount of libraries have good documentation.
now here is my way to learn code, (the question I often asked myself)
How do people learn huge code bases knowing that documentation does not cover all the code (or documentation is horrible)? Just *HOW*?
I come to conclusion long time ago that reading the actual code line by line is the way to go, although it's the hardest way.
Thankfully IDE can help you out by using "goto definition" and similar IDE tools.
also some of the code bases have good code comments, which are awesome way to speed this process up, usually there is no need for documentation in that case.
But problem remains the same as with online documentation and that is there very few libraries that have good code comments.
I see a lot of developers are against over commenting code, some will say:
1. comments are obstacle 2. or even that there is no time for comments 3. or even worse: if you don't understand the code you should not be using it. |
I just can't believe majority would say that, then how the heck do you learn?
is reading code line by line, like if you're compiler truly the only way?
Another approach in addition to reading the code I use is this:
I have about 10K bookmarks in my browser, when I need some info that I was previously over but forgot detail I just go search my bookmarks, quick and effective.
otherwise google is your best friend, but yes googling out takes time, especially if library does not have big community. same applies to forums.
btw, I consider forums and mailing list to be way to slow for my learning pace.
Your tools
What are your techniques to learn? what tools you use?
what is you main weapon? (ie. mailing list, forums, google, IDE tools, team work, code samples, existing projects etc..)
Last edited on
There are usually a lot of quick and dirty youtube videos that break down a library or whole language in less than an hour. I usually do that just so I'm comfortable coding with whatever it is, then if there's any specific functionality I want to learn with it, I can Google the question and find if there's a function or something that does the trick. I don't often use documentation.
thank you for input zapshe, there are indeed good yt videos, I watch them too regularly.
I guess there are not many general suggestions about this topic because ie. people mostly will use all sorts of material and use any means available just to get the info they want, meaning it depends from library to library what kind of meterial or tools will somebody use.
I guess there are not many general suggestions about this topic because ie. people mostly will use all sorts of material and use any means available just to get the info they want, meaning it depends from library to library what kind of meterial or tools will somebody use.
I hate videos personally. I can speed read and I can read about 5 pages of text in the time some goober can read a paragraph out loud. Its painfully slow.
I learn most libs by getting their example code working and then poking at it to exercise the tool. Huge stuff is more involved, eg boost, where you can do it the same way but the rabbit hole of this thing needs that thing needs another thing needs something else makes it hard to play with the functionality you need due to the custom types it was made from getting in the way. For those kinds of things, you just have to dig in and study for a long time to make sense of it.
I learn most libs by getting their example code working and then poking at it to exercise the tool. Huge stuff is more involved, eg boost, where you can do it the same way but the rabbit hole of this thing needs that thing needs another thing needs something else makes it hard to play with the functionality you need due to the custom types it was made from getting in the way. For those kinds of things, you just have to dig in and study for a long time to make sense of it.
I usually set them to about 2x speed and skip through half the video to see the application of a specific function or such. When I do read documentation, it's the nice kind. But a lot of times I find it to be wordy and just fluff. Half of it can't even be understood sometimes.
There's nothing wrong with comments, but in general they should explain why something is happening, not how something is happening. If you can force the "comment" to be part of the language itself -- e.g. a good function name -- then that is even better.
For example, if I see a check that says "if (x != null) { ... }". I can see that we're checking x against being null... but a better question is why are we doing this? What bug was this piece of code a fix to? What crash or bad behavior are we trying to avoid? What "gotchas" should I be aware of when editing this piece of a code a year from now, because something else broke? Sometimes it's obvious, other times it's deceptively not obvious; making clear code that other people can understand is hard. It's an art.
When writing comments, I would err on the side of a bit too much information, personally. But the problem with comments is that they can become outdated. I see others that edit a file but then don't update the comment at the top of the function, and over a few commits, the comment, class name, or function name starts to become misleading. A comment is another form "thing that needs to be maintained", and only through experience can you develop a judgement as to what's appropriate or not.
I generally don't need to look at source code to understand a library, though. A library should have documentation on their website that can either be viewed online or downloaded. e.g. MSDN. For libraries where I can't figure out what's happening even after reading the documentation for the element I'm trying to use, I will search the web for examples, and usually find some forum. For less popular libraries, the harder it is -- that's when you sometimes have to dig into the code itself. And for that, I will usually start at the library function call I care about, and then use tools like grep to search for library-related keywords that might give hints as to what's happening.
For example, if I see a check that says "if (x != null) { ... }". I can see that we're checking x against being null... but a better question is why are we doing this? What bug was this piece of code a fix to? What crash or bad behavior are we trying to avoid? What "gotchas" should I be aware of when editing this piece of a code a year from now, because something else broke? Sometimes it's obvious, other times it's deceptively not obvious; making clear code that other people can understand is hard. It's an art.
When writing comments, I would err on the side of a bit too much information, personally. But the problem with comments is that they can become outdated. I see others that edit a file but then don't update the comment at the top of the function, and over a few commits, the comment, class name, or function name starts to become misleading. A comment is another form "thing that needs to be maintained", and only through experience can you develop a judgement as to what's appropriate or not.
I generally don't need to look at source code to understand a library, though. A library should have documentation on their website that can either be viewed online or downloaded. e.g. MSDN. For libraries where I can't figure out what's happening even after reading the documentation for the element I'm trying to use, I will search the web for examples, and usually find some forum. For less popular libraries, the harder it is -- that's when you sometimes have to dig into the code itself. And for that, I will usually start at the library function call I care about, and then use tools like grep to search for library-related keywords that might give hints as to what's happening.
Last edited on
| I hate videos personally. |
"Learning to program" videos have the all the drawbacks of sitting through a boring lecture without the benefit of being able to ask questions.
| How do you learn other C++ libraries? |
I am a programming hobbyist. For me learning a C++ library is for the most part about using it. Not how it is put together at the source level.
This C++ document ( http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3551.pdf ) has the idea for a simple library source I have looked at and modified for my own use.
I am not against poking around in library sources. Most are simply beyond my current capabilities and understanding. I might as well be looking at some ancient Cuneiform text.
my flow chart tends to be
- find a free library (if none, evaluate whether spending money is worth it)
- grab examples if examples do not work, goto step 1 for a different lib
- make example do what I wanted to do. if unable, try web search and docs
- if unable to get it going, goto 1
I almost never look into the code. If there is nothing else out there and my tinkering got me close enough, I may. if I go into the code, though, its usually with an axe. I am going to chop and glue to make it work, branching the library into my own copy. Most of the time, this is something simple like granting access to a private variable or something that I want to see but the author didn't think I would want it.
- find a free library (if none, evaluate whether spending money is worth it)
- grab examples if examples do not work, goto step 1 for a different lib
- make example do what I wanted to do. if unable, try web search and docs
- if unable to get it going, goto 1
I almost never look into the code. If there is nothing else out there and my tinkering got me close enough, I may. if I go into the code, though, its usually with an axe. I am going to chop and glue to make it work, branching the library into my own copy. Most of the time, this is something simple like granting access to a private variable or something that I want to see but the author didn't think I would want it.
Topic archived. No new replies allowed.