Ascii to DWORD replacement

[frktons]

I think the check of input values has to be done before calling the conversion
routine. No need to duplicate them.

[dedndave]

Yeah, but which string, unsigned, signed, floating point, various scientific notation etc etc ....
Are you going to fill a conversion with every possible case of data error that can be fed to it ?

i think Jochen has a nice routine like that   :t
it would be a nice addition to the masm32 library

[hutch--]

 

> i think Jochen has a nice routine like that it would be a nice addition to the masm32 library

No, its a nice addition to MasmBasic, that is what JJ wrote it for. A library for MASM needs much finer granularity to avoid duplication and redundancy, the difference is the conceptual difference between a high level language and a low level language, small isolated procedures built as separate object modules that can be combined in very flexible ways to produce a wide range of functionality.

[jj2007]

> i think Jochen has a nice routine like that it would be a nice addition to the masm32 library

No, its a nice addition to MasmBasic, that is what JJ wrote it for. A library for MASM needs much finer granularity to avoid duplication and redundancy, ...

Mixing Masm32 and MasmBasic is perhaps not a good idea, I agree. Val(My$) (and MovVal) are "all you can eat" macros that emulate the behaviour of the corresponding HLL (in this case, GfaBasic).

There is an issue with the design logic, however.

First, we tend to say "it's better to have a high-speed specialised algo than a slow allrounder". Right, but MasmBasic's Val/MovVal, while able to "eat" decimal, bin and two hex formats, and correctly handling whitespace, is five times as fast as the current atodw... Now that will change with the superfast new Masm32 atodw, fine.

Second, "I want to be sure the algo does only what I want it to do". I.e. atodw should not convert "-123" if the documentation says "unsigned decimal" (and one can argue whether writing "DWORD" is sufficient). However, if you feed "-123" to atodw, then the algo should complain, otherwise that "design advantage" is nil.

Last but not least, I still believe that even the experienced programmer who starts with Masm32 needs a very explicit warning that atodw, if fed with " 123 ", produces rubbish. Not knowing that behaviour produces the kind of bug that makes us spend sleepless nights, and it would be easy to avoid it.

[MichaelW]

I think the check of input values has to be done before calling the conversion routine. No need to duplicate them.

I agree. A separate general-purpose "filter" implemented as a procedure, or better, as a macro that generates procedures that are specific to the filtering requirements (IOW that have one argument, the address of the string, and where the specific "filter" is hard coded).