|  | encapsulating related utility functions | | |
| | | Marco |  |
|  Posted: Sun Jun 22, 2008 9:27 pm Post subject: encapsulating related utility functions |  |
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 pure functions with no
state.
1) Create a class with all static functions
2) Use a named namespace
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Oncaphillis | |
| | Posted: Mon Jun 23, 2008 1:22 am Post subject: Re: encapsulating related utility functions | |
| |  | |
| Quote: | 1) Create a class with all static functions
2) Use a named namespace
|
In ancient times projects used to employ static class
functions as a namespace replacement since not
all compilers supported them.
You can not import whole libraries via a "using namespace"
statement when defining static class functions, so it might be a little
bit inconvenient. I personally try to avoid importing
namspaces since I tend to forget which foo() of the Foo::foo()
and Bar::foo() I've used, but may be that's more for personal
taste.
A big pro for static class members is access control via
private and protected. So if your functions are not trivial
and there are some helper functions within your library which
are supposed to be internal static class members are a real
advantage. Especially if it's for templated functions which
have to show up in the header files and which can not
be defined as static for a given source-file.
O.
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Jeff Koftinoff | |
| | Posted: Thu Jun 26, 2008 12:15 am Post subject: Re: encapsulating related utility functions | |
| | | |
On Jun 22, 2:27 pm, Marco <prenom_no...@yahoo.com> wrote:
| Quote: | 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 pure functions with no
state.
1) Create a class with all static functions
2) Use a named namespace
|
One pattern that I've been using recently is to use option #1 when all
the functions and helper classes need to be templatized on the same
type, just because I can't do "typename <typename T> namespace tools
{ ... }"
For instance:
template <typename T>
struct tools
{
class A
{
T a1,a2;
public:
...
friend std::ostream operator << ( std::ostream &o, const A &v )
{
o << a1 << " " << a2 << "\n";
return o;
}
};
class B
{
T b1,b2;
public:
...
friend std::ostream operator << ( std::ostream &o, const B &v )
{
o << b1 << " " << b2 << "\n";
return o;
}
};
static void do_something( const A &a, const B &b )
{
std::cout << a << b << "\n";
}
};
void f()
{
tools<float>::A a;
tools<float>::B a;
tools<float>::do_something(a,b);
}
I find it easier to read and write than the alternatives. The
downside to it is that all members of the struct must be put in one
place, whereas the namespace can be re-opened and added to at any
time. Perhaps that is a benefit in some situations...
jeff koftinoff
jeffk@jdkoftinoff.com
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
|
|
