[interfacekit] Re: [Fwd: Message submitted to 'interfacekit']

> Yes, having similar functions bottleneck through a single function is
> really the best way for maintainability and correctness.

I agree on that. Nevertheless it doesn't answer the question. Both the 
current R5 and the proposed implementation bottleneck through one 
function.

> If we are -really- concerned about performance, we can inline the
> 'stubby' functions in the header.

We should be very careful with inlining functions. Unless the 
functions's tasks are trival (as BString::Length()/String() are for 
example), the function call overhead to function execution ratio should 
be insignificantly small. And inlining may introduce serious binary 
compatibility traps.


> On Thu, Oct 10, 2002 at 07:31:04PM +0200, Jack Burton wrote:
>   >
>   > Hi all.
>   > I hope you all won't be upset by another question :)
>   > I'm approaching the completion of BString (some methods are well 
> > tested,
>   > other aren't, and a pair aren't implemented, but it will be in 
> > short
> time),=
>   >
>   > and I was wondering.... Often I have some function which are 
> > similar,
> for
>   > example:
>   >
>   > 1. Prepend(const char *string)
>   >
>   > and
>   >
>   > 2. Prepend(const BString &string).
>   >
>   > These functions call a private utility function (_DoPrepend),
>   > but I am thinking if it would be better for the (2) to just call 
> > the
> first
>   > (i.e.
>   >
>   > Prepend(const BString &string)
>   > {
>   > =09Prepend(string.String());
>   > }
>   >
>   > Yes, this mean a little performance loss, but it would have the
> undubious
>   > vantage that there would be less code =3D=3D less bugs.

I don't see why there would be less code. I would say, it's the same 
(maybe one line difference depending on were the strlen() is used)... 
unless you count the mere existence of a function real code.

Regarding the performance loss: BString is a high-performance class. It 
trades space (the length field in _privateData) for performance. I 
would say, however you implement it now, the final code should take 
advantage of this length field.

Regarding Erik's `premature optimization is the root of all evil': I 
couldn't agree more. But in this case it's only about calling strlen() 
inside the worker function or supplying the length as a parameter, 
allowing the `optimization' to use Length() instead of strlen() for the 
BString parameter. Anyway, in my opinion this optimization should 
definitely be used in the production code.

>   > Anyway, this is just an example, and I would be glad if someone 
> > took a
>   > moment and threw a look to our BString implementation, to 
> > understand
>   > what I= am saying.

I would argue similarly for the other methods. The R1 release code 
should use the optimizations. BTW, for two Append() versions and `+=' 
you don't even have a choice, as they are implemented inline.

CU, Ingo

Other related posts: