|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r56862 - in sandbox/ggl/formal_review_request/libs/ggl/doc: doxygen_input/pages doxygen_output/html
From: barend.gehrels_at_[hidden]
Date: 2009-10-15 04:39:11
Author: barendgehrels
Date: 2009-10-15 04:39:09 EDT (Thu, 15 Oct 2009)
New Revision: 56862
URL: http://svn.boost.org/trac/boost/changeset/56862
Log:
Doc fix
Text files modified:
sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_input/pages/doxygen_design_cross_section.hpp | 11 ++++++-----
sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_output/html/design.html | 5 ++++-
2 files changed, 10 insertions(+), 6 deletions(-)
Modified: sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_input/pages/doxygen_design_cross_section.hpp
==============================================================================
--- sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_input/pages/doxygen_design_cross_section.hpp (original)
+++ sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_input/pages/doxygen_design_cross_section.hpp 2009-10-15 04:39:09 EDT (Thu, 15 Oct 2009)
@@ -568,11 +568,12 @@
\section par9 Point concept
The five traits classes mentioned in the paragraphs above form together the Point Concept. Any point type for which specializations are implemented in the traits namespace should be handled correctly by the library. So the Point concept consists of:
- * a specialization for traits::tag
- * a specialization for traits::coordinate_system
- * a specialization for traits::coordinate_type
- * a specialization for traits::dimension
- * a specialization for traits::access
+- a specialization for traits::tag
+- a specialization for traits::coordinate_system
+- a specialization for traits::coordinate_type
+- a specialization for traits::dimension
+- a specialization for traits::access
+
The last one is a class, containing a function, the first four are meta-functions.
So we now have agnosticism for the number of dimensions, agnosticism for coordinate systems, our design can handle any coordinate type, and it can handle different geometry types.
Furthermore we can specify our own strategies, the code will not compile in case of two points with different dimensions (because of the assertion), and it will not compile for two points with different coordinate systems (because there is no specialization).
Modified: sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_output/html/design.html
==============================================================================
--- sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_output/html/design.html (original)
+++ sandbox/ggl/formal_review_request/libs/ggl/doc/doxygen_output/html/design.html 2009-10-15 04:39:09 EDT (Thu, 15 Oct 2009)
@@ -410,7 +410,10 @@
</pre></div><p>
where a strategy is specified explicitly and constructed with a radius.<h2><a class="anchor" name="par9">
Point concept</a></h2>
-The five traits classes mentioned in the paragraphs above form together the Point Concept. Any point type for which specializations are implemented in the traits namespace should be handled correctly by the library. So the Point concept consists of: a specialization for traits::tag a specialization for traits::coordinate_system a specialization for traits::coordinate_type a specialization for traits::dimension a specialization for traits::access The last one is a class, containing a function, the first four are meta-functions. So we now have agnosticism for the number of dimensions, agnosticism for coordinate systems, our design can handle any coordinate type, and it can handle different geometry types. Furthermore we can specify our own strategies, the code will not compile in case of two points with different dimensions (because of the assertion), and it will not compile for two points with different coordinate systems (because there is no specialization). We still have the distance function returning dou
ble. Next paragraph will solve that.<h2><a class="anchor" name="par10">
+The five traits classes mentioned in the paragraphs above form together the Point Concept. Any point type for which specializations are implemented in the traits namespace should be handled correctly by the library. So the Point concept consists of:<ul>
+<li>a specialization for traits::tag</li><li>a specialization for traits::coordinate_system</li><li>a specialization for traits::coordinate_type</li><li>a specialization for traits::dimension</li><li>a specialization for traits::access</li></ul>
+<p>
+The last one is a class, containing a function, the first four are meta-functions. So we now have agnosticism for the number of dimensions, agnosticism for coordinate systems, our design can handle any coordinate type, and it can handle different geometry types. Furthermore we can specify our own strategies, the code will not compile in case of two points with different dimensions (because of the assertion), and it will not compile for two points with different coordinate systems (because there is no specialization). We still have the distance function returning double. Next paragraph will solve that.<h2><a class="anchor" name="par10">
Return type</a></h2>
We promised that calling sqrt was not always necessary. So we define a distance result struct that contains the squared value and is convertible to a double value. This, however, only has to be done for Pythagoras. The spherical distance functions do not take the square root so for them it is not necessary to avoid the expensive square root call; they can just return their distance. So the distance result struct is dependant on strategy, therefore made a member type of the strategy, looking like this: <div class="fragment"><pre class="fragment"><span class="keyword">template</span><<span class="keyword">typename</span> T = <span class="keywordtype">double</span>>
<span class="keyword">struct </span>cartesian_distance
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk