[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: func_arith and func_len
From: |
Ralf Wildenhues |
Subject: |
Re: func_arith and func_len |
Date: |
Sun, 20 Apr 2008 03:06:26 +0200 |
User-agent: |
Mutt/1.5.17+20080114 (2008-01-14) |
* Bob Friesenhahn wrote on Sun, Apr 20, 2008 at 02:42:00AM CEST:
> On Sun, 20 Apr 2008, Ralf Wildenhues wrote:
>>
>> Sorry, but: first, there is no floating point in either Libtool, nor
>> Posix shell semantics. Second, if you can prove to me (by posting
>> timing comparisons) that conversion from integer to string or vice
>> versa, has *any* performance impact whatsoever on Libtool, I'll gladly
>> send lots of beer your way. I mean hey, we still fork quite a bit, and
>
> While for our purposes it is indeed unlikely that we can measure the
> difference, it seems that the code should use the most "correct"
> implementation if using it requires minimal effort.
There is no "more" or "less" correct in this case.
> If all shells
> supporting this math syntax also support the native math types (which
> they likely do since this syntax comes from old ksh), then is there a
> reason why we would not prefer the "native" syntax for math if we are
> doing math? Is there a ripple effect?
Yes. The factoring into a shell function which supports Posix syntax
and a shell function which does the same but using expr is a lot simpler.
Apart from all this reasoning, I doubt that the shell *has* to convert
integers with (($x)); it looks like that would be a quality of
implementation issue.
Of course, Libtool doesn't used typed variables at all, they are not
Posix, and I guess factorizing that for ksh especially is not worth
the effort. But hey, try it out and prove me wrong with your timings.
Cheers,
Ralf