Should helper functions be members?

[shaun roe]

When should a function be a private member, and when simply a standalone
function in the .cpp file?
I'm in the middle of writing a class which bridges between two packages,
and so I need some helper functions to convert between the types used,
in particular between 'unsigned long long' and a ValidityKey which is
like an unsigned long long but only goes up to 2^63 -1.
(Please dont flame me for using unsigned long long, I know its not
standard, but I'm stuck with it).

So I could do the following (this example is not complete - and is just
off the top of my head - , just highlighting the salient points)

in the .h file:
==============
//fwd decl
namespace pkg1{
class ValidityKey;
}

class CoolInterface{
private:
pkg1::ValidityK ey convertToKey(co nst longlongKey);
};

and then put the implementation in the .cpp file as usual:

in the .cpp file
=============== =

#include "pkg1/ValidityKey.h"
#include "pkg1/ValidityKeyExce ption.h"

pkg1::ValidityK ey CoolInterface:: convertToKey(co nst longlongKey){
if (longlongKey ValidityKey::ma x()) //max() is 2^63 -1
{
std::cerr<<"Coo lInterfaceError : key is too big"<<std::endl ;
throw(pkg1::Val idityKeyExcepti on("convertToKe y",longlongKey) );
} else {
return ValidityKey(lon glongKey);//this constructor exists
}
}

Now... equally I could just put the whole helper function in the .cpp
file as a standalone function and not put any mention of it in my class,
so I wouldnt need a fwd declaration in my .h file for the class. I think
this would be cleaner, but its not a philosophy I see followed very
often... what is the disadvantage? I will only use this helper in the
scope of the .cpp file.

cheers

shaun

[Daniel T.]

In article
<sh************ *************** **@news-reader.wanadoop ortails.com>,
shaun roe <sh*******@wana doo.frwrote:

When should a function be a private member, and when simply a standalone
function in the .cpp file?

Make it a stand-alone function in the cpp file (in an unnamed namespace)
if the number of parameters it needs is relatively small. This will help
reduce your compile times.

I'm in the middle of writing a class which bridges between two packages,
and so I need some helper functions to convert between the types used,
in particular between 'unsigned long long' and a ValidityKey which is
like an unsigned long long but only goes up to 2^63 -1.
(Please dont flame me for using unsigned long long, I know its not
standard, but I'm stuck with it).

So I could do the following (this example is not complete - and is just
off the top of my head - , just highlighting the salient points)

in the .h file:
==============
//fwd decl
namespace pkg1{
class ValidityKey;
}

class CoolInterface{
private:
pkg1::ValidityK ey convertToKey(co nst longlongKey);
};

and then put the implementation in the .cpp file as usual:

in the .cpp file
=============== =

#include "pkg1/ValidityKey.h"
#include "pkg1/ValidityKeyExce ption.h"

pkg1::ValidityK ey CoolInterface:: convertToKey(co nst longlongKey){
if (longlongKey ValidityKey::ma x()) //max() is 2^63 -1
{
std::cerr<<"Coo lInterfaceError : key is too big"<<std::endl ;
throw(pkg1::Val idityKeyExcepti on("convertToKe y",longlongKey) );
} else {
return ValidityKey(lon glongKey);//this constructor exists
}
}

Hmm. This function should be part of ValidaityKey. If you can't change
ValidaityKey then I would make a separate module for it and make it a
stand-alone function. There is no reason at all to put it in
CoolInterface.