Dave Harris wrote:
In-Reply-To: <cpsv4p$foa$1@sea.gmane.org> michaeltoksvig@yahoo.com (michael toksvig) wrote (abridged):
you might consider adding operator[] to point and size
also, consider defining area in terms of 2 points, and adding operator[] to that, too
I was about to say the same thing :-) I'd go further, and expose the array.
class box { point data_[2]; [snip] };
I think that this is the wrong representation.
This is because you will almost certainly want transforms that act on arrays of points, and it will sometimes be convenient if they can act on rectangles too.
Translation: a.pos += gui::size( 5, 7 ); Scaling: a.size += gui::size( 10, 20 ); Rotation: n/a since you are assuming that each side has an angle of 90 degrees (allowing for two point representations).
I would provide get/set methods which are independent of representation. I'd consider allowing things like ++box.top() too. Currently I think the convenience is not worth the loss of purity. ++box[0][1] should work, though.
If you have point high, low; then which corner is "high"? Likewise, using top_left, bottom_right is bad. In general, storing a rectangle as a set of two points is the wrong representation, especially for portability. Windows defines (0, 0) to be the top left corner, while Mac/Cocoa define it to be the bottom left corner. Therefore, in order to extract the two points in any of the above point set representations, you need platform dependant information about the coordinate orientation. This complicates matters similar to my initial attempt (using properties) by having to rely on platform dependant mapping every time you are referencing the rectangle data. Having a (point, size) notation, similar to the Cocoa representation, you remove the need for platform dependancy (except when mapping between the native type and the independant type). Also, this representation simplifies translation and scaling (see above). You do not need to worry about the direction of the size type since this is resolved for you by the operating system. Granted, gui::rect( 10, 15, 100, 150 ) will be orientated differently on Windows and Mac, but for the operating system user, they will be orientated correctly.
On naming... I think "area" is the wrong name.
I have revised the names for area (now rect with a typedef for rectangle if you prefer to use the longer name) and position (now point).
I see no benefit in using "position" instead of the usual "point". "Point" is shorter.
I was aiming at adding information to the name, for example move( point pt ); // move to the new point move( position pos ); // change the position I have conceeded the point (pun intended!) and changed the name. It may be a good idea to typedef point as position, like I do with rect.
It's hard to improve on "size" :-)
:)
I would seriously consider replacing float with a typedef, perhaps with another typedef for distances and offsets. Even without type checking, I think using more exact type names helps to clarify thought.
I am now using a UDT called metric (re: mathematics) to represent the values. See the other messages in the thread for discussions on this.
[Later...]
I've looked at the code in the zip file now. I see it doesn't match the email. It uses a different representation and adds several member functions, although not as many as me. I am surprised to see things like size*size and size/size.
On review, I have removed size/size, size*size. As for the representation change: this is an evolving library, but the essence remains the same, so discussion here is still valid. I do not intend on posting the full member function list as these e-mails are long enough already! If you are interested, take a look at the code (as you have done). I appreciate the feedback. Regards, Reece