member function vs standalone func in cpp

[shaun roe]

This may be a question of style:
Sometimes I need a little helper function (e.g. checkRange(val, lo, hi))
in my .cpp and have a habit of making these functions simple standalone
functions in the .cpp file instead of member functions, because they
don't access any member variables. My understanding is that the 'static'
keyword in this context restricts their scope to the .cpp file.
If I find I use the function a lot, I promote it to a fully fledged
standalone function in a standalone .h & .cpp file as usual.

2 questions:
a) Does this seem reasonable, or is it 'poor style'?
b) is my understanding of static correct? What if I do not declare the
function static, doesn't it have file scope anyway?

cheers

shaun

 

[Lloyd Bonafide]

2 questions:
a) Does this seem reasonable, or is it 'poor style'?

Nothing wrong with static helper functions.

b) is my understanding of static correct? What if I do not declare the
function static, doesn't it have file scope anyway?

If you don't declare it static, modules that link with it can call it
provided they declare it (or include the declaration from a header
file):

<bar.cpp>

int get_number()
{
return 5;
}

<foo.cpp>

#include <iostream>

int get_number(); // Declaration

int main()
{
std::cout << get_number() << std::endl;

return 0;
}

 

[Brian Tyler]

I suppose that depends how specific it is to your class. If there is no
way any it would be of use anywhere else then why not make it a private
static? If it may have a more general use then why not have a separate
"utility" namespace where you put all those handy little multipurpose
functions?

static just means that you don't need to create an object of the class to
use the function, as such you can't use "this" in a static, but you can
access private functions and data members. So the class acts a bit like a
namespace and the static is like a friend. However access rules apply, so
if you make it private only the class and friends can access it.

Perhaps there may be some performance advantage over a normal member
function, but I'm not sure about this and it probably depends on the
situation.

 

[Krice]

Sometimes I need a little helper function (e.g. checkRange(val, lo, hi))
in my .cpp and have a habit of making these functions simple standalone
functions in the .cpp file instead of member functions, because they
don't access any member variables.

val, lo and hi should be member variables.

 

[Eberhard Schefold]

a) Does this seem reasonable, or is it 'poor style'?

I've asked this question myself (it does appear handy at times), but
decided against it. This is rather a 'gut' feeling, but I think that
the file location of a declaration or definition should be of as little
significance as possible. This may be an academic example, but one day
you could decide to move code into a different file, and thereby
inadvertedly call a different function with the same name that happens
to reside there.

If the utility function doesn't have much to do with the class though, I
don't think you absolutely have to make the function a member. As a C++
programmer one tends to shy away from global functions, but I don't
think that's alway justified. Use a namespace if you want.

b) is my understanding of static correct? What if I do not declare the
function static, doesn't it have file scope anyway?

The point is linkage. By default, functions at file scope have external
linkage, and internal linkage if declared static. You'll notice the
difference e.g. when you try to link two object files that both contain
a function with the same name.

 

[shaun roe]

I suppose that depends how specific it is to your class. If there is no
way any it would be of use anywhere else then why not make it a private
static? If it may have a more general use then why not have a separate
"utility" namespace where you put all those handy little multipurpose
functions?

Usually I put it in cpp and if I find I use it in more than 1-2 classes
(depends on the details), I make a utility namespace as you say

static just means that you don't need to create an object of the class to
use the function, as such you can't use "this" in a static, but you can
access private functions and data members. So the class acts a bit like a
namespace and the static is like a friend. However access rules apply, so
if you make it private only the class and friends can access it.

I didn't mean static as in static meber function, but the other meaning
of static, using it in the global namespace to restrict the scope of the
function to a single file; as I understand, 'static' in this usage in a
cpp file:
static void foo(){std::cout<<"Are you local?";}

will restrict the scope of foo to the cpp file only. I believe this has
been confirmed by the other commentators on this thread.

 

[Brian Tyler]

I didn't mean static as in static meber function, but the other meaning
of static, using it in the global namespace to restrict the scope of the
function to a single file; as I understand, 'static' in this usage in a
cpp file:
static void foo(){std::cout<<"Are you local?";}

will restrict the scope of foo to the cpp file only. I believe this has
been confirmed by the other commentators on this thread.

Got you, everything I write is template / inline so anything static ends
up everywhere anyway

 

[Andrey Tarasevich]

This may be a question of style:
Sometimes I need a little helper function (e.g. checkRange(val, lo, hi))
in my .cpp and have a habit of making these functions simple standalone
functions in the .cpp file instead of member functions, because they
don't access any member variables.
OK.

My understanding is that the 'static'
keyword in this context restricts their scope to the .cpp file.

Well, formally speaking, "scope" in C++ cannot be bigger than one
translation unit (.cpp file) anyway. Declaring a standalone function
'static' doesn't really affect its scope. It restricts its linkage to so
called internal linkage.

But in some informal meaning of the term that's pretty much correct.

If I find I use the function a lot, I promote it to a fully fledged
standalone function in a standalone .h & .cpp file as usual.
OK.

2 questions:
a) Does this seem reasonable, or is it 'poor style'?

It is reasonable in case of a more-or-less generic function (like
'checkRange' operating on integral values).

In cases when the function has some semantic attachment to some
particular class (like 'checkRange' on arguments of some user-defined
class type), it might be a good idea to declare it as a static member
function of that class, not as a standalone function.

b) is my understanding of static correct? What if I do not declare the
function static, doesn't it have file scope anyway?

This is when the formal meaning of "scope" becomes important. Once
again, 'static' in your case doesn't affect scope. It affects linkage.

 

[James Kanze]

This may be a question of style:
Sometimes I need a little helper function (e.g.
checkRange(val, lo, hi)) in my .cpp and have a habit of making
these functions simple standalone functions in the .cpp file
instead of member functions, because they don't access any
member variables. My understanding is that the 'static'
keyword in this context restricts their scope to the .cpp
file. If I find I use the function a lot, I promote it to a
fully fledged standalone function in a standalone .h & .cpp
file as usual.

2 questions:
a) Does this seem reasonable, or is it 'poor style'?

I do it all the time, except that I'll put the function in an
anonymous namespace, rather than declaring it static. And I
don't limit it to functions: data and helper classes will appear
as well.

In extreme cases, I'll create a private namespace in the header,
forward declare a class there, and make it a friend. That way,
my "helper" functions (which are then members of this friend
class) can access private members as well.

b) is my understanding of static correct? What if I do not
declare the function static, doesn't it have file scope
anyway?

Formallly:
-- there is no such thing as file scope; it's namespace scope,
and
-- scope is always limited to a file, what you're concerned
with is called linkage (whether the same qualified name in
another translation unit refers to the same "thing" or not).

Practically, declaring a function or a variable at namespace
scope static means that it has "internal linkage"; the same name
elsewhere in the translation unit refers to the same thing, but
the same name in other translation units doesn't.
(Pragmatically: the name won't be exported to the linker.)

Using static for this has been deprecated (I think), and of
course, it can't be used for helper classes, etc. (And you can't
bind a template argument to anything which doesn't have external
linkage. Not often a consideration for functions, but it can be
for variables.) Putting the functions etc. in an anonymous
namespace means that they have external linkage, but the
qualified name (i.e. the name with its namespace) cannot be
specified in another translation unit.