On 12.07.2011, at 11:57, Edzard Egberts wrote:
> MacArthur, Ian (SELEX GALILEO, UK) schrieb:
>> But, I think this is premature optimisation at this stage: first, we
>> should build it with the hooks in place, and then see how much it
>> *really* costs us. Modern compilers may be able to elide the hooks a lot
>> of the time, I think, so the impact may be less than people fear.
>>
>> If it transpires that we are taking a hit, *then* we implement the
>> FLTK3_LEAN_AND_MEAN option.
>>
>> How does that sound?
>
> I don't worry about costs of runtime, but about complexity of code.
> Don't you think, this will bloat developers problems a lot? I did such
> things myself, but I learned, after keeping it simple it's often a good
> idea, to make it more simple. Is this complexity really useful enough
This is the original FLTK 1 code:
void fltk3::Button::draw() {
FLTK3_OBJECT_VCALLS_WRAPPER(draw(), Draw)
if (type() == fltk3::HIDDEN_BUTTON) return;
fltk3::Color col = value() ? selection_color() : color();
This is the code in FLTK 3, wrapper included:
void fltk3::Button::draw() {
FLTK3_OBJECT_VCALLS_WRAPPER(draw(), Draw)
if (type() == fltk3::HIDDEN_BUTTON) return;
fltk3::Color col = value() ? selection_color() : color();
Yes, you can't see what's going on inside that macro, but being a macro, we can
easily define it as empty and have zero overhead via a compile time option, and
for FLTK 3 purposes, I guarantee that this macro is completely transparent. But
also see the remark in my previous mail... .
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
