
Boost : 
From: Reece Dunn (msclrhd_at_[hidden])
Date: 20041105 13:21:15
Andy Little wrote:
> "Reece Dunn" <msclrhd_at_[hidden]> wrote in message
>>There are also platformindependant versions of position (NSPoint, POINT,
>>etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that
>
> FWIW I find the difference between Point and Size largely irrelevent
>
> In MFC:
> CPoint (CSize );
> CSize(CPoint );
>
> tending to make me think that they could be covered by one type eg xy_pair;
MFC gets the intended use of CPoint/CSize wrong.
In a mathematical sense, a point is a 0size location in an nD
coordinate system. In this case, it is a 2D coordinate system, so is
(x,y). This is used for positioning, e.g. moving the graphics cursor, so
I call it gui::position. It does not make sense to perform point [+*/]=
point since points are locations in a space (how do I add the location
of my house to the location of Jupiter)?
The size type stores width and height information, so it can be treated
as a 2D vector. In this case, standard arithmetic operations make sense.
Also, it is possible for sizes to interact with points, e.g. point += size.
If you do point  point, then the resulting type is a size type that
represents the distance between the two points.
So in a mathematical sense, the difference between size and position is
entirely relevant, it's just that some libraries (not mentioning names)
do not adhere to the above mathematical rules.
>>At the moment, you need to register Win32/64 window classes using:
>> gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE
>>);
>>but I am looking to abstract this.
>
> I reckon the X or Fresco http://www.fresco.org ;) end should be
> tackled too ...
Noted. I was planning on getting support for WinXX, Cocoa (MacOS), X11,
GTK+ and Motif. I will need assistance to port to some of these APIs.
Regards,
Reece
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk