Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7183 > unrolled thread

Pointer Vs non-pointer member variable

Back to article view | Back to comp.lang.c++

Contents

  Pointer Vs non-pointer member variable ittium <ittium@gmail.com> - 2011-06-27 07:12 -0700
    Re: Pointer Vs non-pointer member variable Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-27 10:25 -0400
      Re: Pointer Vs non-pointer member variable SG <s.gesemann@gmail.com> - 2011-06-30 06:03 -0700
    Re: Pointer Vs non-pointer member variable Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-27 19:42 +0000
      Re: Pointer Vs non-pointer member variable Fred <fred.l.kleinschmidt@boeing.com> - 2011-06-30 11:43 -0700
        Re: Pointer Vs non-pointer member variable drew@furrfu.invalid (Drew Lawson) - 2011-06-30 20:21 +0000
        Re: Pointer Vs non-pointer member variable Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-07-01 11:25 +0200
        Re: Pointer Vs non-pointer member variable Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-01 11:11 +0000
    Re: Pointer Vs non-pointer member variable Stuart Redmann <DerTopper@web.de> - 2011-06-29 23:12 -0700

#7183 — Pointer Vs non-pointer member variable

Group,
Are there any guidelines regarding, choosing pointer vs non-pointer
member variables for a class
thanks
Ittium

[toc] | [next] | [standalone]

#7184

On 6/27/2011 10:12 AM, ittium wrote:
> Are there any guidelines regarding, choosing pointer vs non-pointer
> member variables for a class

Yes, I am sure you can find hundreds of "guidelines" of that sort.  Most 
likely they are going to be tied to "associativity" and "containment" 
relationships.  Learn about those, and you can write your own "guidelines".

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#7289

On 27 Jun., 16:25, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> On 6/27/2011 10:12 AM, ittium wrote:
>
> > Are there any guidelines regarding, choosing pointer vs non-pointer
> > member variables for a class
>
> Yes, I am sure you can find hundreds of "guidelines" of that sort.  Most
> likely they are going to be tied to "associativity" and "containment"
> relationships.  Learn about those, [...]

Richt. There are many different ways of how some inter-object
relationship can be implemented:

  class sub {...};
  class foo1 { sub real_sub_object; ... };
  class foo2 { sub* stupid_pointer; ... };
  class foo3 { vector<sub> vect; ... };
  class foo4 { unique_ptr<sub> up; ... };
  ...

Especially in the presence of neat little building blocks like
standard containers and unique_ptr I think the number of good reasons
why somebody should implement an "is-part-of" or "is-made-up-out-of"
relationship (containment) with a raw pointer (see foo2) is
approaching zero. A raw pointer basically means association. If you
want to use raw pointers to model containment you also have to
"override" the class' default copy semantics by providing custom or
explicitly disabling copy ctor, assignment operator and dtor. IMHO,
it's best to avoid it if possible. Let other, smaller building blocks
handle all the necessary management or use the objects as "real data
members" in these cases.

Cheers!
SG

[toc] | [prev] | [next] | [standalone]

#7187

On Mon, 2011-06-27, ittium wrote:
> Group,
> Are there any guidelines regarding, choosing pointer vs non-pointer
> member variables for a class

Use non-pointer unless you have a reason not to.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#7304

On Jun 27, 12:42 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Mon, 2011-06-27, ittium wrote:
> > Group,
> > Are there any guidelines regarding, choosing pointer vs non-pointer
> > member variables for a class
>
> Use non-pointer unless you have a reason not to.
>

I tend to do the opposite - use pointer unless you have a reason not
to.

For example:
MyClass.h:
// Using non-pointer

#include Other.h
class MyClass {
 public:
   Other myOther;
   // etc.
};

// Using pointer

class Other;
class MyClass {
 public:
   Other *myOther;
   // etc.
};

Now if MyClass.h is included in a lot of other files,
using the non-pointer version will cause all of those
files to be re-compiled whenever there is a change to
Other.h (assuming you have the correct dependencies
specified in your Makefile).

Using the pointer version, only MyClass.C will be
re-compiled when Other.h changes - there will not be
any re-compiles of the files including MyClass.h unless
they also include Other.h separately.

--
Fred K

[toc] | [prev] | [next] | [standalone]

#7306

In article <e52c2ace-62a4-47fb-8063-1431317a52a4@h38g2000pro.googlegroups.com>
	Fred <fred.l.kleinschmidt@boeing.com> writes:
>On Jun 27, 12:42 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Mon, 2011-06-27, ittium wrote:
>> > Group,
>> > Are there any guidelines regarding, choosing pointer vs non-pointer
>> > member variables for a class
>>
>> Use non-pointer unless you have a reason not to.
>>
>
>I tend to do the opposite - use pointer unless you have a reason not
>to.

Haven't you heard that pointers are EVIL?
They'll steal your lunch money and tie your shoelaces together.
They probably cause global warming and kill kittens as well.

That's why people insist on calling them "raw" -- to remind you to
wash your hands after touchin one.

-- 
Drew Lawson            |  What is an "Oprah"?
                       |      -- Teal'c
                       |

[toc] | [prev] | [next] | [standalone]

#7327

Fred <fred.l.kleinschmidt@boeing.com> writes:

> I tend to do the opposite - use pointer unless you have a reason not
> to.
[...]
> Now if MyClass.h is included in a lot of other files, using the
> non-pointer version will cause all of those files to be re-compiled
> whenever there is a change to Other.h (assuming you have the correct
> dependencies specified in your Makefile).
>
> Using the pointer version, only MyClass.C will be re-compiled when
> Other.h changes - there will not be any re-compiles of the files
> including MyClass.h unless they also include Other.h separately.

Designing your data model to optimize the behavior of the tools you use
is an strange strategy (and I doubt you'll save a lot of compile time,
but this depends on your code). The difference between embedding and
pointing to is not purely cosmetic.

Another real problem with this is that the systematic use of pointers
brings C++ to the level of Java from the point of view of data locality,
fragmenting memory as much as possible, and probably adds tons of
indirections in the resulting binary, forbiding many optimizations
because of the ensuing potential aliasing between pointers. Slowdown,
code bloat.

I really can't see any real benefit to your "trick". You're basically
wrecking your design and sabotaging the work of the compiler.

-- Alain.

[toc] | [prev] | [next] | [standalone]

#7328

On Thu, 2011-06-30, Fred wrote:
> On Jun 27, 12:42 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Mon, 2011-06-27, ittium wrote:
>> > Group,
>> > Are there any guidelines regarding, choosing pointer vs non-pointer
>> > member variables for a class
>>
>> Use non-pointer unless you have a reason not to.
>>
>
> I tend to do the opposite - use pointer unless you have a reason not
> to.
>
> For example:
> MyClass.h:
> // Using non-pointer
>
> #include Other.h
> class MyClass {
>  public:

You mean private, right?

>    Other myOther;
>    // etc.
> };
>
> // Using pointer
>
> class Other;
> class MyClass {
>  public:
>    Other *myOther;
>    // etc.

Here you also have to add constructors, destructors etc -- things
which were not needed in the first version.

> };
>
> Now if MyClass.h is included in a lot of other files,
> using the non-pointer version will cause all of those
> files to be re-compiled whenever there is a change to
> Other.h

Not enough reason IMHO. But I do something like this if Other.h is
very dirty and would pull in lots of macros and cruft, like some Unix
system include files.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#7267

On 27 Jun., ittium wrote:
> Group,
> Are there any guidelines regarding, choosing pointer vs non-pointer
> member variables for a class
> thanks
> Ittium

That's easy: Always choose non-pointer if possible.

Note that there are few cases where you have to use pointer, for
example if the object that is pointed to is managed by a different
class:

class Application
{
public:
  void DoSomething ();
};

class SomeClass
{
private:
  Application* App_;

public:
  SomeClass (Application* App)
    : App_ (App)
  {}

  void foo ()
  {
    App_->DoSomething ();
  }
};

Here SomeClass uses a plain pointer to the Application class since
this class is created and managed by some third entity.

Another case is when the member is managed by the class itself but
cannot be created in the constructor of the class. In that scenario
you are forced to use pointers. However, you should use some smart
pointer:

class Slave
{};

class Master
{
public:
  Master ();
  void Initialize ()
  {
    Slave_ = std::auto_ptr<Slave> (new Slave ());
  }

private:
  std::auto_ptr<Slave> Slave_;
};

In this case the life-time of Slave_ will be a subset of the life-time
of Master.

Regards,
Stuart

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web