> Therefore, an exceptionless "strtoint" is not a drop in replacement, you = > > need to recode your error handling. If you do so you can just as well = > > replace it by val.
If you first start off using compactsysutils, the error checking will still work if you upgrade to using sysutils. Therefore it is more compatible. When you upgrade to the real sysutils after you decide your application has grown to be such bloatware that it won't matter.. then at least now your inttostr will work with sysutils and compactsysutils.. plus you will have two error checks.. the exception and the manual verification. Furthermore, if you forget the try/except, at leas you will have real logic checking. I rarely see people use try/except around strtoint in delphi code (maybe just sloppy programmers). However, that being said.. I think checking for if "s<>'0'" is kind of a cludge.. but so is checking using ugly val with Var params either way. Val is more obvious to the programmer and would be recommended for airplane/rocket ship programming where it is critical errors are within the contract. Actually, that is something I brought up in an article recently about error contracts being forced by the compiler using Tuple's as function resutls, but anyway that's off topic. Floats, however would be much harder to check for.. 0.00 0.000 etc. and maybe a parser would have to be added to check the float first for valid input. But if we do not agree to make the StrToInt functions part of fsutils or tinyutils or intutils or convutils then I'm fine with this.. we can just tell people to use Val. At least we have all the other functions to put into fsutils/txtutils such as CompareText, WrapText, ExtractFilePath, and lots of others. i.e. strtoint isn't a show stopper either way. Also some from the StrUtils? Since strutils puts sysutils in uses. Maybe we make one called txtutils or textutils.pp for things like comparetext/wraptext/strutils ones? Or just tinyutils.pp with tons of functions all in one namespace? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
