dim a string to store up to 10 bytes only.

[James]

I'm reading a file that has a field that has a max length of 10.
I want to dim a string to store up to 10 bytes only. Is this possible?

Currently I have coded Dim strMyStr as String

Thanks in advance for any help.

[Rick Rothstein]

"James" <tbt102@hotmail.com> wrote in message
news:3dd92007$1@tnews.web.devx.com...
>
> I'm reading a file that has a field that has a max length of 10.
> I want to dim a string to store up to 10 bytes only. Is this
possible?

Dim MyString As String * 10

Rick - MVP


> Currently I have coded Dim strMyStr as String
>
> Thanks in advance for any help.

[Bob Butler]

"Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message
news:3dd92724$1@tnews.web.devx.com
> "James" <tbt102@hotmail.com> wrote in message
> news:3dd92007$1@tnews.web.devx.com...
>>
>> I'm reading a file that has a field that has a max length of 10.
>> I want to dim a string to store up to 10 bytes only. Is this
>> possible?
>
> Dim MyString As String * 10
>
> Rick - MVP

That's not really "up to 10 bytes", that's 10 bytes all the time. Shorter
strings will be padded, longer strings will be truncated. If the OP needs
"up to" literally then there is nothing in VB that will do that except maybe
using a textbox with MaxChars (if you don't mind a true kludge!)

[Phil Weber]

> That's not really "up to 10 bytes," that's 10 bytes
> all the time.

Bob/Rick: And it's not 10 bytes, it's 10 characters. ;-) 32-bit versions of
VB use Unicode internally, so a 10-character string occupies 20 bytes.
--
Phil Weber

[Rick Rothstein]

"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3dd9297b@tnews.web.devx.com...
> "Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message
> news:3dd92724$1@tnews.web.devx.com
> > "James" <tbt102@hotmail.com> wrote in message
> > news:3dd92007$1@tnews.web.devx.com...
> >>
> >> I'm reading a file that has a field that has a max length of 10.
> >> I want to dim a string to store up to 10 bytes only. Is this
> >> possible?
> >
> > Dim MyString As String * 10
> >
> > Rick - MVP
>
> That's not really "up to 10 bytes", that's 10 bytes all the time.
> Shorter strings will be padded, longer strings will be truncated.

Picky...picky...picky <g>


> If the OP needs "up to" literally then there is nothing in VB that
> will do that except maybe using a textbox with MaxChars (if you
> don't mind a true kludge!)

I never mind a good kludge <g>


Rick - MVP

[Rick Rothstein]

"Phil Weber" <pweber@nospam.fawcette.com> wrote in message
news:3dd92d6e@tnews.web.devx.com...
> > That's not really "up to 10 bytes," that's 10 bytes
> > all the time.
>
> Bob/Rick: And it's not 10 bytes, it's 10 characters. ;-) 32-bit
versions of
> VB use Unicode internally, so a 10-character string occupies 20 bytes.
> --
> Phil Weber

Technically, you're right... but I'd be willing to bet he meant
"characters" ;-)

Rick - MVP

[Bob Butler]

"Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message
news:3dd931eb$1@tnews.web.devx.com
> "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
> news:3dd92d6e@tnews.web.devx.com...
>>> That's not really "up to 10 bytes," that's 10 bytes > all the time.
>>
>> Bob/Rick: And it's not 10 bytes, it's 10 characters. ;-) 32-bit
>> versions of VB use Unicode internally, so a 10-character string
>> occupies 20 bytes. --
>> Phil Weber
>
> Technically, you're right... but I'd be willing to bet he meant
> "characters" ;-)

I know I was thinking characters but it's a good catch anyway. Always best
to be specific.

[Russ Holsclaw]

> I'm reading a file that has a field that has a max length of 10.
> I want to dim a string to store up to 10 bytes only. Is this possible?
>
> Currently I have coded Dim strMyStr as String
>
> Thanks in advance for any help.

You should know that a fixed-length string in VB is a very different animal
from a variable-length one, especially if it's part of a user-defined Type
(UDT) and you're doing Random or Binary file I/O. Most functions in VB that
take strings a parameters wind up converting fixed strings to variable ones.
Storing fixed strings in an array take up a lot less memory than
variable-length strings, however, and I would say that is probably the
greatest advantage to them, in addition to the fact that they are handled
differently in the Get and Put statements. (Read the Help for those,
carefully).

[Anthony Jones]

>>
Storing fixed strings in an array take up a lot less memory than
variable-length strings,
<<

Uh..how come?

[Phil Weber]

> Storing fixed strings in an array take up a lot less
> memory than variable-length strings...

Russell: Each variable-length string element stores a four-byte pointer to
the string data in the array, in addition to the data itself. Fixed-length
strings, on the other hand, store the data contiguously in the array; no
pointer is required. However, each element consumes the maximum string
length; variable-length strings use only the space actually required by the
data.

So, if your fixed-length strings have an average of four wasted bytes per
element, the memory consumed is roughly the same as that required by
variable-length strings. Worst case, variable-length strings consume four
additional bytes per element. Whether that qualifies as *a lot* depends, I
guess, on how many elements we're talking about. ;-)
--
Phil Weber

[Bob Butler]

"Phil Weber" <pweber@nospam.fawcette.com> wrote in message
news:3dda9993$1@tnews.web.devx.com
>> Storing fixed strings in an array take up a lot less > memory than
>> variable-length strings...
>
> Russell: Each variable-length string element stores a four-byte
> pointer to the string data in the array, in addition to the data
> itself. Fixed-length strings, on the other hand, store the data
> contiguously in the array; no pointer is required. However, each
> element consumes the maximum string length; variable-length strings
> use only the space actually required by the data.
>
> So, if your fixed-length strings have an average of four wasted bytes
> per element, the memory consumed is roughly the same as that required
> by variable-length strings. Worst case, variable-length strings
> consume four additional bytes per element. Whether that qualifies as
> *a lot* depends, I guess, on how many elements we're talking about. ;-

Do fixed-length strings have a 'current length' associated with them? If
not, then that's an additional 4 bytes per string for variable length.

[Joe \Nuke Me Xemu\ Foster]

"Phil Weber" <pweber@nospam.fawcette.com> wrote in message <news:3dda9993$1@tnews.web.devx.com>...

> > Storing fixed strings in an array take up a lot less
> > memory than variable-length strings...
>
> Russell: Each variable-length string element stores a four-byte pointer to
> the string data in the array, in addition to the data itself. Fixed-length
> strings, on the other hand, store the data contiguously in the array; no
> pointer is required. However, each element consumes the maximum string
> length; variable-length strings use only the space actually required by the
> data.
>
> So, if your fixed-length strings have an average of four wasted bytes per
> element, the memory consumed is roughly the same as that required by
> variable-length strings. Worst case, variable-length strings consume four
> additional bytes per element. Whether that qualifies as *a lot* depends, I
> guess, on how many elements we're talking about. ;-)

When I instantiated an array X(1 To 1024 * 1024&) As String * 16,
memory increased by around 32900KB. There appear to be no wasted
bytes, aside from the usual Unibloat. VB5 EE SP3 on NT4 WS SP6a.

--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Bob Butler" <butlerbob@earthlink.net> wrote in message <news:3ddac794@tnews.web.devx.com>...

> "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
> news:3dda9993$1@tnews.web.devx.com
> >> Storing fixed strings in an array take up a lot less > memory than
> >> variable-length strings...
> >
> > Russell: Each variable-length string element stores a four-byte
> > pointer to the string data in the array, in addition to the data
> > itself. Fixed-length strings, on the other hand, store the data
> > contiguously in the array; no pointer is required. However, each
> > element consumes the maximum string length; variable-length strings
> > use only the space actually required by the data.
> >
> > So, if your fixed-length strings have an average of four wasted bytes
> > per element, the memory consumed is roughly the same as that required
> > by variable-length strings. Worst case, variable-length strings
> > consume four additional bytes per element. Whether that qualifies as
> > *a lot* depends, I guess, on how many elements we're talking about. ;-
>
> Do fixed-length strings have a 'current length' associated with them? If
> not, then that's an additional 4 bytes per string for variable length.

No length, no Unibloat NUL at the end. Variable-length strings never
have less than six bytes of slop. There's probably a lot more, since
each one is allocated from a dynamic memory arena, with at least four
more bytes of overhead. (At the *bare* minimum, chunks just might be
two-byte-aligned, with 31 additional bits for the chunk size plus one
bit for the "available / in use" flag. *Nobody* actually does this.)

--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Russ Holsclaw]

> No length, no Unibloat NUL at the end. Variable-length strings never
> have less than six bytes of slop. There's probably a lot more, since
> each one is allocated from a dynamic memory arena, with at least four
> more bytes of overhead. (At the *bare* minimum, chunks just might be
> two-byte-aligned, with 31 additional bits for the chunk size plus one
> bit for the "available / in use" flag. *Nobody* actually does this.)

All that you say is right. All variable-length strings have a pointer (4
bytes) pointing to a data structure containing a string, a NULL character
for C-compatibility, and a length field at a negative offset. In addition,
as I understand it, there's some additional data to facilitate garbage
collection and re-packing of string space to control memory fragmentation.

And, frankly, I was also assuming that a fixed-length string usually has
pretty fixed-length content, such as a telephone number or a social-security
number. But the poster didn't say what the application was... just an
assumption on my part. He didn't say how he was reading it from the file,
and whether the file was an ASCII file requiring parsing, like a comma- or
tab-delimited file, or was a Random or Binary file where the format is
pre-determined and not subject to context-sensitive parsing.

I've done a great deal of work with binary files, but then I'm sort of a
bits-and-bytes kinda guy ... been coding since 1966. A lot of folks find
them all too confusing because they don't understand how data are stored
internally.

I'm amused by the comment in the Microsoft VB programmer's guide that
dismisses regular file I/O as being more "difficult" than using a relational
database. I guess that's in the eye of the beholder. DAO and ADO always
seemed like an awful lot of rigmarole to go through to access data. I
recognize the long-term value of using a database, of course, but never
considered it simpler than ordinary files, even binary ones.

--
Russ Holsclaw

[Joe \Nuke Me Xemu\ Foster]

"Russ Holsclaw" <russ@holsclaw.nyet> wrote in message <news:3ddbfd11$1@tnews.web.devx.com>...

> > No length, no Unibloat NUL at the end. Variable-length strings never
> > have less than six bytes of slop. There's probably a lot more, since
> > each one is allocated from a dynamic memory arena, with at least four
> > more bytes of overhead. (At the *bare* minimum, chunks just might be
> > two-byte-aligned, with 31 additional bits for the chunk size plus one
> > bit for the "available / in use" flag. *Nobody* actually does this.)
>
> All that you say is right. All variable-length strings have a pointer (4
> bytes) pointing to a data structure containing a string, a NULL character
> for C-compatibility, and a length field at a negative offset. In addition,
> as I understand it, there's some additional data to facilitate garbage
> collection and re-packing of string space to control memory fragmentation.

The StrPtr() points to the first character, while the length in bytes,
*not* including the "terminating" NUL, is tucked away at StrPtr() - 4.

> And, frankly, I was also assuming that a fixed-length string usually has
> pretty fixed-length content, such as a telephone number or a social-security
> number. But the poster didn't say what the application was... just an
> assumption on my part. He didn't say how he was reading it from the file,
> and whether the file was an ASCII file requiring parsing, like a comma- or
> tab-delimited file, or was a Random or Binary file where the format is
> pre-determined and not subject to context-sensitive parsing.

Once you're parsing, you're dealing with many variable-length strings
regardless.

> I've done a great deal of work with binary files, but then I'm sort of a
> bits-and-bytes kinda guy ... been coding since 1966. A lot of folks find
> them all too confusing because they don't understand how data are stored
> internally.

VB does toss in some additional wrinkles of its own.

> I'm amused by the comment in the Microsoft VB programmer's guide that
> dismisses regular file I/O as being more "difficult" than using a relational
> database. I guess that's in the eye of the beholder. DAO and ADO always
> seemed like an awful lot of rigmarole to go through to access data. I
> recognize the long-term value of using a database, of course, but never
> considered it simpler than ordinary files, even binary ones.

Attempts to "future-proof" binary file formats can get "interesting".
Having to read half the file (on average) just to find one particular
record also gets old really fast. DAO.Recordset.Seek is my friend.

--
Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!