Re: Class members, pointers or not?
From: Dave Moore (dtmoore_at_rijnh.nl)
Date: 04/29/04
- Next message: josh: "Re: Why won't the compiler tell??"
- Previous message: E. Robert Tisdale: "Re: "using namespace" within a class declaration?"
- In reply to: Oystein Haare: "Class members, pointers or not?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 28 Apr 2004 16:07:23 -0700
Oystein Haare <oyhaare@online.no> wrote in message news:<pan.2004.04.28.13.59.36.583367@online.no>...
> Is it best to declare class member objects as pointers or not pointers?
>
Generally speaking, using pointer members (and reference members)
requires more care than regular data members. However, there are some
cases when they are useful or even unavoidable.
1) When an contained object cannot be properly created when the
constructor for the enclosing class is called, you can declare a
pointer member and then initialize it with a call to new when you have
enough information to properly create the member. Of course you had
then better properly delete the pointer in the destructor for the
enclosing class. In my experience, this is a useful solution to the
problem of creating sub-objects that require user-input to be created.
2) To avoid copying a large, already-existing object, it is sometimes
useful to use a pointer (or reference) member in a class to access the
external object. If the object will never change and is available
when the constructor is called, then use a (const) reference-member,
otherwise you have to use a pointer-member. Of course lifetime issues
then become a potentially serious problem (you don't want to try to
access the external object through the pointer/reference member after
it has been destructed), so care is required. Note that most (all?)
of the time, equivalent behavior can be achieved by passing the
external object as an argument to a member function, which is a safer
solution.
3) For separating interface and implementation in a class design, it
is sometimes useful to the so-called "pimpl-idiom" (pimpl == private
implementation). For example,
// file "foo.hpp"
class foo {
public:
foo(int);
// whatever
private:
class pimpl; // forward declaration
pimpl* acne;
};
// file "foo.cpp"
class foo::pimpl {
int a_;
public:
pimpl(int a) : a_(a);
// private implementation
};
foo::foo(int a) {
acne = new pimpl(a);
}
// other foo member functions requiring information from foo::pimpl
This allows more "modular" C++ code, where the interface in the .hpp
file just provides users with the semantics for using the class, and
all of the implementation details and data members are hidden in the
.cpp file. So, if you decide to completely re-implement a class, you
can just replace the code in the .cpp file without changing the header
file at all. I understand that this is a particularly useful trick
when writing libraries, but that is not something I have experience
with myself.
4) anything else I have forgotten <grin>
Hope this sheds some light on things for you ...
Dave Moore
- Next message: josh: "Re: Why won't the compiler tell??"
- Previous message: E. Robert Tisdale: "Re: "using namespace" within a class declaration?"
- In reply to: Oystein Haare: "Class members, pointers or not?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
