DHOLLINGSWORTH2 said:
IF your C procedure operates on "Class data" then you've messed the whole
++ thing. It's a matter of Object Orientation.
- a C procedure takes up less space than C++;
- a C procedure takes up more Time than C++, unless you are passing a lot
of references to the data being operated on.
- if data flows out of an object and not back in, I'd say use C when you
can. If the data flows back into an object, stick to C++.
- the matter is one of protection, and believe me, you will save on
aspirin debugging large projects.
- objects of the same class share methods, but use a seperate base pointer
to this objects data. a C procedure needs to pass in ALL of the pointers
to data.
- a C procedure doesn't care whos data its messing with, or if the data is
valid.
What??????
Where the heck did you get this information from?
First off, there are no "C" procedures versus "C++" procedures. If you're
compiling in C++, it's ALL C++! The difference is between member functions
and non-member functions, not C and C++. I understand that C++ has added
the use of member functions, but that doesn't make non-member function "C
procedures".
What makes you say that a non-member function takes up less space? Are you
referring to the parameters that get pushed when the function gets called?
In that case, there is indeed (at least conceptually, if not always in fact)
space reserved for the "this" pointer when making the call, but the itself
function is no larger. Also, static member functions, as in the OP's
example, don't use a "this" pointer, and so do not even take up that extra
space when called.
Next (referring to objects and the use of C or C++ based on data flow
direction), what makes you prefer using a non-member function for reading
data but a member function for writing data? That's very inconsistent.
Perhaps you're referring to the somewhat common practice of using a struct
and non-member functions for common tasks that don't require any special
data handling, such as a Point struct, which only has x and y members and is
used simply as a data holder for passing coordinates to functions like Move
and MoveTo? Regardless, it's not possible to only pass data ot of an
object. The data HAS to go in, somehow!
I have no idea what you're trying to say about non-member requiring passing
in ALL of the pointers to the data! You can certainly pass a pointer to a
struct or class to a non-member function. In member funcitons, if you're
operating on the object itself, then you don't have to *explicitly* pass the
object instance (unless you're calling a static member function). But it
*does* get passed to the function, as a kind of "hidden" parameter.
Finally, I don't see what the validity of the data has to do with anything,
regardless of whether you're referring to a member or non-member function.
To the OP:
I'd disregard the above posting altogether, if I were you.
Static member functions are indeed quite similar to non-member functions, in
that no "this" pointer exists, so there is no reference to a "current"
object. But you *can* access static member data or other static member
functions directly from a static member function, so they're not exactly the
same.
As for *why* use non-member functions, the most common reason, I suppose, is
when the function does not need to refer to an object. Consider the sin()
function. It takes an angle in radians and returns the sine for that angle.
No object is needed, and it would be more trouble to create an object just
to be able to call its sin function, wouldn't it?
There are many other common functions, often called "global" functions, that
act as utlities (scanf, sprintf, atoi, etc.) which don't require objects.
You should design your own code in a manner that is safe, consistent,
logical, and maintainable. And to help do that, I'd recommend some good
books, such as Scott Meyer's two "Effective C+" and More Effective C++"
books, and Stroustrup's "The C++ Programming Language".
-Howard