News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Ascii to DWORD replacement

Started by hutch--, January 25, 2013, 01:58:28 PM

Previous topic - Next topic

frktons

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

There are only two days a year when you can't do anything: one is called yesterday, the other is called tomorrow, so today is the right day to love, believe, do and, above all, live.

Dalai Lama

dedndave

Quote from: hutch-- on January 30, 2013, 09:57:50 AM
:biggrin:

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--

 :biggrin:

> 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

Quote from: hutch-- on January 30, 2013, 12:32:33 PM
:biggrin:

> 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

Quote from: frktons on January 30, 2013, 10:19:14 AM
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).
Well Microsoft, here's another nice mess you've gotten us into.