Steven T. Hatton wrote:
How would one typically (correctly) include such a library in his code? If I follow K&R 2nd. Ed., they put the #includes for libraries in any .c file that relies on them. Is that technically necessarily? From my experimentation, id doesn't /seem/ to be necessary. All that is required to get the code to run is that the one of the header files referenced in the .c includes the particular library.
It's not necessary but sometimes makes the code easier to read. Most headers use soemthing like #ifndef CCXX_MISC_H_ #define CCXX_MISC_H_ ... #endif so that if you #include the header more than once, after the first time, the preprocessor will just ignore the content of the header file. Since this is exactly what's in misc.h (header for ost::stringTokenizer), you can include it as often as you like. So #including it more than once is not technically wrong (i.e. it doesn't depend on the compiler to do anything special). I personally tend to use #includes even where they're not needed just for readability: it's a way of saying this class needs something from misc.h even if it's not explicitly stated.
But 'technically' correct, and stylistically correct are not the same thing. What is the prefered /style/?
Is this CommonC++ library really common? If I put it in my code and distribute it, will a bunch of people curse me? Is it the best bag of trick to draw from for general functionality such as string tokenization. I'm writing for a QT/KDE environment.
If there's something in QT that works better, I would use it on the grounds that the more class libraries you use, the greater the chance one won't compile. On the other hand CommonC++ is probably easier to get on any platform than Qt is. Sadly, I didn't know about this class a couple of years' ago when I had to tokenise some input. It could have saved me some work and a buffer overrun. -- JDL