Encapsulating related utility functions

[Marco]

One of the things I like about C++ is that it doesn't force you to
create fake "objects" in the OO sense. We had a debate at the office
about the "right" way to encapsulate related utility functions (such
as additional math functions). These would be pure functions with no
state.

1) Create a class with all static functions

2) Use a named namespace

Please site articles or books if possible.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-06-22 16:22, Marco wrote:

One of the things I like about C++ is that it doesn't force you to
create fake "objects" in the OO sense. We had a debate at the office
about the "right" way to encapsulate related utility functions (such
as additional math functions). These would be pure functions with no
state.

1) Create a class with all static functions

2) Use a named namespace

Please site articles or books if possible.

Ask your self this (or ask your collogues):

* If you will never instantiate it why use a class, or put another way:
how is it object-oriented to create a class but never create any
objects from it?

* If you create a class with static functions, what relation does these
functions have with the class (except that the class provides a
namespace for the functions)?

--
Erik Wikström

[Kai-Uwe Bux]

Erik Wikström wrote:

On 2008-06-22 16:22, Marco wrote:

>One of the things I like about C++ is that it doesn't force you to
create fake "objects" in the OO sense. We had a debate at the office
about the "right" way to encapsulate related utility functions (such
as additional math functions). These would be pure functions with no
state.

1) Create a class with all static functions

2) Use a named namespace

Please site articles or books if possible.

Ask your self this (or ask your collogues):

* If you will never instantiate it why use a class, or put another way:
how is it object-oriented to create a class but never create any
objects from it?

And what's wrong with it not being OO?

* If you create a class with static functions, what relation does these
functions have with the class (except that the class provides a
namespace for the functions)?

In the case of the OP, probably none; but then again: why would that be bad?

One difference between a class and a namespace is that you (or anybody else)
can add stuff to a namespace whereas a class is closed.

A more interesting difference is that a class can be used as a template type
parameter. That can make option (1) appropriate in some cases. The class
can provide implementations (and sometimes even semantics) for primitive
operations used in an algorithm. (E.g., one could have a string class that
takes a policy class supplying implementations of search and pattern
matching algorithms; or you could have a vector whose reallocation strategy
is governed by a policy. Changing the policy would be a way to optimize a
program.)
Now, to evaluate the options (1) and (2) on their merits, I still agree that
if those template tricks don't enter the picture, option (2) is the way to
go. But that is simply because I don't see why you would want to close the
namespace.

Best

Kai-Uwe Bux

[James Kanze]

On Jun 22, 4:41 pm, Erik Wikström <Erik-wikst...@telia. comwrote:

On 2008-06-22 16:22, Marco wrote:

One of the things I like about C++ is that it doesn't force
you to create fake "objects" in the OO sense. We had a
debate at the office about the "right" way to encapsulate
related utility functions (such as additional math
functions). These would be pure functions with no state.

1) Create a class with all static functions

2) Use a named namespace

Please site articles or books if possible.

Ask your self this (or ask your collogues):

* If you will never instantiate it why use a class, or put another way:
how is it object-oriented to create a class but never create any
objects from it?

To close it? A class differs from a namespace in several ways.
One, of course, is that you can't instantiate a namespace.
Another is that you can't add names to a class. Yet a third is
that a class can have private members.

Obviously (I think), none of these issues apply to additional
math functions, and these should probably be in a namespace.
But there are probably cases where closure or private members
are an issue, in which case, a class should be used.

* If you create a class with static functions, what relation
does these functions have with the class (except that the
class provides a namespace for the functions)?

If the functions are private, they can only be called by other
members of the class.

Note that I'm just playing the devil's advocate here. Generally
speaking, the original question can be restated to ask "is it
appropriate to confuse the reader by pretending something is OO
when you're not?"

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[=?UTF-8?B?TWFyY2VsIE3DvGxsZXI=?=]

Hi!

Erik Wikström wrote:

Ask your self this (or ask your collogues):

* If you will never instantiate it why use a class, or put another way:
how is it object-oriented to create a class but never create any
objects from it?

* If you create a class with static functions, what relation does these
functions have with the class (except that the class provides a
namespace for the functions)?

There are meaningful semantics of classes with only static members.

For example something like that:

template<class T, class K>
class instance_reposi tory
{public:
// abstract factory interface used for object instantiation
struct IFactory
{ virtual T* operator()(K& key) = 0;
};

public:
// Get an existing instance of T or return NULL.
static intrusive_ptr<T FindByKey(const K&);
// Get an existing instance of T or create a new one.
static intrusive_ptr<T GetByKey(K& key, IFactory& factory);
private:
static sorted_vector<T *, const K&Index;
static mutex Mtx; // protect the index above
};
Marcel

[Daniel Pitts]

Marco wrote:

One of the things I like about C++ is that it doesn't force you to
create fake "objects" in the OO sense. We had a debate at the office
about the "right" way to encapsulate related utility functions (such
as additional math functions). These would be pure functions with no
state.

1) Create a class with all static functions

2) Use a named namespace

Please site articles or books if possible.

Use a named namespace. The effect is the same (and the accessing syntax
will likely be the same). The benefit of using a namespace is that
namespaces are open, and you can have several header files which "add"
to the namespace.

For example, say you have functions for trig, and functions for algebra.
It might make sense to put them all in the namespace my_math_space, but
have "trig.h" and "algebra.h" . You couldn't do that that a class.

Classes should, in general, be used to encapsulate state/value. If you
have no state or value, then a class doesn't make sense. Note, type is
part of state, so polymorphic classes without data members do make sense
as classes.

Hope this helps,
Daniel.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity .net/wordpress/>

[Marco]

On Jun 22, 7:22 am, Marco <prenom_no...@y ahoo.comwrote:

One of the things I like about C++ is that it doesn't force you to
create fake "objects" in the OO sense. We had a debate at the office
about the "right" way to encapsulate related utility functions (such
as additional math functions). These would be pure functions with no
state.

1) Create a class with all static functions

2) Use a named namespace

site

oops that should be: Please cite articles or books if possible.