"Anis Benyelloul" <benyelloul@mailbolt.com> wrote
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
I had a quick look. Thanks !
You would need to change the licence for boost. Ahem.. I assume you're talking about the manual, because the code *is* under the Boost Licence. And about the manual, I don't recall having read something that forbids FDL for manuals ... maybe be I missed it ?
Ok .. I dont know how boost sees this.
Not quite sure I understand the reason behind the parameter for points. You're talking about the template parameter of geom::point<> ? Well, it is an implementation type (as explained in the manual), something that tells geom::point<> how you'd like to implement the notion of ``point'' (as XY, as XYZ, as polar coordinates ... etc). The interface is familiar :
url<http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/streamlines.hpp> Recently howver I use a struct with x and y members... its less typing ;-) Ok. I understand the use of a common type for cartesian and polar coordinates. Alternatively these two types could be provided as complete useable types, with a common interface. A viable alternative to the wrapper is simply to provide a conversion from one to the other type. Specialising the traits class looks to be nearly the same work as writing these from scratch with a common interface. One could provide something similar by overloaded functions: I dont see the advantage in wrapping other libraries point types. I would want precisely defined semantics on the parameters of a point. For example I would expect the semantics of float versus integer value_types to be defined separately. Allowing use of user defined point systems would appear to make this type of control of the specification much more difficult, if not impossible. Not sure what units angles are in. Is it degrees or radians? radians is my preference. FWIW I use specific type safee angle types. This allows conversions between the two families of angular unit. I also use types representing lengths in graphics. IOW I use a point<pqs::length::mm> type etc. This provides graphics data with unit information independent of the device its currently being displayed on. Its not a solution for every case but where the units of an entity is fixed it provides this information with no runtime space overhead. See my site at http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html I strongly disagree with the statement in the documentation: " Indeed, a ``2D point'' is just a 3D point whose implementation doesn't actually reserve memory space for a Z attribute." 2D space has no notion of another dimension. There is no Z attribute. Projections of 3D objects onto a 2D plane are not limited to truncation of their z-dimension. Mixing 2D and 3D points doesnt actually happen in my experience. They live in separate spaces. 3D points are mapped to 2D points by applying a transform(projection). Some sort of matrix operations on 2D and 3D points should also be available(which will require conversion to homogeneous coordinates).
Why no lines? Maybe in the next version ? But think of this, what is a line ? isn't it a std::pair<point, point> ? Also, I had the idea of geom::region (a region of the plan/space) a collection of boxes, geom::polygon<> a collection of points ... etc ... But lets make sure we have the best points and rectangles of the planet first :)...
The box here is useful for a GUI viewport or window, an attribute of the current output device. IMO Its a mistake for a geometry library to get involved with this low level stuff too early. Geometrically a box is a 2D region bounded by geometric *1* lines, with no guarantee of its attitude. Why not start with the most primitive concepts, eg geometric points, lines, circles arcs, curves and regions? As for lines, one could use std::pair, but IMO a 'line' type is a clearer statement when reading code. That said, there should be some form of mechanism for graphical output on various platforms/ devices, but again without this affecting the core geometry library. generically this requires some means of converting points between various coordinate systems. Sorry for all the criticism. As you may gather I have my own ideas on what I want from a geometry library... looking forward to hearing your views ... * 1* as opposed to lines which have colour and thickness. These attributes, though required for output are not necessary from a geometric viewpoint Andy Little