Re: How do i convert text string to hex values as string?



Dr. Stockton,

[greatly snipped]

"Dr John Stockton" <jrs@xxxxxxxxxxxxxxxxxx> wrote in message
news:bT5KIwCBH6jCFwpM@xxxxxxxxxxxxxxxxxxxxx
....
>>If the solution to which you refer is
>>
>>sVAL = sVAL & ltrim(" " & right("0" & Hex(...), 2))
>>
>>it was a standard technique even back in DOS BASIC days.
....
> Right("0"&D, 2) is traditional for making a number 0..99 into 00..99.
> But IIRC
> Right(100+D, 2) is faster, because addition is faster than concatenation
> and otherwise it needs the same operations.
> So Right(Hex(256+D), 2) should do it for Hex.
....

Addition is a great alternative, and I use it myself at times, simply
because of its compelling logic. But I have to question whether "because
addition is faster than concatenation" is a valid justification for the use
of one technique over the other. I bring it up, not just in response to
your statement, but because I see this concern raised as justification in
many programming books and posts, and it falls into a "pet peeve" category.

When I programmed with MASM back in DOS days, where computers could be
extremely slow and memory was at a premium, the number of ticks for each
instruction had to be added up, and the total number of ticks for each
isolated procedure was a terribly significant consideration.

Even in those days, however, I cross-compiled MASM libraries with compiled
QuickBASIC libraries, because QuickBASIC had by far the best string handling
techniques of any language then in general use (even though the compiled
libraries were somewhat bloated and slow, a fact that had to be reconciled
with the overall program). Cross-compiling MASM and QuickBASIC was not
uncommon (I certainly didn't invent it), and, in those days, it had some
significant advantages (if done correctly) over writing entirely in a
middle-level language, such as C.

VBS is such a high-level language that I'm not at all sure what is quicker
for most operators or inherent functions. I could run a loop of 100,000 or
so and see, but I really don't want to spend the time doing that. Much less
do I know precisely how VBS, a purely variant language, handles transitory
data space assignments in its data heap (or heaps ?), which is likely the
real key to the concatenation versus addition issue that you raise.

More in point, however, VBS is a utility script designed for relatively
short sequences of code. The point of its use for most scripters is to
write a properly operating code sequence relatively quickly, and to allow
the resulting script to be put into service and read easily without
excessive comment, for correction or later modification. The speed and
memory capabilities of modern computers cover a host of what *used* to be
coding *evils*.

The beauty of a BASIC language (not unlike the English language) is its
ambiguity. It gives one many different ways to do the same thing (unlike
some other very high-level languages), without an obvious reason to choose
one over the other (which one finds in lower-level languages). I suggest
that the scripter's orientation to, or "conception" of, VBS -- that which
helps him or her to write sufficient code and get it into service as quickly
as possible, is probably the primary governing concern, with conceptional
integrity and ease of reading being the primary secondary concern.

My background leads me to view VBS primarily as a string-handler (BASIC was
never strong in number-crunching), and I write many more string routines
than does someone coming to the language from a numeric-oriented language,
such as C. For example, I often use string keyword arguments instead of
bitcode arguments or a series of Boolean flag arguments, because they read
better without comment or the tedious setting of constants (which I avoid),
even though they are obviously somewhat slower, since they have to be
coerced, string-compared and processed into flags. And I invariably call
procedures by name, instead of pointers.

>From posts here, it is clear that many scripters cannot conceive of VBS
outside of an ASM or HTML host. One sees many calls to COM objects for
results which could be done necessarily faster and with less memory usage by
a few lines of inherent script. The point is that a scripter produces a
satisfactory code and gets it into service faster, when working within his
or her cohesive framework or concept of the language.

I can't believe that the issue of single- or few-character concatenation
versus addition can make a significant difference in a *script*, even a
recursive script, when compared to the considerations of operating within
the scripter's conceptual preference and the clarity in reading the
resulting script.

Don't get me wrong, I appreciate the importance of education and
demonstration of other approaches and viewpoints for getting the job done,
as well as the observation that one method may be quicker or otherwise more
efficient than another (in many cases the difference is obvious and far more
dramatic). And since one tends to post responses from one's own viewpoint,
giving an OP a selection always helps to produce an option that suits his or
her preferences.

But I cannot accept that "because addition is faster than concatenation" is
a valid justification for preferring addition of an otherwise curious ("why
am I doing this?") numeric value, prior to string operations, over
single-character concatenation of the very character that one wants in the
end result. Single-dimension efficiency is not a sole compelling
consideration.

Regards,
Joe Earnest


.



Relevant Pages

  • Re: syntax...
    ... B&D on the part of the language designer. ... probably handle concatenation of string literals by itself, ... bitwise XOR, or if not that, then exponentiation.) ...
    (comp.lang.misc)
  • Re: syntax...
    ... parser to allow a little more freedom, nicer style, ... ... B&D on the part of the language designer. ... probably handle concatenation of string literals by itself, ...
    (comp.lang.misc)
  • Re: Simple regex problem has me baffled
    ... I am writing a script to analyse a log file. ... Each pair of Request and Response calls have a unique ... Use of uninitialized value in concatenation or string at ./magic.pl ...
    (perl.beginners)
  • RE: Simple regex problem has me baffled
    ... I am writing a script to analyse a log file. ... Each pair of Request and Response calls have a unique ... Use of uninitialized value in concatenation or string at ...
    (perl.beginners)
  • Re: Newbie question re initialization
    ... When I submit my script for testing I receive the following warnings: ... Use of uninitialized value in concatenation or string at foo.pl line 19. ... Why is $username undef then? ...
    (comp.lang.perl.misc)

Loading