If the compiler let you do that, it would be an easy way to break exactly what const references were meant to protect: the data being referred to that cannot be changed.
No. They're operators
A memory address.
myNumbers is an array of integers-that is, myNumbers is a pointer to a memory location that holds 100 integers, pointing to the first at index 0. It is the static alternative of the following:
int* myNumbers = new int ; // dynamically allocated array
// use myNumbers
myArrays, on the other hand, is an array of 100 pointers, each pointer being capable of pointing to an integer or an array of integers.
Essentially none. When you instantiate a class, you get an instance that can also be called an object.
If you have a pointer to an object, the pointer operator would be best suited. If you have instantiated an object as a local variable on the stack, then the dot operator is best suited.
If your class' data members are well-programmed smart pointers, string classes, or
STL containers such as std::vector, then the default copy constructor inserted
by the compiler ensures that their respective copy constructors are invoked.
However, if your class has raw pointer members (such as int* for a dynamic array instead of std::vector<int>), you need to supply a correctly programmed copy constructor that ensures a deep copy of an array during function calls where an object of the class is passed by value.
Yes. If an instance of a class can be created without arguments, then the class is said to have a default constructor. A class can have only one default constructor.
From a technical viewpoint, making Human::age a public member would work as well. However, from a design point of view, keeping member data private is a good idea. Accessor functions such as GetAge() or SetAge() are a refined and scalable way to access this private data, allowing you to perform error checks for instance before the value of Human::age is set or reset.