The Point object is passed by value, so there is little or no benefit to declaring it const. In fact, to the compiler, the function signature is the same whether you include this const in front of a value parameter or not. For example:

int f( int ); 


int f( const int );  // redeclares f(int)


                     // no overloading, there's only one function


int g( int& );


int g( const int& ); // not the same as g(int&)


                     // g is overloaded

Point GetPoint( const int i )   { return points_[i]; } 

Same comment about the parameter type. Normally, const pass-by-value is unuseful and misleading at best.

This should be a const member function, since it doesn't change the state of the object.

If you're not returning a builtin type, such as int or long, return-by-value should usually return a const value.^[1] This assists client code by making sure the compiler emits an error if the caller tries to modify the temporary.

^[1] I want to point out that not everyone agrees with me on this point. In Lakos96 (pg. 618), the author argues against returning a const value, and points out that it is redundant for builtin types anyway (for example, returning "const int"), which he notes may interfere with template instantiation.

For example, the user might write something like "poly.GetPoint(i) = Point(2,2);". If this were intended to work, GetPoint() should have used return-by-reference and not return-by-value in the first place. As we will see later, it makes sense for GetPoint() to be a const member function for another reason: GetPoint() should be usable on const Polygon objects in operator+().

int   GetNumPoints()             { return points_.size(); } 

Again, the function should be const.

Incidentally, this is a good example of where not to write a const return-by-value. A return type of "const int" would be wrong in this case, because: (a) returning "const int" doesn't buy you anything, since the returned int is already an rvalue and so can't be modified; and (b) returning "const int" can interfere with template instantiation and is confusing, misleading, and probably fattening.

double GetArea() 


{


  if( area_ < 0 ) // if not yet calculated and cached


  {


    CalcArea();     // calculate now


  }


  return area_;


}

Even though this function modifies the object's internal state, it should be const. Why? Because this function does not modify the object's observable state. We are doing some caching here, but that's an internal implementation detail and the object is logically const even if it isn't physically const.

Corollary: The member variable area_ should be declared mutable. If your compiler doesn't support mutable yet, kludge this with a const_cast of area_ and write a comment telling the next person to remove the const_cast once mutable is available梑ut do make the function const.

private: 


  void InvalidateArea() { area_ = -1; }

This function ought also to be const, if for no other reason than consistency. Granted, semantically it will be called only from non-const functions, since its purpose is to invalidate the cached area_ when the object's state changes. But consistency and clarity are important to good programming style, so make this function const too.

void CalcArea() 


{


  area_ = 0;


  vector<Point>:: iterator i;


  for( i = points_.begin(); i != points_.end(); ++i )


  {


    area_ += /* some work */;


  }


}

This member function definitely should be const, because it does not alter the externally visible state of the object. Note also that this function is called only from another const member function, namely GetArea().

The iterator should not change the state of the points_ collection, so it ought to be a const_iterator.

   vector<Point> points_; 


   double        area_;


};





Polygon operator+( Polygon& lhs, Polygon& rhs )


{

The parameters should be passed by references to const, of course.

Again, the return-by-value of an object should be const.

Polygon ret = lhs; 


int last = rhs.GetNumPoints();

Because last should never change, say so by making its type "const int".

  for( int i = 0; i < last; ++i ) // concatenate 


  {


    ret.AddPoint( rhs.GetPoint(i) );


  }


  return ret;


}

(Once we make rhs a reference-to-const parameter, we see another reason why GetPoint() should be a const member function.)

void f( const Polygon& poly ) 


{


  const_cast<Polygon&>(poly).AddPoint( Point(0,0) );


}

Bonus: Using the result of the const_cast is undefined if the referenced object was declared as const梬hich it is in the case of f(cpoly) below. The parameter isn't really const, so don't declare it as const. It's tantamount to lying.

void g( Polygon& const rPoly ) { rPoly.AddPoint( Point(1,1) ); } 

This const is not only useless, because references are already const inasmuch as they cannot be reseated (changed to refer to a different object), but actually illegal.

void h( Polygon* const pPoly ) { pPoly->AddPoint( Point(2,2) ); } 

This const is equally useless, but for a different reason: Because we're passing the pointer by value, this makes as little sense as passing a parameter "const int" above. Think about it梚t's exactly the same thing, because this const merely promises that you won't modify the pointer value. That's not a very useful promise, because the caller can't possibly care or be affected by that decision.

(If, in looking for the "bonus" part, you said something about this function being uncompilable梥orry, it's quite legal C++. You were probably thinking of putting the const to the left of the *, which would have made the function body illegal.)

int main() 


{


  Polygon poly;


  const Polygon cpoly;


  f(poly);

This is fine.

f(cpoly); 

This causes undefined results when f() tries to cast away the const-ness of its parameter and then modify it. See above.

g(poly); 

This is fine.

  h(&poly); 


}

This is fine.