 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
lotusny78@yahoo.com
Guest
|
 Posted: Fri Apr 22, 2005 11:50 am Post subject: unnamed namespaces |
 |
|
I've read a number of threads which skirt around, but never seem to
answer, the same question:
Is it ever a good idea to replace private member functions with
helper functions in an anonymous namespace in the implementation file.
If so, under what conditions?
One situation in which this comes up a lot is breaking up a long member
function into managable pieces.
My own opinion, it is approriate even if you need some private data
passed as arguments because:
2) it prevents class bloat by keeping things which users have no
interest in out of the definition, while still keeping the code out of
the global space
3) decreases compilation times while refactoring
Obviously, as you need more and more arguments to pass private data,
the scale tips back toward private members.
Cheers,
Sean
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Bronek Kozicki
Guest
|
| Posted: Sat Apr 23, 2005 2:22 am Post subject: Re: unnamed namespaces |
|
|
[email]lotusny78 (AT) yahoo (DOT) com[/email] wrote:
| Quote: | Obviously, as you need more and more arguments to pass private data,
the scale tips back toward private members.
|
or pimpl; then the only private member of your class (the one in a
header file) is pointer (smart one, preferably) to implementation class.
This has, however, one serious drawback: if implementation class is
defined in implementation file, then no class member (especially
destructor) can be defined inline in the class. There are ways around
it, but AFAIK each one has some performance drawback.
B.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Valentin Samko
Guest
|
| Posted: Sat Apr 23, 2005 9:22 am Post subject: Re: unnamed namespaces |
|
|
[email]lotusny78 (AT) yahoo (DOT) com[/email] wrote:
| Quote: | I've read a number of threads which skirt around, but never seem to
answer, the same question:
Is it ever a good idea to replace private member functions with
helper functions in an anonymous namespace in the implementation file.
If so, under what conditions?
|
If you can replace a member function by a helper function which does not
need to be a friend, then why have this function as a member?
If some functionality used by member functions of your class does not
need access to protected/private members, and is not directly related to
the functionality provided by your class, try to keep it outside. One of
the exceptions is when your function must be virtual. This will help you
keep your class as one logical entity, which does one logical task,
delegating unrelated work to other functions / classes. As the result,
it will be easier for others to read and understand your code.
--
Valentin Samko
http://val.samko.info
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
lotusny78@yahoo.com
Guest
|
| Posted: Sun Apr 24, 2005 9:20 am Post subject: Re: unnamed namespaces |
|
|
If you can replace a member function by a helper function which does
not
| Quote: | need to be a friend, then why have this function as a member?
|
Maybe ANY private member function (excluding virtuals) can be made a
non-member non-friend function by passing references to private data as
arguments, but no one does that. The question is:
Is there a negative effect of replacing private functions with
non-member, non-friend functions which are connected to whatever
private data they need when called by the class e.g.
We start with:
class MyClass {
//...
public:
DoSomething();
};
//MyClass.cpp
void MyClass::DoSomething() {
//long block
//of code to find a window
//long block
//of code to get info with the window
//long block
//of code to use that info (the actual work of the function
}
We refactor to:
class MyClass {
//...
public:
DoSomething();
private:
FindWindow();
GetWindowInfo(window&);
};
//MyClass.cpp
void MyClass::DoSomething() {
window win = FindWindow();
GetWindowInfo(win);
//long block
//of code to use that info (the actual work of the function
}
Can (and should) we write:
class MyClass {
//...
public:
DoSomething();
};
//MyClass.cpp
namespace {
FindWindow() {...}
GetWindowInfo(window&) {...}
}
void MyClass::DoSomething() {
win = FindWindow();
GetWindowInfo(win);
//long block
//of code to use that info (the actual work of the function
}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Valentin Samko
Guest
|
| Posted: Sun Apr 24, 2005 8:19 pm Post subject: Re: unnamed namespaces |
|
|
[email]lotusny78 (AT) yahoo (DOT) com[/email] wrote:
| Quote: | If you can replace a member function by a helper function which does
not
need to be a friend, then why have this function as a member?
Maybe ANY private member function (excluding virtuals) can be made a
non-member non-friend function by passing references to private data as
arguments, but no one does that. The question is:
Is there a negative effect of replacing private functions with
non-member, non-friend functions which are connected to whatever
private data they need when called by the class e.g.
|
I thought I explained this in my previous post.
My main argument is that one class (or function) should perform one
logical task. If some code in your member functions is orthogonal to
that task, move it outside, delegate this work to other functions and
classes.
Regarding the negative effect, unless you are using the pimp idiom, I
think, it is better to keep the funcionality provided by your class
inside your class (functionality associated with your class, which
requires access to private/protected members). The main reason is
simplicity of the resulting code.
Examples:
You are implementing a hash table, and want to have a function
which initialises a bucket. I would have it as a private member,
because its functionality and implementation depends on the data
structures used by your hash map, and it performs a task directly
related to the hash map functionality.
You are implementing a networking library, and one of your classes
is a wrapper around sockets. In member functions of that class you often
change socket options in a platform specific way, so you decide to have
a special function for that. In this case I would rather have it as
a non member function (although it might need an access to some private
data in your class), because the functionality of changing socket
options is most likely orthogonal to the functionality provided by
your socket class.
--
Valentin Samko
http://val.samko.info
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Nemanja Trifunovic
Guest
|
| Posted: Sun Apr 24, 2005 8:20 pm Post subject: Re: unnamed namespaces |
|
|
| Quote: | Maybe ANY private member function (excluding virtuals) can be made a
non-member non-friend function by passing references to private data as |
arguments, but no one does that.
Actually, I do that pretty often, but it really depends on a concrete
situation.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
