$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-15 04:33:27
John Torjo wrote:
>>The first thing that comes to mind when reading "data that is associated
>>with the component" is data binding. I think it is a mistake to build
>
>What do you mean by this? Could you give an example?
I gave examples in my explanation. Let's say you have a textbox component.
To bind it to generic data, you would need something like:
template< typename Data > class gui::textbox;
This would allow:
gui::textbox< std::string > name;
gui::textbox< long > age;
But: How do you convert the string data into a long? I suppose you could
have a conversion parameter, so you would do:
gui::textbox< long, lexical_converter< long > > age;
However, because textbox is now a template, you get potential code bloat,
especially if you are templating a more complex component such as a table
(where in windows this is a "virtual" ListView control in report mode). I
want to stear away from using templates as much as possible, using them
where necessary, and keep the design as simple as it can be.
>>With this in mind, I have taken a drastic approach: do not provide native
>>interoperability for size, position and area. I have designed them as:
>>
>> struct position{ float x; float y; };
>> struct size{ float dx; float dy; };
>> struct area
>> {
>> float top; float left;
>> float width; float height;
>> };
>>
>>This means that the interface must convert these to the native
>>representations and vise versa.
>
>I would say that this is the correct approach.
>
>As a side-node, I'm moderately against having float coordinates. Why would
>you think int is not enough?
>From the various discussions, it is down to precision in caclculation.
Usually, this would be when rounding floating values to integer boundaries.
For example:
x = 2.6 + 5.6 = 8.2
as an integer expression, is this:
x = 2 + 5 = 7; // using floor(val)
x = 3 + 6 = 9; // using ceil(val) or round(val)
In this case, the integer expressions are out by 1 depending on what
rounding scheme is used. I took actual values to show the case above. If
these were values in an algorithm that performed anti-aliasing for example,
the anti-aliasing would not calculate the correct values.
Note that for integer-based coordinate systems, the values are converted to
integers when needed, but otherwise are left as floating values to retain
precision.
Regards,
Reece