-> vs .

[Jon Slaughter]

I was wondering if there is any big difference(speed/size) when one uses ->
vs . as returning a pointer vs a reference.

i..e in my code I overload [] a lot(cause I have many classes) and I can do
either

object& operator[](int index)

{

if ((index >= NumProperties()) || (index < 0) || (Properties.empty()))

{

throw "Object: Invalid Index!";

}

return *(Properties[index]);

};



or



object* operator[](int index)

{

if ((index >= NumProperties()) || (index < 0) || (Properties.empty()))

{

throw "Object: Invalid Index!";

}

return (Properties[index]);

};



Properties is a vector of pointers. The difference between the two methods
basicaly comes down to using -> and . but I prefer to use . because its
easier to type and consistent with my thinking about fields(while the -> is
basicaly the same its just easier to think about .(not much but...)).

I'm just wondering if there is any reason not to use the first code example
over the second one(as far as optimization is concerned).



Thanks,

Jon

 

[Maxim Yegorushkin]

I was wondering if there is any big difference(speed/size) when one uses ->
vs . as returning a pointer vs a reference.

There is no difference in speed/size.

 

[Jon Slaughter]

There is no difference in speed/size.

good, thats what I thought but wasn't sure.

Thanks,

Jon

 

[David Hilsee]

I was wondering if there is any big difference(speed/size) when one uses ->
vs . as returning a pointer vs a reference.

i..e in my code I overload [] a lot(cause I have many classes) and I can do
either

object& operator[](int index)

{

if ((index >= NumProperties()) || (index < 0) || (Properties.empty()))

{

throw "Object: Invalid Index!";

}

return *(Properties[index]);

};



or



object* operator[](int index)

{

if ((index >= NumProperties()) || (index < 0) || (Properties.empty()))

{

throw "Object: Invalid Index!";

}

return (Properties[index]);

};



Properties is a vector of pointers. The difference between the two methods
basicaly comes down to using -> and . but I prefer to use . because its
easier to type and consistent with my thinking about fields(while the -> is
basicaly the same its just easier to think about .(not much but...)).

I'm just wondering if there is any reason not to use the first code example
over the second one(as far as optimization is concerned).

There probably isn't a difference in speed/size, but you can test to be
sure.

Personally, I'd only use the pointer version if it were possible for the
return value to be null. Traditionally, operator[] returns a reference or
by value.

 

[Ivan Vecerina]

:I was wondering if there is any big difference(speed/size) when one
uses ->
: vs . as returning a pointer vs a reference.

There *can* be a difference: using a reference could be faster in some
cases.

When using a pointer, the compiler has to assume that the pointer
might be NULL. This typically has implications for type casts, for
example, where before adding an offset to a pointer value, the
original value has to be checked for NULL.
Some compilers/platforms may also choose to perform other run-time
checks when dereferencing pointers, which is unnecessary for
references (as they are not allowed to be NULL).

This supports the classic rationale: use a pointer instead of a
reference only if the pointer is allowed to have a NULL value.

hth-Ivan

 

[Maxim Yegorushkin]

:I was wondering if there is any big difference(speed/size) when one
uses ->
: vs . as returning a pointer vs a reference.

There *can* be a difference: using a reference could be faster in some
cases.

Only in theory, I think.

When using a pointer, the compiler has to assume that the pointer
might be NULL. This typically has implications for type casts, for
example, where before adding an offset to a pointer value, the
original value has to be checked for NULL.
Some compilers/platforms may also choose to perform other run-time
checks when dereferencing pointers, which is unnecessary for
references (as they are not allowed to be NULL).

Is this just wishful thinking or are you talking about a specific
implementation? I just checked the assembly output of the following
code using gcc 4.0.1 on x86:

#include <stdio.h>

struct A { int i; };
struct B { int ii; };
struct C : A, B {};

C& f();
C* g();

B& h();
B* i();

int main()
{
// upcasting
B& b1 = f();
B* b2 = g();

// downcasting
C& c1 = static_cast<C&>(h());
C* c2 = static_cast<C*>(i());

printf("%p\n%p\n%p\n%p\n", &b1, b2, &c1, c2);
}

The assembly code treats pointers and references exactly the same way:
it checks them for zero before casting. And I would be surprised if it
wouldn't: references are pointers with changed semantics.

This supports the classic rationale: use a pointer instead of a
reference only if the pointer is allowed to have a NULL value.

IMO, the rationale is somewhat missleading. Unlike references, pointers
have simpler semantics and rules. I don't see a reason for using
references instead of pointers unless I have to.

 

[msalters]

Maxim Yegorushkin schreef:

:I was wondering if there is any big difference(speed/size) when one
uses ->
: vs . as returning a pointer vs a reference. [snip]
When using a pointer, the compiler has to assume that the pointer
might be NULL. This typically has implications for type casts, for
example, where before adding an offset to a pointer value, the
original value has to be checked for NULL.
Some compilers/platforms may also choose to perform other run-time
checks when dereferencing pointers, which is unnecessary for
references (as they are not allowed to be NULL).

Is this just wishful thinking or are you talking about a specific
implementation?

IIRC, GCC and dynamic_cast. After all, dynamic_cast<T*> must deal with
NULL pointers. The logical implementation first checks for 0. The
dynamic_cast<T&> case doesn't. Other compilers are probably the same.

HTH,
Michiel Salters

 

[Ivan Vecerina]

Only in theory, I think.

The impact of the difference is theoretical, in that the NULL-check
is unlikely to make a difference in a real-world program.
But if there was a performance difference, it would most
likely be in favor of using references.

Is this just wishful thinking or are you talking about a specific
implementation? I just checked the assembly output of the following
code using gcc 4.0.1 on x86: ....
The assembly code treats pointers and references exactly the same way:
it checks them for zero before casting. And I would be surprised if it
wouldn't: references are pointers with changed semantics.

A null-bound reference is undefined behavior. gcc may handle as it
chooses, but in optimized builds one would have the right to expect
that such a redundant check is dropped-out.

IMO, the rationale is somewhat missleading. Unlike references, pointers
have simpler semantics and rules. I don't see a reason for using
references instead of pointers unless I have to.

I'm not sure that pointers are simpler than references, except
for those who learned C before C++.
Pointers can be NULL, and pointers can be confused with the address
of the first element of an array, or an iterator. Pointers can
be const, or be assignable. Also, pointers may suggest that the
object may be delete-d (unless your team wisely uses smart pointers
whenever appropriate).

In a program that hasn't entered UB, references always refer to one
valid object. When no additional feature is needed, using a reference
contributes to the readability and safety of the code.
Why wouldn't you take advantage of that tool?


Regards,
Ivan

 

[Dave Rahardja]

IMO, the rationale is somewhat missleading. Unlike references, pointers
have simpler semantics and rules. I don't see a reason for using
references instead of pointers unless I have to.

I disagree. References are safer than pointers in instances where a pointer
cannot be 0 or point to a variety of objects during its lifetime. References
allow the conceptual shift from "pointer" to "alias", which frees my mind from
dealing with the more dynamic nature or pointers.

 

[Maxim Yegorushkin]

Ivan Vecerina wrote:

[]

A null-bound reference is undefined behavior. gcc may handle as it
chooses, but in optimized builds one would have the right to expect
that such a redundant check is dropped-out.

I forgot to mention that I had compiled with -O3 switch.

I'm not sure that pointers are simpler than references, except
for those who learned C before C++.
Pointers can be NULL, and pointers can be confused with the address
of the first element of an array,

I see no problem with that.

or an iterator.

A pointer is an (stl) iterator.

Pointers can be const, or be assignable.

As well as integers. References are always const and assignement to
reference is completely different to its initialization, which is quite
confusing:

int i, j;
int& r = i;
r = j; // oops, meaning is not the same as in the previous line

Also, pointers may suggest that the
object may be delete-d (unless your team wisely uses smart pointers
whenever appropriate).

Raw pointers do not suggest or imply any kind of ownership. Smart
pointers do indeed.

In a program that hasn't entered UB, references always refer to one
valid object. When no additional feature is needed, using a reference
contributes to the readability and safety of the code.
Why wouldn't you take advantage of that tool?

Because I believe that reference semantics are more subtle than that of
pointer.

 

[Maxim Yegorushkin]

I disagree. References are safer than pointers in instances where a pointer
cannot be 0 or point to a variety of objects during its lifetime. References
allow the conceptual shift from "pointer" to "alias", which frees my mind from
dealing with the more dynamic nature or pointers.

My experience is opposite.

 

[Ivan Vecerina]

: Ivan Vecerina wrote:
: > A null-bound reference is undefined behavior. gcc may handle as
it
: > chooses, but in optimized builds one would have the right to
expect
: > that such a redundant check is dropped-out.
:
: I forgot to mention that I had compiled with -O3 switch.

Well, this redundant code might disappoint performance freaks,
and possibly could be submitted as a (minor) performance bug.

: > Pointers can be NULL, and pointers can be confused with the
address
: > of the first element of an array,
: I see no problem with that.

I prefer the language to guarantee that a variable is valid, except
when I explicitly want to allow it to be NULL.

: > or an iterator.
: A pointer is an (stl) iterator.

Yes, even when it actually points to a single element,
or to an item of a non-contiguously allocated collection.
This creates opportunities for confusion and errors,
which are avoided when using a reference.

: > Pointers can be const, or be assignable.
:
: As well as integers. References are always const and assignement to
: reference is completely different to its initialization, which is
quite
: confusing:
:
: int i, j;
: int& r = i;
: r = j; // oops, meaning is not the same as in the previous line

Initialization and assignment are very different beasts.
Many authors therefore recommend writing int& r(i);
The backwards-compatibility syntax of C++ (assignment-initialization)
is confusing in many other contexts, as one has to learn anyway what
triggers a call to an assignment operator vs. to a constructor.
I don't think this can be blamed on references...

: > Also, pointers may suggest that the
: > object may be delete-d (unless your team wisely uses smart
pointers
: > whenever appropriate).
:
: Raw pointers do not suggest or imply any kind of ownership. Smart
: pointers do indeed.
Good. Until you have to interface with a C-style library.

: > In a program that hasn't entered UB, references always refer to
one
: > valid object. When no additional feature is needed, using a
reference
: > contributes to the readability and safety of the code.
: > Why wouldn't you take advantage of that tool?
:
: Because I believe that reference semantics are more subtle than that
of
: pointer.
Well, I guess we each may have beliefs of our own.
I also have friends who believe that naked pointers have no place in
modern C++ code (which I disagree with).

I guess you're not looking forward to the introduction of
rvalue-references in C++0x -- I'm definitely a supporter of this
extension.

Kind regards,
Ivan

 

[Maxim Yegorushkin]

Ivan Vecerina wrote:

[]

: > Why wouldn't you take advantage of that tool?
:
: Because I believe that reference semantics are more subtle than that
of
: pointer.
Well, I guess we each may have beliefs of our own.
I also have friends who believe that naked pointers have no place in
modern C++ code (which I disagree with).

I agree, this all is a matter of taste.

I guess you're not looking forward to the introduction of
rvalue-references in C++0x -- I'm definitely a supporter of this
extension.

So am I.

 

[Dave Rahardja]

My experience is opposite.

Your mileage may vary, I guess.