Our kernel CONCEPT is representation-independent. There is no assumption on how a Point_3, for example, is represented. In particular, it need not be represented by Cartesian coordinates. Thus writing code that RELIES on being able to change these coordinates may lead to inefficient code. Our basic library algorithms are designed around the predicates that operate on the geometric objects and do not require this mutability.

Non-modifiability also makes the underlying handle-rep scheme used (by default) to allocate, copy, etc., CGAL objects somewhat easier. We recognize, however, that users may WANT this flexibility and thus are working on PROVIDING mutable kernel objects.

The only way to do this currently is to construct a new point and assign it to the old one:

use p = Point_2 (p.x (), p.y () +1);

as if you would like to do p.y () += 1.

Our kernel concept is representation-independent. There is no assumption on how a Point_3, for example, is represented. In particular, it need not be represented by Cartesian coordinates. Thus writing code that relies on being able to change these coordinates may lead to inefficient code. Our basic library algorithms are designed around the predicates that operate on the geometric objects and do not require this mutability.

Non-modifiability also makes the underlying handle-rep scheme used (by default) to allocate, copy, etc., CGAL objects somewhat easier. We recognize, however, that users may want this flexibility and thus are working on providing mutable kernel objects.

The only way to do this currently is to construct a new point and assign it to the old one:

use p = Point_2 (p.x (), p.y () +1);

as if you would like to do p.y () += 1.