[fpc-devel] Re: fpc-devel Digest, Vol 40, Issue 16

[L]

> Functions like strtoint however have raise calls.

> > Yes, but there already exists a raise-less version of strtoint, called
> > "val". So, there is IMO absolutely no need for an exceptionless version of
> > strtoint in another unit.

Of course we can use our own functions that emulate what is in the sysutils
unit.. but if they aren't drop in replacements this means that code is broken
and now we have to add Val calls and Str calls instead of just using a drop in
replacement.

The str() and val() functions I use occasionally, and I know turbopascal
programmers had to use them.. but they are not drop in replacements. One of the
goals of compactsysutils was to be a drop in replacement.  It is nice to be able
to immediately convert a string to integer instead of using var params or OUT
params. There is a way to build a StrToInt that still reports errors.. it
returns a zero on error.

In KOL, Kladov also returns a zero with his Str2Int function if string is bad.
You may be thinking.. but what if the string really is a zero and we want to
know that it is?
Well then we can do this:
if (s = '0') or (StrToInt(s) <> 0) then  writeln('S is an integer');
if StrToInt('SomeString') = 0 then  writeln('s is not an integer');

Since the strtoint function is just a simple val call, we can maintain
two copies if it. It's robust bone simple function that needs zero maintenance.
So having two copies isn't an issue with it...

With other functions that use raise calls that are more complex.. then
we worry more about the double maintenance for sure..

StrToInt may not fit in fsutils.pp  since fsutils is for file
system functions though?

So we'd have to make another unit. IntUtils.pp ...
and another one for CompareText/Wraptext().. TxtUtils.pp

Or, instead of fsutils.pp we could have tinyutils.pp which didn't just have
filesystem
functions, but others such as CompareText, WrapText, ExtractFilePath, StrToInt,
etc.

I think the more units we add the more bytes we lose (not sure how many,
but a namespace requires something.. premature optimization?
Yes.. but still).


> What does a raise call rely on? I can play and find out, but maybe you know
> off
> hand.

> > Afaik it is a statement, therefore handled by the compiler.

Sorry I meant.. how do you make an exception without using sysutils.. because we
could use the raise statement for functions that have raise calls like
wraptext/comparetext/strtoint.

I looked at kol.pas and err.pas to see how exceptions work without sysutils.
That was just another idea for the strtoint function so that we wouldn't have to
remove the raise call in intutils.pp or tinyutils.pp. But the returning zero
option would remove need for raise altogether.

Just clear things up for other readers.. I'm not proposing we change any code in
sysutils.. sysutils will remain delphi compatible.. so when I say remove raise
call from strtoint.. I mean remove it in a duplicate funciton, not the original.
Michael was worried about breaking delphi compat but this can't happen if we
just make fsutils.wrapper() calls within sysutils original unit. Then in
tinyutils.pp we make wrapper calls to intutils.pp and fsutils.pp so that
tinyutils.pp doesn't use any of sysutils at all.
So the sysutils interface stays the same.. it is illegal to break the sysutils
contract.