>So I take it that the ultimate problem is that the job as currently constituted is too slow? Or is it that is is 'fast enough' (for the procedures surrounding it) but someone says it can be faster?
>
>IF it is the latter, let the person do so would be my opinion. I don't doubt that it could well be faster with C++ though I suppose it could take a highly skilled one to make it so.
It is indeed the latter.
>This would be an interesting and informative exercise. The development time could be tracked, then the speed difference (between your original and the C++ one) measured and some conclusions drawn.
Well, I'm sure that my customer is satisfied (very satisfied) with the current performance. And he certainly will not spend money on such an experiment. :)
This 'investigation' should suffice for now. Specifically, will ... be outperformed by the C++ equivalents:
FGETS()
FPUTS()
CHRTRAN()
STRTRAN()
LEFT()
PADL()
IF
Groet,
Peter de Valença
Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
