What I think is needed is lots of simple silly trivial examples. Similar to how spirit does it.
Yes, this is a great idea and is on my todo list. Although the tutorial is sprinkled with examples, it is not easy to find what you need without reading through the entire documentation.
Kinda how i learned spirit was just to compile all the samples, and slowly got familiar and comfterble with it.
Also, GIL can spit some really nasty error messages. Not your fault, but can be a little scarey.
I have some thoughts about this as well. It is possible to write a script that filters this giant error output and returns a much more compact and human readable error description. For example, replace the page-long description of an 8-bit rgb view with 'rgb8_view_t', etc. It is also possible to find the common causes for the errors and print them as hints. For example, if you pass the wrong view you typically get an error at a given GIL line. One could track common errors and manually add hints for them. A more advanced system could leverage the debugging power of other developers. For example, once you figure out and fix the error, you submit the error message along with an English description of what was wrong to a server. The next time you get an error, your script can check online for the error trace and give you a list of English descriptions of common causes... This script would need to be tuned for each compiler and platform, however. But it seems like a tool that many other boost libraries could benefit from. Just a thought... Any volunteers? Lubomir