Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Why not choose both?</p> <p>Really, the only thing that matters is the interface between your library and its internals. Or, how your users will <strong>use</strong> the library. You can store the information for a rectangle however you'd like, but that should be encapsulated far, far away from the user so that they don't need to worry about how their rectangle is stored, just that it is indeed a rectangle.</p> <p>In other words on choosing both, if you're writing object oriented code, you can store the rectangle however you want, and then let your user create a rectangle using either method.</p> <p>For example, your declaration might look something like this:</p> <pre><code>class Rectangle { public: Rectangle(Point p1, Point p2); Rectangle(Point origin, int width, int height); ... }; </code></pre> <p>(C++, since you tagged that)</p> <p>Where Point is some class:</p> <pre><code>class Point { public: Point(int x, int y) : mX(x), mY(y) {} private: int mX; int mY; }; </code></pre> <p>This way, your library isn't limited to only supporting one type of specification for creating a rectangle.</p> <p>As far as implementation specifically, it really doesn't matter. They both work and can easily be converted to one another and use the same amount of memory, and therefore there will be no major performance implications of using one over the other. </p> <p>For simple ease of development, consider what the use cases of your rectangle are. Take a look at each member function you'll need to write for that class and think about which format will make it easier to write those functions.</p> <p>If it were me I'd probably implement it with the two points.</p> <p><strong>Edit: An academic approach to why I think implementing it either way will make absolutely no difference in most cases.</strong></p> <p>Let there be a member function or an operation on our Rectangle class that does work on our rectangle or makes some calculation. Assume one method of implementation (width/height/origin or two points) will do this operation significantly faster than the other implementation.</p> <p>We can convert from implementation width/height/origin with the following:</p> <pre><code>// assuming x0,y0 is top left and x1,y1 is bottom right x0 = originX; y0 = originY; x1 = originX + width; y1 = originY + height; </code></pre> <p>And we can convert from implementation two points with the following:</p> <pre><code>// assuming x0,y0 is top left and x1,y1 is bottom right originX = x0; originY = y0; width = x1 - x0; height = y1 - y0; </code></pre> <p>Therefore, the implementation which performs this operation much slower/worse than the other implementation can be converted to the other implementation in O(1) running time, so that other implementation cannot be <em>that</em> much better than the first implementation. </p> <p>Unless you're doing this operation several thousand times a second or on an extremely performance-limited device, I'm very convinced that there will be no performance difference. There is already no memory difference because both implementations pretty much just store 4 floats/ints.</p> <p>This pretty much leaves convenience of coding, and like I said above in my original post, you can simply "consider what the use cases of your rectangle are. Take a look at each member function you'll need to write for that class and think about which format will make it easier to write those functions."</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload