Should I use -> or . ?

Hello all ... I am trying to learn C++ ... again (PHP is so much easier).

Here is my question:

Should I use the arrow operator to access class methods and the dot operator to access class members?

Here is the code I am using:

Code:

---

#ifndef CREATURE

class Creature {
  public:
  Creature(){
    std::cout << "Creating Creature" << std::endl;
  }
 
  ~Creature(){
    std::cout << "Destroying Creature" << std::endl;
  }
 
  void eat(){
    std::cout << "Creature is eating" << std::endl;
  }
 
  void setBloodType(char* bType){
    bloodType = bType;
  }
 
  char* getBloodType(){
    return bloodType;
  }
 
  protected:
    char* bloodType;
 
};

#define CREATURE 1
#endif

---

Code:

---

#ifndef MAMMAL

class Mammal : public Creature {
 
  public:
   
    Mammal(){
      std::cout << "Creating Mammal" << std::endl;
    }

    ~Mammal(){
      std::cout << "Destroying Mammal" << std::endl;
    }
   
    void eat(){
      std::cout << "Mammal is eating" << std::endl;
    }
 
};

#define MAMMAL 1
#endif

---

Code:

---

#include<iostream>
#include "Creature.cpp"
#include "Mammal.cpp"

using namespace std;

int main(){
 
  Creature *creature = new Creature;
  char* CreatureBloodType = "Unknown";
  creature->setBloodType(CreatureBloodType);
  creature->eat();
  cout << "Creature blood type is " << creature->getBloodType() << endl;
  delete creature;
 
  char* MammalBloodType = "O Negative";
  Mammal *mammal = new Mammal;
  mammal->eat();
  mammal->setBloodType(MammalBloodType);
  cout << "Mammal blood type is " << mammal->getBloodType() << endl;
  delete mammal;
 
  system("PAUSE");
  return 0;
}

---

TIA!

You use -> when the variable is a pointer to an object and . when the variable is the object.

Come to think of it is there really any good reason for the existance of "->" and not using . for pointers too?

So I would (usually) only be using the dot operator within the classes?

From what I have seen thus far, you instantiate an object as a pointer.

Quote:

---

Originally Posted by Kudose

So I would (usually) only be using the dot operator within the classes

---

That really depends on what kind of variables you will operate on.

Quote:

---

Originally Posted by Tux0r

Come to think of it is there really any good reason for the existance of "->" and not using . for pointers too?

---

I am learning, obvisouly, but replacing the arrows with dots breaks everything ( as I am working with the object as a pointer :) )

Could you please elaborate on this?

Quote:

---

Originally Posted by Kudose

I am learning, obvisouly, but replacing the arrows with dots breaks everything ( as I am working with the object as a pointer :) )

Could you please elaborate on this?

---

No, could you? I really don't see why they had to do this. And I have been programming in C++ for years.

Quote:

---

Originally Posted by Tux0r

Come to think of it is there really any good reason for the existance of "->" and not using . for pointers too?

---

Keep in mind that pointers are a legacy from C.
And pointers are variables that stores memory addresses, thus they can be reassigned and all that. So to access the members of an object pointed to by a pointer, you'd have to dereference the pointer first and then use the . operator.
But since the . operator has higher precedence than the * operator, we have to prioritize it:
(*p).mymember.
This is obviously awkward syntax and even more so when there are several indirections, so they invented the -> syntax to replace it.

Quote:

---

Originally Posted by Kudose

So I would (usually) only be using the dot operator within the classes?

From what I have seen thus far, you instantiate an object as a pointer.

---

Not everything needs to be created with new. In your code, there is no need.
Just type the name: Creature creature; and there you have your object. No need for new, no need for delete.

Also, you have mixed up source files and headers. Class declarations should go into headers (.h files). Implementation of the class should go into a source file (.cpp file).
And never ever include .cpp files. They are compiled separately. Header files can be included.

Might not matter in this particular example as you're not using a generic Creature pointer to a Mammal object anywhere, but these:

Code:

---

class Creature {
 
  ~Creature(){
    std::cout << "Destroying Creature" << std::endl;
  }
 
  void eat(){
    std::cout << "Creature is eating" << std::endl;
  }

---

...should really be virtual.

Quote:

---

Originally Posted by Tux0r

Come to think of it is there really any good reason for the existance of "->" and not using . for pointers too?

---

Yes.

I am digesting the info above, but before I forget: I spy a Weedpacket. :D

Quote:

---

Originally Posted by Elysia

Keep in mind that pointers are a legacy from C.
And pointers are variables that stores memory addresses, thus they can be reassigned and all that. So to access the members of an object pointed to by a pointer, you'd have to dereference the pointer first and then use the . operator.
But since the . operator has higher precedence than the * operator, we have to prioritize it:
(*p).mymember.
This is obviously awkward syntax and even more so when there are several indirections, so they invented the -> syntax to replace it.

---

That helps a lot.

Quote:

---

Originally Posted by Elysia

Not everything needs to be created with new. In your code, there is no need.
Just type the name: Creature creature; and there you have your object. No need for new, no need for delete.

---

In which instances would I want to create an object using new?

Quote:

---

Originally Posted by Elysia

Also, you have mixed up source files and headers. Class declarations should go into headers (.h files). Implementation of the class should go into a source file (.cpp file).
And never ever include .cpp files. They are compiled separately. Header files can be included.

---

Yes, I just didn't do this for this small learning task. I would include the cpp file in the h (header) file and include the header file in my main code ... correct?

Quote:

---

Originally Posted by hk_mp5kpdw

Might not matter in this particular example as you're not using a generic Creature pointer to a Mammal object anywhere, but these:

Code:

---

class Creature {
 
  ~Creature(){
    std::cout << "Destroying Creature" << std::endl;
  }
 
  void eat(){
    std::cout << "Creature is eating" << std::endl;
  }

---

...should really be virtual.

---

Am I correct in thinking that a virtual method allows it to be overridden by derived classes?

So, if I created Dog class, the Creature and Mammal eat/destructor methods should be virtual?

Quote:

---

Originally Posted by Elysia

Keep in mind that pointers are a legacy from C.
And pointers are variables that stores memory addresses, thus they can be reassigned and all that. So to access the members of an object pointed to by a pointer, you'd have to dereference the pointer first and then use the . operator.
But since the . operator has higher precedence than the * operator, we have to prioritize it:
(*p).mymember.

---

I think the question was more along the lines of, the compiler does in fact know whether the variable is a pointer or an object, so why can't it apply an implicit dereference if it's a pointer? Then we would say "obj.foo()" and "ptrToObj.foo()" in either case. In other words, if the LHS is a pointer, magically transform "." into "->".

After thinking a bit, I can't come up with a compelling reason why it couldn't have been done that way. At first I thought it might negatively impact code clarity, by making it impossible to tell at a glance whether the LHS is a pointer or an object. But if you accept that argument, then you should also accept that C++ references are equally confusing because they "magically" dereference themselves wherever they are used, and are difficult to distinguish in precisely the same way.

I happen to think that C++ references are NOT confusing, and similarly, I don't think it would be confusing to have a single operator for member access in both objects and pointers, but that just isn't how it is, and it is never going to change.

Quote:

---

Originally Posted by Kudose

In which instances would I want to create an object using new?

---

Objects created that way I showed are created on the stack and disappear whenever the function ends. So if you want the objects to last longer than that, then the new keyword is the answer. It's called dynamic memory.

Quote:

---

Yes, I just didn't do this for this small learning task. I would include the cpp file in the h (header) file and include the header file in my main code ... correct?

---

No, you never include any .cpp files. The compiler will compile all of those.
You are correct that you include the header in your main code.

Quote:

---

Originally Posted by Kudose

Am I correct in thinking that a virtual method allows it to be overridden by derived classes?

So, if I created Dog class, the Creature and Mammal eat/destructor methods should be virtual?

---

This is a topic called polymorphism. If you wanted to store a pointer or reference to a Mammal via a Creature* or Creature& variable, then you can make certain functions virtual. By doing so, the compiler looks up the actual type of the object and call the right function.
Try this code with and without virtual before eat (in both classes) and look at the results.

Code:

---

Mammal m;
Creature& c = m;
m.eat();

---

There is usually a rule that says that when you have a virtual function in a class, the destructor of the class should also be virtual. The reason is because of the same code snippet above.

Quote:

---

Originally Posted by brewbuck

I think the question was more along the lines of, the compiler does in fact know whether the variable is a pointer or an object, so why can't it apply an implicit dereference if it's a pointer? Then we would say "obj.foo()" and "ptrToObj.foo()" in either case. In other words, if the LHS is a pointer, magically transform "." into "->".

After thinking a bit, I can't come up with a compelling reason why it couldn't have been done that way. At first I thought it might negatively impact code clarity, by making it impossible to tell at a glance whether the LHS is a pointer or an object. But if you accept that argument, then you should also accept that C++ references are equally confusing because they "magically" dereference themselves wherever they are used, and are difficult to distinguish in precisely the same way.

I happen to think that C++ references are NOT confusing, and similarly, I don't think it would be confusing to have a single operator for member access in both objects and pointers, but that just isn't how it is, and it is never going to change.

---

The way I see it, it's the C legacy that created that. Now, why C never did this is another matter. But I suppose it's just to separate pointers from pointees, some language thingy.

Quote:

---

Originally Posted by brewbuck

In other words, if the LHS is a pointer, magically transform "." into "->".

---

Well, here you have the first problem. Code semantics are being hidden away, making the code less clear. And isn't this precisely what should be avoided on a strongly typed language? And wouldn't that just complicate the compiler's life too?

I believe we can agree (*ptr).member() needs an alternative. However, I don't think it ever crossed anyone's mind to replace it with the dereference operator simply because there is important information that suddenly is lost and a semantics contract being broken.

Quote:

---

But if you accept that argument, then you should also accept that C++ references are equally confusing because they "magically" dereference themselves wherever they are used, and are difficult to distinguish in precisely the same way.

---

Absolutely not! :)
You may look at references as const pointers, but regardless of how they are implemented by the compiler, their semantics are vastly different. A reference is never dereferenced. Or to put it bluntly, a reference is not a pointer, it is a reference.

Quote:

---

Originally Posted by Mario F.

Absolutely not! :)
You may look at references as const pointers, but regardless of how they are implemented by the compiler, their semantics are vastly different. A reference is never dereferenced. Or to put it bluntly, a reference is not a pointer, it is a reference.

---

My point is, in the following code snippet, can you tell me whether x is a reference to an object, or an actual object?

Code:

---

foo.bar();

---

I don't see how that's different from asking, is foo an object or a pointer to an object?

I have another question about header files ... I have been searching and cannot figure this out.

testing.h

Code:

---

#ifndef TESTING_H
#define TESTING_H

int test();

#endif

---

testing.cpp

Code:

---

#include "testing.h"

int test(){
  return 3;
}

---

test.cpp

Code:

---

#include<iostream>
#include "testing.h"

int main(){
 
  std::cout << test();
 
  system("PAUSE");
  return 0;
}

---

[Linker error] undefined reference to `test()' using Dev-C++

Does anyone know why I would get this?

TIA!

If you're building with a project, you have to include both testing.cpp and test.cpp in the project so both can be compiled and then linked together.

As it is, you are only compiling test.cpp, which can see the declaration for test() but cannot link to the definition.

Aside from the linking issue, Dev-C++ is a bit outdated. I would recommend a new IDE.
Some good IDEs that are available can be found at: http://cpwiki.sf.net/IDE
Visual Studio and Code::Blocks are two favorites.

Quote:

---

Originally Posted by brewbuck

My point is, in the following code snippet, can you tell me whether x is a reference to an object, or an actual object?

Code:

---

foo.bar();

---

I don't see how that's different from asking, is foo an object or a pointer to an object?

---

References and pointers have different semantics though. Asking if something is an object or an alias (aka reference) of that object really doesn't matter. Thantos is a reference to me, so if you address me as Thantos or as my real name it doesn't really make any difference.

Quote:

---

Originally Posted by brewbuck

My point is, in the following code snippet, can you tell me whether x is a reference to an object, or an actual object?

Code:

---

foo.bar();

---

I don't see how that's different from asking, is foo an object or a pointer to an object?

---

Ah, I see you point.
I don't have the vocabulary to put this in the right words. But I believe it is largely irrelevant to know if it is a reference or the actual object, since any operator semantics remain the same.

However, * and -> offer vastly different semantics. Let me remind you of their overload declarations:

Code:

---

myClass &operator*() { /*...*/ }
myClass *operator->() { /*...*/ }
const myClass &operator*() const { /*...*/ }
const myClass *operator->() const { /*...*/ }

---

>> Asking if something is an object or an alias (aka reference) of that object really doesn't matter.
When an object goes out of scope, it is destroyed. When a reference (or alias) goes out of scope, the object is not destroyed. That is as much of a difference as the difference between a pointer and an object with respect to this question.

>> However, * and -> offer vastly different semantics.
The question was between . and ->, not * and ->.

Installed Code::Blocks ... looks like a winner.

I got everything up and running. Thanks for everyone's help and the interesting reading!

Quote:

---

And never ever include .cpp files. They are compiled separately. Header files can be included.

---

You can include .cpp files as .inl or as .hpp when using templates if you want to put your definitions in a separate file. I prefer .inl but I have seen it done as .cpp.

btw, the "blood type" function is implemented wrong
you can't just make a char pointer data member point at another char
you gotta allocate an indepent piece of memory for it

>> you can't just make a char pointer data member point at another char
In this case you can, because they are all pointers to string literals.

They should be const char* variables which would make this more clear, but it's still legal as is and should work.

Quote:

---

Originally Posted by brewbuck

My point is, in the following code snippet, can you tell me whether x is a reference to an object, or an actual object?

Code:

---

foo.bar();

---

I don't see how that's different from asking, is foo an object or a pointer to an object?

---

The pointer could be null. This is the most significant difference between references and pointers: references cannot ever be null, and if you use them properly, they cannot ever be invalid either. A pointer, on the other hand, can be null, and it's not uncommon for it to be invalid either.

Thus, dereferencing a reference can be implicit (by using the value directly or by using the direct member access operator), whereas dereferencing a pointer really should always be explicit, using * or ->.

Well, my GCC allows a NULL reference:

Code:

---

#include <iostream>

int main(void)
{
    int &ref = *(int *)0;
    std::cout << "&ref is 0" << std::endl;
    std::cout << "ref is now " << ref << std::endl;
}

---

The code crashes after printing "&ref is now 0". That's not standard, is it?

Quote:

---

Originally Posted by Brafil

That's not standard, is it?

---

That is undefined behaviour due to an attempt to dereference a null pointer.

null reference isn't the same as address 0. A null reference would be a reference that doesn't reference anything. It logically doesn't make any sense. Even if it referenced nothing it would still be referencing something (the nothingness).

In the example it did reference something, that something just happened to be invalid.

But then a pointer also always points to something (whether it is nothing or invalid) and in this regard there isn't any difference?

In a correct program a pointer can point to nothing but a reference cannot refer to nothing.

So, when exactly would one use the

Creature creature;
Creature creature = new Creature();
Creature* creature

initialisations?

Can anyone think of any use cases to split up how you would use them please?

Quote:

---

Originally Posted by Swordsman

Can anyone think of any use cases to split up how you would use them please?

---

Generally, I would prefer to write:

Code:

---

Creature creature;

---

The idea being that the Creature class (it is a class, right?) would manage its own memory, so I need not worry about that.

This one is unusual:

Code:

---

Creature creature = new Creature;

---

Unless you really intend for Creature to have a constructor that takes a Creature*, you probably wanted to write:

Code:

---

Creature* creature = new Creature;

---

I would try not to use this, but instead use a smart pointer such as std::auto_ptr or std::tr1::shared_ptr, e.g.,

Code:

---

std::auto_ptr<Creature> creature(new Creature);

---

but note note std::auto_ptr will be deprecated in the next version of C++ in favour of std::unique_ptr, which is not part of the C++ standard library at this point of time. One "use case" that comes to mind would be when you want the lifetime of the object to be beyond the scope in which it was created.

Quote:

---

Originally Posted by laserlight

I would try not to use this, but instead use a smart pointer such as std::auto_ptr or std::tr1::shared_ptr, e.g.,

---

Also auto_ptr doen't support proper deallocation on arrays. For that you need boost::scoped_ptr or something similar. Also be careful about multiple references with auto_ptrs, but they are preferred for RAII.

Quote:

---

Originally Posted by linuxdude

Also auto_ptr doen't support proper deallocation on arrays. For that you need boost::scoped_ptr or something similar.

---

No, for that you should use a container class, e.g., std::vector. boost::scoped_ptr would have the same "problem" as std::auto_ptr in that respect.

Quote:

---

Originally Posted by laserlight

No, for that you should use a container class, e.g., std::vector. boost::scoped_ptr would have the same "problem" as std::auto_ptr in that respect.

---

Sorry, I meant boost::scoped_array.

BTW, does the standard guarantee that doing this trick (int &ref = *(int *)NULL) crashes immediately? Else you could do

Code:

---

#include <iostream>

template <typename Type>
void swap_by_pointers(Type *a, Type *b)
{
    if (a != NULL && b != NULL) {
        Type temp = *a;
        *a = *b;
        *b = temp;
    }
}

template <typename Type>
void swap(Type &a, Type &b)
{
    swap_by_pointers(&a, &b);
}

int main(void)
{
    int four = 4;
    int &ref = *(int *)NULL;
    swap(four, ref);
    std::cout << "four is " << four << ". (Can't show ref)" << std::endl;
}

---

Quote:

---

BTW, does the standard guarantee that doing this trick (int &ref = *(int *)NULL) crashes immediately?

---

I think we already said that it's undefined behavior. Look it up.