On Tuesday 25 March 2003 02:03 pm, John Lamb wrote:
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_
If I'm understanding E&S, what really matters is /Translation Unit/. When something is said to be in /file scope/ it refers to the file produced by the preprocessor. I'll have to confess, when my professor started talking about preprocessor directives in my C programming course, my head just started to spin. Now some of it seems to be falling into place.
...
#endif
It looks like Jerry Feldman has some insight into another twist on how this might affect preprocessing. Somehow, I suspect compilers are smart enough these days to know to skip the redundancies, but one never knows. And there may be still more subtle implications I have failed to comprehend in what he said.
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.
Ho! Duh! Now I see what you're saying. I don't need to mess with putting the arcana at the top of my files, it's already there in the .h files. # So #including it more than once is not technically wrong ...
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.
In Java, I usually import the class rather than the package, and typically use this.member whenever I can. I also tend to use ClassName.ststicMember, even within the class it is a member of. There's nothing that confuses me more than seeing an identifier arise from a completely obscure location. So I have to agree with your opinion.
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.
After getting reasonably fluent in Java (I still have much to learn) I sat down to write some C. I was simply amazed at the result. I had forgotten all about iterating off the ends of arrays, and managing memory, etc. Fortunately, QT protects me from myself fairly well. Or so it would seem thus far.
-- JDL
I need to look this stuff over some more, but at a glance, it looks as though the Trolls have a different way to skin the same cat. This, for example, is something Java only wishes it had: http://doc.trolltech.com/3.1/qstring.html#insert And this looks to be a tokenizer, and then some: http://doc.trolltech.com/3.1/qstringlist.html http://doc.trolltech.com/3.1/qstring.html http://doc.trolltech.com/3.1/qstring-members.html STH