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

On Tue, 25 Mar 2003 23:06:17 -0500 "Steven T. Hatton" wrote:

I thought Bjarne Stroustrup did that. ;-) He invented C++ and he also is an associate of Kernighan and Ritchie at Bell Labs.

I guess that is part of what I'm not clear on. From my perspective, the only code in a program outside of main() should, if at all possible, be contained in classes. If I accept that class definitions are properly placed in the header files, then I would only have main.cpp and a bunch of header files. Not so. Each class you define (in a header file) contains functions (I prefer to call them methods). Those functions may be inline (and expanded at instanciation time), but larger functions that are not inline should be defined in a source module. Whether a function should be inline or not depends on many factors. Additionally, it is not imperative that all functions in a C++ program be class members.

I think your comments on the linker are correct. I'm in a bit of a hurry. I'll respond to the rest of the email later. -- -- Gerald Feldman Boston Computer Solutions and Consulting ICQ#156300 PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Steven T. Hatton wrote:

Personally, I'm finding all this jumping back and forth between class.cpp and class.h rather burdensome, and I'm wondering why I should even do it. Why not just do everything within the class body and be done with it?

Sometimes this makes sense. If the method finds the maximum of two integers, then I would put it in the class body because that's efficient. On the other hand, if the method reads an XML file and checks that it is valid, I would separate the definition from the declaration because the definition is sure to be very long and the method might be used in many subclasses. If I kept the definition in the class body, the object code would become very big because it would have many copies of the method rather than just one. Usually there's a tradeoff between speed and size. Small methods are best defined in the class body because the code runs faster (fewer function calls) but isn't much bigger. Big methods are best defined outside because the function call overhead is small compared to the work the function does and it reduces object code bloat (and makes the code compile faster).

...

Whether a function should be inline or not depends on many factors.

I would like to hear your views on this. From my Java experience, it seems rather strange to define things about a class outside of the body.

-- JDL