<ArarghMail804NOSPAM@[EMAIL PROTECTED]
> wrote:
> "Judson McClendon" <judmc@[EMAIL PROTECTED]
> wrote:
>
> <snip>
>>There is a reason those routines were not do***ented. Any time you use
> Such as?
You don't them - that's the point. Good programming is about
knowing exactly what and how. When you're guessing, you are
breaking reliability. :-)
>>undo***ented features of a compiler you are begging for unreliability
>>and obsolescence. If you're writing programs for fun, have at it. :-)
>>But when you write code, as I do, for clients who want reliability and
>>longevity, using such features, especially when it's only to gain some
>>trivial, likely only perceived, advantage, is not good business. :-)
>
> I would guess that the reason they were do***ented at that time (PDS7)
> was for sup****t of far strings. The layout of a string descriptor
> changed, and it was no longer possible to get the address & length of
> a string from it.
>
> It would have been much better if MS had provided & do***ented those
> STRING* routines from the very beginning. It would have eliminated
> all the guessing as to string descriptor layouts or having to use the
> more bulky SADD method. Also, being able to use the STRING* calls
> from within called routines would have solved much of the worry of the
> string pool being compacted before the string got used.
>
> Also, my library of routines for use with Basic works with all
> versions of QuickBasic from 4.5 to VBDOS 1.0. It would probably work
> as is with QuickBasic 4.0 & 4.1 as their runtime libs look very
> similar to 4.5. And, it would probably work with versions of
> QuickBasic prior to 4.0, but since it was never needed, it was never
> tested.
Yes, but those are old, never to be enhanced tools. In a normal
development environment programmers are using tools that are
being updated periodically. Using undo***ented features simply
opens yourself and your applications to potential unforeseen bugs
and other complications. If you were having brain or open heart
surgery, would you want your doctor to be guessing about how
his tools and instruments work? I think not. As I said, when it's
for fun, more power to you. But if it's for money and im****tant,
using such techniques is (I'm sorry) simply foolish. You never
*have to* use such techniques; there are always other ways. :-)
In addition, one of the prime requisites of "good code" is that it
be as easy to read and understand as possible, so maintenance
is easier and more reliable. Techniques such as this are directly
the opposite. Only very rarely is machine efficiency worth the
cost of obfuscating clear, easily maintainable code with code
that is not understood because it uses undo***ented features.
Never is gaining efficiency worth losing reliability. :-)
--
Judson McClendon judmc@[EMAIL PROTECTED]
(remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
|
