Change C functions to C++ static methods for organisation?

[Digital Puer]

Hi, I've inherited a bunch of C code that needs to be called from
a C++ framework, so I thought it would be good to put these C
functions into C++ classes for better organisation. What are
best practices?

Should I put related C functions into a class and make them
static methods? Most of the C functions are in separate files
with no global variables (one file of functions for producing
random numbers, one file of functions for doing stats analysis,
etc.), so should I make a class out of each of these files and just
make them static functions?

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi, I've inherited a bunch of C code that needs to be called from
a C++ framework, so I thought it would be good to put these C
functions into C++ classes for better organisation. What are
best practices?

Should I put related C functions into a class and make them
static methods? Most of the C functions are in separate files
with no global variables (one file of functions for producing
random numbers, one file of functions for doing stats analysis,
etc.), so should I make a class out of each of these files and just
make them static functions?

That sounds like a Java-solution to me (not necessarily bad) but C++
does nor require everything to be a class, and for many things I think
this makes sense. I'd put the functions in one or more namespaces.

 

[Noah Roberts]

Hi, I've inherited a bunch of C code that needs to be called from
a C++ framework, so I thought it would be good to put these C
functions into C++ classes for better organisation. What are
best practices?

Should I put related C functions into a class and make them
static methods? Most of the C functions are in separate files
with no global variables (one file of functions for producing
random numbers, one file of functions for doing stats analysis,
etc.), so should I make a class out of each of these files and just
make them static functions?

No. You should leave them be. Put them in a namespace if you want but
really...just let them be. If you are going to bother OOing them then
do it for real. Create classes that contain encapsulated data and put
functions that need access to the private data parts in the class and
leave the rest as external functions.

 

[Frederick Gotham]

Digital Puer:

Hi, I've inherited a bunch of C code that needs to be called from
a C++ framework, so I thought it would be good to put these C
functions into C++ classes for better organisation. What are
best practices?

Should I put related C functions into a class and make them
static methods? Most of the C functions are in separate files
with no global variables (one file of functions for producing
random numbers, one file of functions for doing stats analysis,
etc.), so should I make a class out of each of these files and just
make them static functions?

The only reason I've ever had to put a perfectly good set of a functions into
a class as static functions, was to aid me in template trickery:

template<class T>
void Func()
{
T::SomeFunc();
}

It seems that a lot of novices are doing nowadays just so they can say
they're code is OO.

 

[Digital Puer]

No. You should leave them be. Put them in a namespace if you want but
really...just let them be. If you are going to bother OOing them then
do it for real. Create classes that contain encapsulated data and put
functions that need access to the private data parts in the class and
leave the rest as external functions.

If I use a namespace, the syntax for a function would be the same
as if the function were a static method, right?

For example, MyUtils::doSomething().

There does not seem to be any advantage of a namespace over the
use of static methods to collect together unrelated functions.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

If I use a namespace, the syntax for a function would be the same
as if the function were a static method, right?

For example, MyUtils::doSomething().

There does not seem to be any advantage of a namespace over the
use of static methods to collect together unrelated functions.

Well, there's one class less in the application. In the future someone
might come across the code and try to understand what the purpose of the
class is, or even worse, try to instantiate it. Can you come up with any
good reason why you need a class that does nothing except provides a
namespace for the functions? Look at it in another way, is there any
advantage of a class over a namespace?

Using the namespace is probably more OO than using the class, since the
functions are probably to diverse to be in the same class, which would
mean that you should put them in several different classes, so that the
classes are small coherent units. Should the functions on the other hand
form a coherent set of operations they should probably be non-static
methods of some already existing class.