dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 4 123 ... LastLast
Results 1 to 15 of 49

Thread: Hardcore String Mid$'ing

  1. #1
    Chris Lucas Guest

    Hardcore String Mid$'ing


    Greetings all. I'm looking into alternative methods of grabbing the Mid$()
    of a string. Specifically I want to use CopyMemory to modify the pointers
    of elements of a string array so that they each point to different portions
    of the same string, then use CopyMemory to make each element a certain length.
    I can shift the string pointers easily enough, and specify the appropriate
    length, but the results come back garbled. I'm thinking that this has to
    do with the way string arrays are stored in memory. Below is the string
    I'm working with, and the output I get, any help here is appreciated. BTW
    I'm really using PeekLng/PokeLng for those of you familiar with those specialized
    declarations of "RLTMoveMemory".

    My string to tokenize is: "First Second Third"
    After 6 calls to CopyMemory my string elements are:
    element(0) = "Fi "
    element(1) = "Se "
    element(2) = "Th "

    What gives, they point to the right place (obviously) and read the right
    length, but those other bytes aren't where they are supposed to be. Thanks.

    Chris

  2. #2
    Rob Teixeira Guest

    Re: Hardcore String Mid$'ing



    I hate to break the bad news to you, but this is definitely not recommended.
    The first big barrier is that strings aren't immutable.
    The next issue you have to deal with is that a BSTR is a pointer to pointer
    to an array of wide (16-bit unicode) characters. The two bytes preceding
    the pointer are the number of characters. However, in order to be a valid
    string, it *also* needs to be null terminated. You won't be able to accomplish
    that part. A BSTR (or more appropriately, an OLECHAR) only guarantees what
    the data is supposed to look like, not how an operation works with the string,
    and certain operations will look for the null terminator.

    -Rob

    "Chris Lucas" <cdl1051@earthlink.net> wrote:
    >
    >Greetings all. I'm looking into alternative methods of grabbing the Mid$()
    >of a string. Specifically I want to use CopyMemory to modify the pointers
    >of elements of a string array so that they each point to different portions
    >of the same string, then use CopyMemory to make each element a certain length.
    > I can shift the string pointers easily enough, and specify the appropriate
    >length, but the results come back garbled. I'm thinking that this has to
    >do with the way string arrays are stored in memory. Below is the string
    >I'm working with, and the output I get, any help here is appreciated. BTW
    >I'm really using PeekLng/PokeLng for those of you familiar with those specialized
    >declarations of "RLTMoveMemory".
    >
    >My string to tokenize is: "First Second Third"
    >After 6 calls to CopyMemory my string elements are:
    > element(0) = "Fi "
    > element(1) = "Se "
    > element(2) = "Th "
    >
    >What gives, they point to the right place (obviously) and read the right
    >length, but those other bytes aren't where they are supposed to be. Thanks.
    >
    >Chris



  3. #3
    Rob Teixeira Guest

    Re: Hardcore String Mid$'ing



    I hate to break the bad news to you, but this is definitely not recommended.
    The first big barrier is that strings aren't immutable.
    The next issue you have to deal with is that a BSTR is a pointer to pointer
    to an array of wide (16-bit unicode) characters. The two bytes preceding
    the pointer are the number of characters. However, in order to be a valid
    string, it *also* needs to be null terminated. You won't be able to accomplish
    that part. A BSTR (or more appropriately, an OLECHAR) only guarantees what
    the data is supposed to look like, not how an operation works with the string,
    and certain operations will look for the null terminator.

    -Rob

    "Chris Lucas" <cdl1051@earthlink.net> wrote:
    >
    >Greetings all. I'm looking into alternative methods of grabbing the Mid$()
    >of a string. Specifically I want to use CopyMemory to modify the pointers
    >of elements of a string array so that they each point to different portions
    >of the same string, then use CopyMemory to make each element a certain length.
    > I can shift the string pointers easily enough, and specify the appropriate
    >length, but the results come back garbled. I'm thinking that this has to
    >do with the way string arrays are stored in memory. Below is the string
    >I'm working with, and the output I get, any help here is appreciated. BTW
    >I'm really using PeekLng/PokeLng for those of you familiar with those specialized
    >declarations of "RLTMoveMemory".
    >
    >My string to tokenize is: "First Second Third"
    >After 6 calls to CopyMemory my string elements are:
    > element(0) = "Fi "
    > element(1) = "Se "
    > element(2) = "Th "
    >
    >What gives, they point to the right place (obviously) and read the right
    >length, but those other bytes aren't where they are supposed to be. Thanks.
    >
    >Chris



  4. #4
    Karl E. Peterson Guest

    Re: Hardcore String Mid$'ing

    Hi Rob --

    > it *also* needs to be null terminated. You won't be able to accomplish


    Curious statement. Why?

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]



    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3c14f149$1@147.208.176.211...
    >
    >
    > I hate to break the bad news to you, but this is definitely not recommended.
    > The first big barrier is that strings aren't immutable.
    > The next issue you have to deal with is that a BSTR is a pointer to pointer
    > to an array of wide (16-bit unicode) characters. The two bytes preceding
    > the pointer are the number of characters. However, in order to be a valid
    > string, it *also* needs to be null terminated. You won't be able to accomplish
    > that part. A BSTR (or more appropriately, an OLECHAR) only guarantees what
    > the data is supposed to look like, not how an operation works with the string,
    > and certain operations will look for the null terminator.
    >
    > -Rob
    >
    > "Chris Lucas" <cdl1051@earthlink.net> wrote:
    > >
    > >Greetings all. I'm looking into alternative methods of grabbing the Mid$()
    > >of a string. Specifically I want to use CopyMemory to modify the pointers
    > >of elements of a string array so that they each point to different portions
    > >of the same string, then use CopyMemory to make each element a certain length.
    > > I can shift the string pointers easily enough, and specify the appropriate
    > >length, but the results come back garbled. I'm thinking that this has to
    > >do with the way string arrays are stored in memory. Below is the string
    > >I'm working with, and the output I get, any help here is appreciated. BTW
    > >I'm really using PeekLng/PokeLng for those of you familiar with those specialized
    > >declarations of "RLTMoveMemory".
    > >
    > >My string to tokenize is: "First Second Third"
    > >After 6 calls to CopyMemory my string elements are:
    > > element(0) = "Fi "
    > > element(1) = "Se "
    > > element(2) = "Th "
    > >
    > >What gives, they point to the right place (obviously) and read the right
    > >length, but those other bytes aren't where they are supposed to be. Thanks.
    > >
    > >Chris

    >



  5. #5
    Karl E. Peterson Guest

    Re: Hardcore String Mid$'ing

    Hi Rob --

    > it *also* needs to be null terminated. You won't be able to accomplish


    Curious statement. Why?

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]



    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3c14f149$1@147.208.176.211...
    >
    >
    > I hate to break the bad news to you, but this is definitely not recommended.
    > The first big barrier is that strings aren't immutable.
    > The next issue you have to deal with is that a BSTR is a pointer to pointer
    > to an array of wide (16-bit unicode) characters. The two bytes preceding
    > the pointer are the number of characters. However, in order to be a valid
    > string, it *also* needs to be null terminated. You won't be able to accomplish
    > that part. A BSTR (or more appropriately, an OLECHAR) only guarantees what
    > the data is supposed to look like, not how an operation works with the string,
    > and certain operations will look for the null terminator.
    >
    > -Rob
    >
    > "Chris Lucas" <cdl1051@earthlink.net> wrote:
    > >
    > >Greetings all. I'm looking into alternative methods of grabbing the Mid$()
    > >of a string. Specifically I want to use CopyMemory to modify the pointers
    > >of elements of a string array so that they each point to different portions
    > >of the same string, then use CopyMemory to make each element a certain length.
    > > I can shift the string pointers easily enough, and specify the appropriate
    > >length, but the results come back garbled. I'm thinking that this has to
    > >do with the way string arrays are stored in memory. Below is the string
    > >I'm working with, and the output I get, any help here is appreciated. BTW
    > >I'm really using PeekLng/PokeLng for those of you familiar with those specialized
    > >declarations of "RLTMoveMemory".
    > >
    > >My string to tokenize is: "First Second Third"
    > >After 6 calls to CopyMemory my string elements are:
    > > element(0) = "Fi "
    > > element(1) = "Se "
    > > element(2) = "Th "
    > >
    > >What gives, they point to the right place (obviously) and read the right
    > >length, but those other bytes aren't where they are supposed to be. Thanks.
    > >
    > >Chris

    >



  6. #6
    Michael \(michka\) Kaplan Guest

    Re: Hardcore String Mid$'ing

    Why does it need to be? Or why can he not accomplish it?


    --
    MichKa

    Michael Kaplan
    (principal developer of the MSLU)
    Trigeminal Software, Inc. -- http://www.trigeminal.com/
    the book -- http://www.i18nWithVB.com/

    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3c153bb8@147.208.176.211...
    > Hi Rob --
    >
    > > it *also* needs to be null terminated. You won't be able to accomplish

    >
    > Curious statement. Why?
    >
    > Later... Karl
    > --
    > [Microsoft Basic: 1976-2001, RIP]
    >
    >
    >
    > "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    > news:3c14f149$1@147.208.176.211...
    > >
    > >
    > > I hate to break the bad news to you, but this is definitely not

    recommended.
    > > The first big barrier is that strings aren't immutable.
    > > The next issue you have to deal with is that a BSTR is a pointer to

    pointer
    > > to an array of wide (16-bit unicode) characters. The two bytes preceding
    > > the pointer are the number of characters. However, in order to be a

    valid
    > > string, it *also* needs to be null terminated. You won't be able to

    accomplish
    > > that part. A BSTR (or more appropriately, an OLECHAR) only guarantees

    what
    > > the data is supposed to look like, not how an operation works with the

    string,
    > > and certain operations will look for the null terminator.
    > >
    > > -Rob
    > >
    > > "Chris Lucas" <cdl1051@earthlink.net> wrote:
    > > >
    > > >Greetings all. I'm looking into alternative methods of grabbing the

    Mid$()
    > > >of a string. Specifically I want to use CopyMemory to modify the

    pointers
    > > >of elements of a string array so that they each point to different

    portions
    > > >of the same string, then use CopyMemory to make each element a certain

    length.
    > > > I can shift the string pointers easily enough, and specify the

    appropriate
    > > >length, but the results come back garbled. I'm thinking that this has

    to
    > > >do with the way string arrays are stored in memory. Below is the

    string
    > > >I'm working with, and the output I get, any help here is appreciated.

    BTW
    > > >I'm really using PeekLng/PokeLng for those of you familiar with those

    specialized
    > > >declarations of "RLTMoveMemory".
    > > >
    > > >My string to tokenize is: "First Second Third"
    > > >After 6 calls to CopyMemory my string elements are:
    > > > element(0) = "Fi "
    > > > element(1) = "Se "
    > > > element(2) = "Th "
    > > >
    > > >What gives, they point to the right place (obviously) and read the

    right
    > > >length, but those other bytes aren't where they are supposed to be.

    Thanks.
    > > >
    > > >Chris

    > >

    >




  7. #7
    Michael \(michka\) Kaplan Guest

    Re: Hardcore String Mid$'ing

    Why does it need to be? Or why can he not accomplish it?


    --
    MichKa

    Michael Kaplan
    (principal developer of the MSLU)
    Trigeminal Software, Inc. -- http://www.trigeminal.com/
    the book -- http://www.i18nWithVB.com/

    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3c153bb8@147.208.176.211...
    > Hi Rob --
    >
    > > it *also* needs to be null terminated. You won't be able to accomplish

    >
    > Curious statement. Why?
    >
    > Later... Karl
    > --
    > [Microsoft Basic: 1976-2001, RIP]
    >
    >
    >
    > "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    > news:3c14f149$1@147.208.176.211...
    > >
    > >
    > > I hate to break the bad news to you, but this is definitely not

    recommended.
    > > The first big barrier is that strings aren't immutable.
    > > The next issue you have to deal with is that a BSTR is a pointer to

    pointer
    > > to an array of wide (16-bit unicode) characters. The two bytes preceding
    > > the pointer are the number of characters. However, in order to be a

    valid
    > > string, it *also* needs to be null terminated. You won't be able to

    accomplish
    > > that part. A BSTR (or more appropriately, an OLECHAR) only guarantees

    what
    > > the data is supposed to look like, not how an operation works with the

    string,
    > > and certain operations will look for the null terminator.
    > >
    > > -Rob
    > >
    > > "Chris Lucas" <cdl1051@earthlink.net> wrote:
    > > >
    > > >Greetings all. I'm looking into alternative methods of grabbing the

    Mid$()
    > > >of a string. Specifically I want to use CopyMemory to modify the

    pointers
    > > >of elements of a string array so that they each point to different

    portions
    > > >of the same string, then use CopyMemory to make each element a certain

    length.
    > > > I can shift the string pointers easily enough, and specify the

    appropriate
    > > >length, but the results come back garbled. I'm thinking that this has

    to
    > > >do with the way string arrays are stored in memory. Below is the

    string
    > > >I'm working with, and the output I get, any help here is appreciated.

    BTW
    > > >I'm really using PeekLng/PokeLng for those of you familiar with those

    specialized
    > > >declarations of "RLTMoveMemory".
    > > >
    > > >My string to tokenize is: "First Second Third"
    > > >After 6 calls to CopyMemory my string elements are:
    > > > element(0) = "Fi "
    > > > element(1) = "Se "
    > > > element(2) = "Th "
    > > >
    > > >What gives, they point to the right place (obviously) and read the

    right
    > > >length, but those other bytes aren't where they are supposed to be.

    Thanks.
    > > >
    > > >Chris

    > >

    >




  8. #8
    Karl E. Peterson Guest

    Re: Hardcore String Mid$'ing

    Yeah, the latter.

    I went back and reread the original question, and I'm not fully sure I understand
    anyway, so perhaps my question is out of place? I guess if the OP is enlarging the
    string elements, yeah, that'd be a problem. But if their contents is simply being
    replaced...?
    --
    [Microsoft Basic: 1976-2001, RIP]


    "Michael (michka) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote in
    message news:3c153c2f$1@147.208.176.211...
    > Why does it need to be? Or why can he not accomplish it?
    >
    >
    > --
    > MichKa
    >
    > Michael Kaplan
    > (principal developer of the MSLU)
    > Trigeminal Software, Inc. -- http://www.trigeminal.com/
    > the book -- http://www.i18nWithVB.com/
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:3c153bb8@147.208.176.211...
    > > Hi Rob --
    > >
    > > > it *also* needs to be null terminated. You won't be able to accomplish

    > >
    > > Curious statement. Why?
    > >
    > > Later... Karl
    > > --
    > > [Microsoft Basic: 1976-2001, RIP]
    > >
    > >
    > >
    > > "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    > > news:3c14f149$1@147.208.176.211...
    > > >
    > > >
    > > > I hate to break the bad news to you, but this is definitely not

    > recommended.
    > > > The first big barrier is that strings aren't immutable.
    > > > The next issue you have to deal with is that a BSTR is a pointer to

    > pointer
    > > > to an array of wide (16-bit unicode) characters. The two bytes preceding
    > > > the pointer are the number of characters. However, in order to be a

    > valid
    > > > string, it *also* needs to be null terminated. You won't be able to

    > accomplish
    > > > that part. A BSTR (or more appropriately, an OLECHAR) only guarantees

    > what
    > > > the data is supposed to look like, not how an operation works with the

    > string,
    > > > and certain operations will look for the null terminator.
    > > >
    > > > -Rob
    > > >
    > > > "Chris Lucas" <cdl1051@earthlink.net> wrote:
    > > > >
    > > > >Greetings all. I'm looking into alternative methods of grabbing the

    > Mid$()
    > > > >of a string. Specifically I want to use CopyMemory to modify the

    > pointers
    > > > >of elements of a string array so that they each point to different

    > portions
    > > > >of the same string, then use CopyMemory to make each element a certain

    > length.
    > > > > I can shift the string pointers easily enough, and specify the

    > appropriate
    > > > >length, but the results come back garbled. I'm thinking that this has

    > to
    > > > >do with the way string arrays are stored in memory. Below is the

    > string
    > > > >I'm working with, and the output I get, any help here is appreciated.

    > BTW
    > > > >I'm really using PeekLng/PokeLng for those of you familiar with those

    > specialized
    > > > >declarations of "RLTMoveMemory".
    > > > >
    > > > >My string to tokenize is: "First Second Third"
    > > > >After 6 calls to CopyMemory my string elements are:
    > > > > element(0) = "Fi "
    > > > > element(1) = "Se "
    > > > > element(2) = "Th "
    > > > >
    > > > >What gives, they point to the right place (obviously) and read the

    > right
    > > > >length, but those other bytes aren't where they are supposed to be.

    > Thanks.
    > > > >
    > > > >Chris
    > > >

    > >

    >
    >



  9. #9
    Karl E. Peterson Guest

    Re: Hardcore String Mid$'ing

    Yeah, the latter.

    I went back and reread the original question, and I'm not fully sure I understand
    anyway, so perhaps my question is out of place? I guess if the OP is enlarging the
    string elements, yeah, that'd be a problem. But if their contents is simply being
    replaced...?
    --
    [Microsoft Basic: 1976-2001, RIP]


    "Michael (michka) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote in
    message news:3c153c2f$1@147.208.176.211...
    > Why does it need to be? Or why can he not accomplish it?
    >
    >
    > --
    > MichKa
    >
    > Michael Kaplan
    > (principal developer of the MSLU)
    > Trigeminal Software, Inc. -- http://www.trigeminal.com/
    > the book -- http://www.i18nWithVB.com/
    >
    > "Karl E. Peterson" <karl@mvps.org> wrote in message
    > news:3c153bb8@147.208.176.211...
    > > Hi Rob --
    > >
    > > > it *also* needs to be null terminated. You won't be able to accomplish

    > >
    > > Curious statement. Why?
    > >
    > > Later... Karl
    > > --
    > > [Microsoft Basic: 1976-2001, RIP]
    > >
    > >
    > >
    > > "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    > > news:3c14f149$1@147.208.176.211...
    > > >
    > > >
    > > > I hate to break the bad news to you, but this is definitely not

    > recommended.
    > > > The first big barrier is that strings aren't immutable.
    > > > The next issue you have to deal with is that a BSTR is a pointer to

    > pointer
    > > > to an array of wide (16-bit unicode) characters. The two bytes preceding
    > > > the pointer are the number of characters. However, in order to be a

    > valid
    > > > string, it *also* needs to be null terminated. You won't be able to

    > accomplish
    > > > that part. A BSTR (or more appropriately, an OLECHAR) only guarantees

    > what
    > > > the data is supposed to look like, not how an operation works with the

    > string,
    > > > and certain operations will look for the null terminator.
    > > >
    > > > -Rob
    > > >
    > > > "Chris Lucas" <cdl1051@earthlink.net> wrote:
    > > > >
    > > > >Greetings all. I'm looking into alternative methods of grabbing the

    > Mid$()
    > > > >of a string. Specifically I want to use CopyMemory to modify the

    > pointers
    > > > >of elements of a string array so that they each point to different

    > portions
    > > > >of the same string, then use CopyMemory to make each element a certain

    > length.
    > > > > I can shift the string pointers easily enough, and specify the

    > appropriate
    > > > >length, but the results come back garbled. I'm thinking that this has

    > to
    > > > >do with the way string arrays are stored in memory. Below is the

    > string
    > > > >I'm working with, and the output I get, any help here is appreciated.

    > BTW
    > > > >I'm really using PeekLng/PokeLng for those of you familiar with those

    > specialized
    > > > >declarations of "RLTMoveMemory".
    > > > >
    > > > >My string to tokenize is: "First Second Third"
    > > > >After 6 calls to CopyMemory my string elements are:
    > > > > element(0) = "Fi "
    > > > > element(1) = "Se "
    > > > > element(2) = "Th "
    > > > >
    > > > >What gives, they point to the right place (obviously) and read the

    > right
    > > > >length, but those other bytes aren't where they are supposed to be.

    > Thanks.
    > > > >
    > > > >Chris
    > > >

    > >

    >
    >



  10. #10
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    Karl and Co.,

    What I'm trying to accomplish here is to pretty much fake a string array.
    By using SysAllocStringByteLen I generate elements of my string array (who
    knows or cares what they contain!). Then hack their pointers and the byte
    that holds their length, so that they all point to unique chunks of one long
    string. By doing this, I am tokenizing the long string and moving these
    tokens into my string array. Of course, all this is fake, and if the long
    string changes, so do my elements, but thats ok. I'm sure this seems like
    a lot of trouble when I could just call Mid$() but with long tokens I'm betting
    this is much much faster than actually shifting copies of the data around.
    That said, my problem remains. I can make each pointer point at the
    correct starting location in the long string, and I can force each element
    to be the correct length, but things don't quite work out. Lemme break down
    what I'm doing, then maybe someone can tell me why its not working...

    1. I use PokeLng (CopyMem) to alter str(0)'s string pointer, now it points
    at the begining of strTarget lets call it.

    2. I use PokeLng again, this time I poke a value of 10 to the address StrPtr(str(0))
    - 4. This is where the length is stored.

    3. I read the contents of str(0). Rather than containing "First" as expected
    if contains "Fi ".

    So what the heck? Aren't the characters "rst" stored right after "Fi" in
    memory? I was under the impression that strings were stored continously
    in memory. Or does the problem lie with the string array's element? Hope
    someone out there has some voodoo for me, I've said a mouthful.

    Chris

  11. #11
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    Karl and Co.,

    What I'm trying to accomplish here is to pretty much fake a string array.
    By using SysAllocStringByteLen I generate elements of my string array (who
    knows or cares what they contain!). Then hack their pointers and the byte
    that holds their length, so that they all point to unique chunks of one long
    string. By doing this, I am tokenizing the long string and moving these
    tokens into my string array. Of course, all this is fake, and if the long
    string changes, so do my elements, but thats ok. I'm sure this seems like
    a lot of trouble when I could just call Mid$() but with long tokens I'm betting
    this is much much faster than actually shifting copies of the data around.
    That said, my problem remains. I can make each pointer point at the
    correct starting location in the long string, and I can force each element
    to be the correct length, but things don't quite work out. Lemme break down
    what I'm doing, then maybe someone can tell me why its not working...

    1. I use PokeLng (CopyMem) to alter str(0)'s string pointer, now it points
    at the begining of strTarget lets call it.

    2. I use PokeLng again, this time I poke a value of 10 to the address StrPtr(str(0))
    - 4. This is where the length is stored.

    3. I read the contents of str(0). Rather than containing "First" as expected
    if contains "Fi ".

    So what the heck? Aren't the characters "rst" stored right after "Fi" in
    memory? I was under the impression that strings were stored continously
    in memory. Or does the problem lie with the string array's element? Hope
    someone out there has some voodoo for me, I've said a mouthful.

    Chris

  12. #12
    Michael \(michka\) Kaplan Guest

    Re: Hardcore String Mid$'ing

    This is a REALLY really REALLY really bad idea.

    These strings are allocated (as are all BSTRs) and your mucking is going to
    cause memory to leak. You are really gaining nothing here but problems.


    --
    MichKa

    Michael Kaplan
    (principal developer of the MSLU)
    Trigeminal Software, Inc. -- http://www.trigeminal.com/
    the book -- http://www.i18nWithVB.com/

    "Chris Lucas" <cdl1051@earthlink.net> wrote in message
    news:3c154edb$1@147.208.176.211...
    >
    > Karl and Co.,
    >
    > What I'm trying to accomplish here is to pretty much fake a string

    array.
    > By using SysAllocStringByteLen I generate elements of my string array

    (who
    > knows or cares what they contain!). Then hack their pointers and the byte
    > that holds their length, so that they all point to unique chunks of one

    long
    > string. By doing this, I am tokenizing the long string and moving these
    > tokens into my string array. Of course, all this is fake, and if the long
    > string changes, so do my elements, but thats ok. I'm sure this seems like
    > a lot of trouble when I could just call Mid$() but with long tokens I'm

    betting
    > this is much much faster than actually shifting copies of the data around.
    > That said, my problem remains. I can make each pointer point at the
    > correct starting location in the long string, and I can force each element
    > to be the correct length, but things don't quite work out. Lemme break

    down
    > what I'm doing, then maybe someone can tell me why its not working...
    >
    > 1. I use PokeLng (CopyMem) to alter str(0)'s string pointer, now it points
    > at the begining of strTarget lets call it.
    >
    > 2. I use PokeLng again, this time I poke a value of 10 to the address

    StrPtr(str(0))
    > - 4. This is where the length is stored.
    >
    > 3. I read the contents of str(0). Rather than containing "First" as

    expected
    > if contains "Fi ".
    >
    > So what the heck? Aren't the characters "rst" stored right after "Fi" in
    > memory? I was under the impression that strings were stored continously
    > in memory. Or does the problem lie with the string array's element? Hope
    > someone out there has some voodoo for me, I've said a mouthful.
    >
    > Chris




  13. #13
    Michael \(michka\) Kaplan Guest

    Re: Hardcore String Mid$'ing

    This is a REALLY really REALLY really bad idea.

    These strings are allocated (as are all BSTRs) and your mucking is going to
    cause memory to leak. You are really gaining nothing here but problems.


    --
    MichKa

    Michael Kaplan
    (principal developer of the MSLU)
    Trigeminal Software, Inc. -- http://www.trigeminal.com/
    the book -- http://www.i18nWithVB.com/

    "Chris Lucas" <cdl1051@earthlink.net> wrote in message
    news:3c154edb$1@147.208.176.211...
    >
    > Karl and Co.,
    >
    > What I'm trying to accomplish here is to pretty much fake a string

    array.
    > By using SysAllocStringByteLen I generate elements of my string array

    (who
    > knows or cares what they contain!). Then hack their pointers and the byte
    > that holds their length, so that they all point to unique chunks of one

    long
    > string. By doing this, I am tokenizing the long string and moving these
    > tokens into my string array. Of course, all this is fake, and if the long
    > string changes, so do my elements, but thats ok. I'm sure this seems like
    > a lot of trouble when I could just call Mid$() but with long tokens I'm

    betting
    > this is much much faster than actually shifting copies of the data around.
    > That said, my problem remains. I can make each pointer point at the
    > correct starting location in the long string, and I can force each element
    > to be the correct length, but things don't quite work out. Lemme break

    down
    > what I'm doing, then maybe someone can tell me why its not working...
    >
    > 1. I use PokeLng (CopyMem) to alter str(0)'s string pointer, now it points
    > at the begining of strTarget lets call it.
    >
    > 2. I use PokeLng again, this time I poke a value of 10 to the address

    StrPtr(str(0))
    > - 4. This is where the length is stored.
    >
    > 3. I read the contents of str(0). Rather than containing "First" as

    expected
    > if contains "Fi ".
    >
    > So what the heck? Aren't the characters "rst" stored right after "Fi" in
    > memory? I was under the impression that strings were stored continously
    > in memory. Or does the problem lie with the string array's element? Hope
    > someone out there has some voodoo for me, I've said a mouthful.
    >
    > Chris




  14. #14
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    I understand the concerns, and everyone else seems to agree with you,
    but I'd still like to know if this can be done and if so how. My guess is
    it can be made to work, then if there's no performance gain, its moot so
    no biggie.

    Chris

    "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
    >This is a REALLY really REALLY really bad idea.
    >
    >These strings are allocated (as are all BSTRs) and your mucking is going

    to
    >cause memory to leak. You are really gaining nothing here but problems.
    >
    >
    >--
    >MichKa
    >
    >Michael Kaplan
    >(principal developer of the MSLU)
    >Trigeminal Software, Inc. -- http://www.trigeminal.com/
    >the book -- http://www.i18nWithVB.com/
    >
    >"Chris Lucas" <cdl1051@earthlink.net> wrote in message
    >news:3c154edb$1@147.208.176.211...
    >>
    >> Karl and Co.,
    >>
    >> What I'm trying to accomplish here is to pretty much fake a string

    >array.
    >> By using SysAllocStringByteLen I generate elements of my string array

    >(who
    >> knows or cares what they contain!). Then hack their pointers and the

    byte
    >> that holds their length, so that they all point to unique chunks of one

    >long
    >> string. By doing this, I am tokenizing the long string and moving these
    >> tokens into my string array. Of course, all this is fake, and if the

    long
    >> string changes, so do my elements, but thats ok. I'm sure this seems

    like
    >> a lot of trouble when I could just call Mid$() but with long tokens I'm

    >betting
    >> this is much much faster than actually shifting copies of the data around.
    >> That said, my problem remains. I can make each pointer point at the
    >> correct starting location in the long string, and I can force each element
    >> to be the correct length, but things don't quite work out. Lemme break

    >down
    >> what I'm doing, then maybe someone can tell me why its not working...
    >>
    >> 1. I use PokeLng (CopyMem) to alter str(0)'s string pointer, now it points
    >> at the begining of strTarget lets call it.
    >>
    >> 2. I use PokeLng again, this time I poke a value of 10 to the address

    >StrPtr(str(0))
    >> - 4. This is where the length is stored.
    >>
    >> 3. I read the contents of str(0). Rather than containing "First" as

    >expected
    >> if contains "Fi ".
    >>
    >> So what the heck? Aren't the characters "rst" stored right after "Fi"

    in
    >> memory? I was under the impression that strings were stored continously
    >> in memory. Or does the problem lie with the string array's element?

    Hope
    >> someone out there has some voodoo for me, I've said a mouthful.
    >>
    >> Chris

    >
    >



  15. #15
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    I understand the concerns, and everyone else seems to agree with you,
    but I'd still like to know if this can be done and if so how. My guess is
    it can be made to work, then if there's no performance gain, its moot so
    no biggie.

    Chris

    "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
    >This is a REALLY really REALLY really bad idea.
    >
    >These strings are allocated (as are all BSTRs) and your mucking is going

    to
    >cause memory to leak. You are really gaining nothing here but problems.
    >
    >
    >--
    >MichKa
    >
    >Michael Kaplan
    >(principal developer of the MSLU)
    >Trigeminal Software, Inc. -- http://www.trigeminal.com/
    >the book -- http://www.i18nWithVB.com/
    >
    >"Chris Lucas" <cdl1051@earthlink.net> wrote in message
    >news:3c154edb$1@147.208.176.211...
    >>
    >> Karl and Co.,
    >>
    >> What I'm trying to accomplish here is to pretty much fake a string

    >array.
    >> By using SysAllocStringByteLen I generate elements of my string array

    >(who
    >> knows or cares what they contain!). Then hack their pointers and the

    byte
    >> that holds their length, so that they all point to unique chunks of one

    >long
    >> string. By doing this, I am tokenizing the long string and moving these
    >> tokens into my string array. Of course, all this is fake, and if the

    long
    >> string changes, so do my elements, but thats ok. I'm sure this seems

    like
    >> a lot of trouble when I could just call Mid$() but with long tokens I'm

    >betting
    >> this is much much faster than actually shifting copies of the data around.
    >> That said, my problem remains. I can make each pointer point at the
    >> correct starting location in the long string, and I can force each element
    >> to be the correct length, but things don't quite work out. Lemme break

    >down
    >> what I'm doing, then maybe someone can tell me why its not working...
    >>
    >> 1. I use PokeLng (CopyMem) to alter str(0)'s string pointer, now it points
    >> at the begining of strTarget lets call it.
    >>
    >> 2. I use PokeLng again, this time I poke a value of 10 to the address

    >StrPtr(str(0))
    >> - 4. This is where the length is stored.
    >>
    >> 3. I read the contents of str(0). Rather than containing "First" as

    >expected
    >> if contains "Fi ".
    >>
    >> So what the heck? Aren't the characters "rst" stored right after "Fi"

    in
    >> memory? I was under the impression that strings were stored continously
    >> in memory. Or does the problem lie with the string array's element?

    Hope
    >> someone out there has some voodoo for me, I've said a mouthful.
    >>
    >> Chris

    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center