Why are always object pointers used? (i.e., ObjectType *objPointer)
what are the advantages of using object pointers Vs objects
(ObjectType obj)
one advantage I see is passing them across methods, but is this purely
presentation issue (use 'objPointer' rather than '&obj') or are there
some performance affects?

-Krishna

krishna.kishore.0987@gmail.com wrote:
> Why are always object pointers used? (i.e., ObjectType *objPointer)
> what are the advantages of using object pointers Vs objects
> (ObjectType obj)

Polymorhpism and slicing.

> one advantage I see is passing them across methods, but is this purely
> presentation issue (use 'objPointer' rather than '&obj') or are there
> some performance affects?

Now you're talking about references instead of copied objects. The
advantage is that a reference parameter always refers to a valid object
(modulo UB in the caller, of course).

On 2007-10-15 21:29, krishna.kishore.0987@gmail.com wrote:
> Why are always object pointers used? (i.e., ObjectType *objPointer)

Probably because of bad design, there is no reason to always use
pointers, but there cases where you should use them and there are other
cases where you can.

> what are the advantages of using object pointers Vs objects
> (ObjectType obj)
> one advantage I see is passing them across methods, but is this purely
> presentation issue (use 'objPointer' rather than '&obj') or are there
> some performance affects?

As red floyd pointed out polymorphism is one reason, for large objects
there is the performance aspect. In some other cases it is about
semantics, some objects should not or cannot be copied. When determining
if a member should be an object or a pointer/reference to an object
there is also the question of ownership.

Personally I try to use references as much as possible and only use
pointers when I must. The question of whether an actual object or a
reference should be used it is often quite clear from the situation if
you know the differences between them and the implications of using them.

--
Erik Wikström

krishna.kishore.0987@gmail.com wrote:
> Why are always object pointers used? (i.e., ObjectType *objPointer)

Always? I don't always use them. In fact, I seldom use them.
This is a very typical example of where I don't use them:

std::string s = "hello";

No pointer there.

> one advantage I see is passing them across methods, but is this purely
> presentation issue (use 'objPointer' rather than '&obj') or are there
> some performance affects?

If you pass an object by value then a copy will most probably be made,
which will often be less efficient than passing by reference or by
pointer. Also there's the slicing problem if inheritance is involved.

On Oct 15, 2:14 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> krishna.kishore.0...@gmail.com wrote:
> > Why are always object pointers used? (i.e., ObjectType *objPointer)
>
> Always? I don't always use them. In fact, I seldom use them.
> This is a very typical example of where I don't use them:
>
> std::string s = "hello";
>
> No pointer there.
>
> > one advantage I see is passing them across methods, but is this purely
> > presentation issue (use 'objPointer' rather than '&obj') or are there
> > some performance affects?
>
> If you pass an object by value then a copy will most probably be made,
> which will often be less efficient than passing by reference or by
> pointer. Also there's the slicing problem if inheritance is involved.

Hi Guys,
Thanks for the replies. When I was punching 'always' I was stuck in
the world of GUI, I see pointers being used for GUI objects, 'always'
Thanks again,
Krishna

On 2007-10-16 00:46, Krishna wrote:
> On Oct 15, 2:14 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> krishna.kishore.0...@gmail.com wrote:
>> > Why are always object pointers used? (i.e., ObjectType *objPointer)
>>
>> Always? I don't always use them. In fact, I seldom use them.
>> This is a very typical example of where I don't use them:
>>
>> std::string s = "hello";
>>
>> No pointer there.
>>
>> > one advantage I see is passing them across methods, but is this purely
>> > presentation issue (use 'objPointer' rather than '&obj') or are there
>> > some performance affects?
>>
>> If you pass an object by value then a copy will most probably be made,
>> which will often be less efficient than passing by reference or by
>> pointer. Also there's the slicing problem if inheritance is involved.
>
> Hi Guys,
> Thanks for the replies. When I was punching 'always' I was stuck in
> the world of GUI, I see pointers being used for GUI objects, 'always'

That would probably be because GUI classes often makes heavy use of
polymorphism, (most graphical elements inherit from a base widget (or
whatever) class, and often implements a number of interfaces).

--
Erik Wikström

On Oct 16, 1:01 am, Erik Wikström <Erik-wikst...@telia.com> wrote:
> On 2007-10-16 00:46, Krishna wrote:
> > On Oct 15, 2:14 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> krishna.kishore.0...@gmail.com wrote:
> >> > Why are always object pointers used? (i.e., ObjectType *objPointer)

> >> Always? I don't always use them. In fact, I seldom use them.
> >> This is a very typical example of where I don't use them:

> >> std::string s = "hello";

> >> No pointer there.

> >> > one advantage I see is passing them across methods, but is this purely
> >> > presentation issue (use 'objPointer' rather than '&obj') or are there
> >> > some performance affects?

> >> If you pass an object by value then a copy will most probably be made,
> >> which will often be less efficient than passing by reference or by
> >> pointer. Also there's the slicing problem if inheritance is involved.

> > Thanks for the replies. When I was punching 'always' I was stuck in
> > the world of GUI, I see pointers being used for GUI objects, 'always'

> That would probably be because GUI classes often makes heavy use of
> polymorphism, (most graphical elements inherit from a base widget (or
> whatever) class, and often implements a number of interfaces).

Independently of polymorphism (although that can also be a
reason), GUI classes often have identity. If you set the
background to red, you want it to be on the class instance which
controls the display, and not some copy. Classes which have
externally visible behavior often (usually?) have identity, and
when a class have identity, it can only be passed by reference
or by a pointer.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34