× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Reading a block at a time may be faster reading, but you get into a REAL
headache with the snippet of the last line you have.

Say we have this data:
Line 1
Line 2
Line 3
Line 4
Line 5
and that each line is terminated with a single end of line char (ASCII has
2, but to make it simpler).  And say we are reading a 15 byte buffer (I
didn't feel like typing to fill a 500 byte buffer <g>).
Your first read would produce:
"Line 1<EOL>Line 2<EOL>L"
and the second read would produce:
"ine 5"
Now you have to come up with some scheme to take the snippet of the last
line, the "L" and add it to the beginning of the block you read.  And since
you only set aside 500 byte for your reads, you'll have to increase your
buffer to 1000 just to be safe, but what if one line is actually 1001 chars
long?  And... It's just a pain in the neck, been there, done that, got the
headache.

Much easier just to read a byte at a time and build your string.  It may be
slower reading, but the code is MUCH easier to maintain and much less prone
to strange bugs.

Regards,

Jim Langston

-----Original Message-----
From: dmosley@dancik.com [mailto:dmosley@dancik.com]

Sounds a bit time consuming.  If you can read one character at a time, can
you specify to pull in a block at a time.  Kind of like, %subst(IFSFILE:
501: 500)

David L. Mosley, Jr.
Systems Analyst
2000 CentreGreen Way
Suite 250
Cary, NC 27513


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.