Class or functions?

[lochnessmonster]

I'm haveing a hard time determining wether i should implement certain things as a class or just functions....for example....

Log.h library <--- i could obviously implement a Log class....and i could also have use Log functions(without a class) alternatively...is there any guideline/recommendations i should use when knowing wether i should make a class library...or function library

another example would be
NTHeader.h <--- provides a way to gain information about a specific PE's header file

should i place all these functions together into one class since they are all closely related? or should i just put them in seperate functions? i have a hard time knowing when i should perform one or the other

[rubberman]

Classes are to be preferred if you may want to subtype them and their behavior. Example for your logging functionality. You might a logging class to log to a file, rotating the files when they get to a certain size, and another one to send log messages to a remote system via TCP/IP or some sort of middleware. Their functionality is basically the same, but how they do what they do is quite different, so some virtual functions for the actual logging would be appropriate, especially if you had a virtual base class as effectively an interface class. That way, you could pass a pointer to that base class to a function and it could log stuff without needing to know what kind of logging class you are using. This sort of operator overloading is extremely useful in order to work with what we call abstractions, or in more current parlance, patterns.

Function libraries are very useful when what you are doing is discrete, such as TCP/IP socket handling, and not likely to be used to derive new behaviors.

[mike_2000_17]

My rule of thumb to decide whether to use free functions or class member functions is as follows. First of all, if you need to keep track of a state of some kind (like an opened file or array/vector or any other construct like that), then you need a class to hold that state (in your case, a Log class), that's a given. Now, the question is whether you should implement the functionalities as part of the class (as a member functions) or as free functions (alongside the class, but not static members, nor necessarily in the same header file). My rule is simple, if the main operation that a particular function does is to work on the class data members, then use a class member function, use a free function otherwise.

So, this means any get/set is obviously a class member. It includes typical things like you see in STL containers (like insert, erase, find, swap, clear, resize....) which clearly directly affect the internals of the STL container and is not meant to do much of anything else.

But then, there are things like operators. Obviously, some have to be members (like assignment and += and such, and some other special ones). But others don't, like addition or multiplication, these clearly act as much on one object as they act on the other, so they probably sit better as friend functions (in fact, because of overloading rules, they really ought to be friend functions and not members).

Free functions also offer great scalability compared to member functions. Consider the case of the operators << and >> for the iostreams. Anyone that comes up with a custom class or type can write free-function overloads of these operators and thus, extend the functionality of the iostreams in a very natural and scalable way. If iostreams were operated on only with member functions, it could not be done so nicely. Your Log class should probably try to mimic iostreams in that sense (it's also good to model your code in concordance with what C++ programmers are very familiar with).

But, I have to say, it's never really trivial to decide whether to use free functions or member functions. Of course, in OOP with virtual functions, it is kind of a trivial decision, but that is just one case. Many library developers struggle with these decisions, especially in generic programming (for example, the ongoing debate about the Boost Graph Library's extensive use of free functions and whether that was the best choice,.. I think so).

Another good rule about this is: functionality that you plan to derive or can only be derived on the library-side would probably be better served with member functions (giving you the liberty to use virtual functions and inheritance); but functionality that is intended for the user-side to be able to extend and customize should be free functions (don't force the users to derive custom classes from your library classes just to extend or change some of the functionality, allowing him to simple overload a free function is a lot nicer).