- Updated.

Packages/Cartesian_kernel/TODO

@@ -3,16 +3,27 @@ Stuff to look at, as time permits:
 
 - Tests :
   - M$VC++ before submitting (especially for CGAL_TYPENAME_BUG).
+    maybe simply put the "#define typename" back.
   - GCOV
   - G++ 2.97.
   - Write a Checker for full kernels, like Pm_traits_checker.h ?
 
+- Stuff is missing in Kernel_traits_common.h for Sphere3.
+  (idem for homogeneous and co)
+- Try to remove the default copy ctors (wait for some stabilization first).
+
+- Cd must come back to life somehow...  Currently, I've disabled it ~totally
+  in Cartesian.h.  Same thing for Conics...
+
+- Factorize all the new kernel traits stuff of the different kernels in a
+  separate .def file, included by all kernels ?
+  Already done, but let's try it on SimpleCartesian_v2 when ready to test,
+  then propose it to Stefan.
+
 - Handles :
   - Having a proper Handle_for_virtual<> is becoming important...
     - It must have the same interface than Handle_for<>
     - Must use the allocator, see Stefan's mail.
-  - Replace ptr by ptr() ?
-  - Provide a Dummy_Handle_for<>.
 
 - Aff_transformations :
   - Finish merging .C files in corresponding .h files.
@@ -26,39 +37,12 @@ Stuff to look at, as time permits:
 - Use CGAL_TYPENAME_MSVC_NULL instead of "#define typename".
   Only in the template parameters, right ?
 - Merging Cartesian and SimpleCartesian :
-  Currently, there are 10000 lines of code in SimpleCartesian kernel, mostly
-  copy-pasted and adapted from the Cartesian kernel.  This is evil in itself
-  from the maintainance point of view.  I think only the low level (FT-based)
-  predicates and constructions are common (and this is already diverging).
-  Moreover, I think it would be good for the Cartesian kernel to somehow
-  have access to raw points/objects, in order to, for example:
+  Benefits are :
+  - possibility to specify a different allocator easily, including different
+    ones in the same kernel.
   - easy to have Iso_rectangleC2 being a twotuple of non ref-counted points,
     whereas now it's a twotuple of ref-counted points, which is a pure lost.
     (all local, temporary objects don't need any ref-counting)
-  - still my big plans of a kernel offering filtered constructions would be
-    far easier and cleaner if based on the primitives of such a kernel.
-  So, I propose to merge much more of these two kernels : I propose that the
-  ref-counted kernel becomes just a set of wrappers around non ref-counted
-  kernel objects and associated predicates/constructions.
-  So basically, I would like to offer another non-ref counted Cartesian kernel
-  (thus replacing the current SimpleCartesian in the end).
-  Having a central place for the code and a single maintainer for those 2
-  kernels seems a better solution than the current one (which will quickly
-  diverge, like homogeneous and Cartesian did in the past).
-  What do you think ?
-  [ Note : another possibility would have been to have a template parameter
-  to the kernel specifying the ref-countability, and having partial
-  specialization of some rep classes.  But I fear a well-known "compiler"
-  would have problems with this... ]
-  - Maybe easier : in Cartesian<>, define :
-   typedef Handle_for <twotuple<FT> > Handled_Point_2;
-
-   And derive :
-   template <class R>
-   PointC2 : public R::Handled_Point_2
-   And similarly for SimpleCartesian.
-   Try it...
-   This will allow to pass an Allocator parameter via the kernel traits.
 - ::bbox() robustness issues : it's not robust, since basically, we use
   to_double().
   The homogeneous kernel uses an epsilon to get this right, in the case
@@ -81,18 +65,6 @@ Stuff to look at, as time permits:
 - Why can't we simply have : typedef Iso_rectangleC2<double> Bbox_2;  ?
   - Iso_rectangleC2 stores a Twotuple<Point_2>, which means they are
     ref-counted, which is sub-optimal...  See above.
-- Getting rid of the partial kernels Cartesian_2 and Cartesian_3 ?  This is a
-  lot (1Kloc) of redundant code, and this is something only aimed at reducing
-  compile time, for which I have some serious doubts anyway.  So:
-  - XXX: Make sure it's not needed.  Cartesian seems built on top of it...
-  - Make a compile time benchmark between Cartesian_2 vs Cartesian, say, with
-    Triangulation_2.
-  - Herve's opinion (original author) is it's not important.
-  - Check it's not documented.  Grep it's not used.
-  - Ask on cgal-develop if anyone uses/needs this.
-  - Remove.
-- Factorize all the new kernel traits stuff of the different kernels in a
-  separate .def file, included by all kernels ?
 - Orientation of Circle_2 and Sphere_3.  I wonder if it's used anywhere.
   Wouldn't it have been better if the kernel circles and spheres were not
   oriented, and if someone needs an orientation, he will be able to build one
@@ -102,8 +74,6 @@ Stuff to look at, as time permits:
   Maybe it's too late for a change, but maybe not ?
   Or maybe worth having a separate Non_oriented_Circle in the kernel ?
   (the oriented one using code from the non-oriented one...)
-- How does the test-suite runs on the kernel ?  I never figured that out ;)
-  Run GCOV on it, I think it's _desperately_ needed...
 - Test Advanced Kernel, Cd.
 - Put the predicates that are marked /*CGAL_NO_FILTER*/ in a separate file,
   say <predicates/no_filter_kernel_ftC2.h> ?  This will simplify the script

Packages/Cartesian_kernel/changes.txt

@@ -15,6 +15,10 @@ Version 6.0 (?? ????? 00)
   We now do the same reasonnable thing as in the homogeneous kernel.
 - Got rid of empty useless destructors.
 - Changed ptr-> access to Ptr()-> .
+- Removed Cartesian_2 and Cartesian_3.
+- Handle and Representation specification come now from Cartesian<>,
+  so that we can customize them easily.
+- A few fixes for the advanced kernel.
 - Various cleanups.
 
 --- CGAL 2.2 is out ---