DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 4 FirstFirst 1234 LastLast
Results 31 to 45 of 49

Thread: Hardcore String Mid$'ing

  1. #31
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    Well, this thread has gotten rather long eh? Anyway, I was poking my
    pointer into the wrong spot. What I originally thought was the solution
    was nothing more than a super low level mid. I wound up NOT allocating the
    string with the API. You don't have to. By changing 4 to 10 on the CopyMem
    call, windows really was copying "First" into asFoo(0). This is too much
    work, I was trying to get around actually moving memory. As best as I can
    tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    bytes exist after the CopyMem call.
    The real solution was to poke the value of StrPtr(strToken) into VarPtr(asFoo(0)).
    Now the string element points to the spot in memory where strToken lives.
    Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    not allocated any strings, do I still get a memory leak? I don't see how,
    but I'll leave it the the gurus to tell me.
    And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    ill-advised. Thus is the price of fast string ops in VB.

    Chris

  2. #32
    Michael \(michka\) Kaplan Guest

    Re: Hardcore String Mid$'ing

    Exactly. Which is the main reason that all of this mucking about is kind of
    useless.


    --
    MichKa

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

    "Paul Marshall" <pmarshal@vulcraft-al.com> wrote in message
    news:f4ic1uk78ii8nrhuova0g95f1s22g8oqeh@4ax.com...
    > On 11 Dec 2001 15:54:43 GMT, "Chris Lucas"
    > <cdl1051@earthlink.net> wrote:
    >
    > Michael,
    >
    > As I understand it a memory leak is a chunk of memory that continues
    > to be thought of as used by windows even though it is not. So your

    saying
    > when the string and the array go out of scope, because they are both

    pointing
    > to the same spot in memory, this portion will not become free?
    >
    > I would be more concerned with the memory originally pointed to
    > by the strings in the array. Having allocated those strings with
    > SysAllocStringByteLen, do you call SysFreeString? Should you?
    >
    >
    > --
    > Paul Marshall
    > pmarshal@vulcraft-al.com




  3. #33
    Michael \(michka\) Kaplan Guest

    Re: Hardcore String Mid$'ing

    Exactly. Which is the main reason that all of this mucking about is kind of
    useless.


    --
    MichKa

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

    "Paul Marshall" <pmarshal@vulcraft-al.com> wrote in message
    news:f4ic1uk78ii8nrhuova0g95f1s22g8oqeh@4ax.com...
    > On 11 Dec 2001 15:54:43 GMT, "Chris Lucas"
    > <cdl1051@earthlink.net> wrote:
    >
    > Michael,
    >
    > As I understand it a memory leak is a chunk of memory that continues
    > to be thought of as used by windows even though it is not. So your

    saying
    > when the string and the array go out of scope, because they are both

    pointing
    > to the same spot in memory, this portion will not become free?
    >
    > I would be more concerned with the memory originally pointed to
    > by the strings in the array. Having allocated those strings with
    > SysAllocStringByteLen, do you call SysFreeString? Should you?
    >
    >
    > --
    > Paul Marshall
    > pmarshal@vulcraft-al.com




  4. #34
    Paul Marshall Guest

    Re: Hardcore String Mid$'ing

    On 11 Dec 2001 15:54:43 GMT, "Chris Lucas"
    <cdl1051@earthlink.net> wrote:

    Michael,

    As I understand it a memory leak is a chunk of memory that continues
    to be thought of as used by windows even though it is not. So your saying
    when the string and the array go out of scope, because they are both pointing
    to the same spot in memory, this portion will not become free?

    I would be more concerned with the memory originally pointed to
    by the strings in the array. Having allocated those strings with
    SysAllocStringByteLen, do you call SysFreeString? Should you?


    --
    Paul Marshall
    pmarshal@vulcraft-al.com

  5. #35
    Paul Marshall Guest

    Re: Hardcore String Mid$'ing

    On 11 Dec 2001 15:54:43 GMT, "Chris Lucas"
    <cdl1051@earthlink.net> wrote:

    Michael,

    As I understand it a memory leak is a chunk of memory that continues
    to be thought of as used by windows even though it is not. So your saying
    when the string and the array go out of scope, because they are both pointing
    to the same spot in memory, this portion will not become free?

    I would be more concerned with the memory originally pointed to
    by the strings in the array. Having allocated those strings with
    SysAllocStringByteLen, do you call SysFreeString? Should you?


    --
    Paul Marshall
    pmarshal@vulcraft-al.com

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

    Re: Hardcore String Mid$'ing

    I am unclear on what the heck you have actually gained here in terms of
    speed that could not be gained by more effective means? Are you really
    gaining a **** thing other than job security since no one else will be able
    to look at this code and have the first clue what you are doing?


    --
    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:3c16483d@147.208.176.211...
    >
    > Well, this thread has gotten rather long eh? Anyway, I was poking my
    > pointer into the wrong spot. What I originally thought was the solution
    > was nothing more than a super low level mid. I wound up NOT allocating

    the
    > string with the API. You don't have to. By changing 4 to 10 on the

    CopyMem
    > call, windows really was copying "First" into asFoo(0). This is too much
    > work, I was trying to get around actually moving memory. As best as I can
    > tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    > bytes exist after the CopyMem call.
    > The real solution was to poke the value of StrPtr(strToken) into

    VarPtr(asFoo(0)).
    > Now the string element points to the spot in memory where strToken lives.
    > Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    > not allocated any strings, do I still get a memory leak? I don't see how,
    > but I'll leave it the the gurus to tell me.
    > And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    > ill-advised. Thus is the price of fast string ops in VB.
    >
    > Chris




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

    Re: Hardcore String Mid$'ing

    I am unclear on what the heck you have actually gained here in terms of
    speed that could not be gained by more effective means? Are you really
    gaining a **** thing other than job security since no one else will be able
    to look at this code and have the first clue what you are doing?


    --
    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:3c16483d@147.208.176.211...
    >
    > Well, this thread has gotten rather long eh? Anyway, I was poking my
    > pointer into the wrong spot. What I originally thought was the solution
    > was nothing more than a super low level mid. I wound up NOT allocating

    the
    > string with the API. You don't have to. By changing 4 to 10 on the

    CopyMem
    > call, windows really was copying "First" into asFoo(0). This is too much
    > work, I was trying to get around actually moving memory. As best as I can
    > tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    > bytes exist after the CopyMem call.
    > The real solution was to poke the value of StrPtr(strToken) into

    VarPtr(asFoo(0)).
    > Now the string element points to the spot in memory where strToken lives.
    > Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    > not allocated any strings, do I still get a memory leak? I don't see how,
    > but I'll leave it the the gurus to tell me.
    > And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    > ill-advised. Thus is the price of fast string ops in VB.
    >
    > Chris




  8. #38
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    Michael,

    Good question, the answer is not much, it doesn't even work. What *I*
    have gained is a better understanding of string arrays and the way they are
    stored in memory (hey, every cloud right?). Yeah, unless the string is "First12Second10Third"
    it won't work. Like someone already pointed out, when I set the string element
    lengths I corrupt the original string. I'm pretty sure I won't be able to
    get around that. Anyway, thanks for the help, I do appreciate it, but it
    looks like Windows wins this round.

    Chris

    "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
    >I am unclear on what the heck you have actually gained here in terms of
    >speed that could not be gained by more effective means? Are you really
    >gaining a **** thing other than job security since no one else will be able
    >to look at this code and have the first clue what you are doing?
    >
    >
    >--
    >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:3c16483d@147.208.176.211...
    >>
    >> Well, this thread has gotten rather long eh? Anyway, I was poking

    my
    >> pointer into the wrong spot. What I originally thought was the solution
    >> was nothing more than a super low level mid. I wound up NOT allocating

    >the
    >> string with the API. You don't have to. By changing 4 to 10 on the

    >CopyMem
    >> call, windows really was copying "First" into asFoo(0). This is too much
    >> work, I was trying to get around actually moving memory. As best as I

    can
    >> tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    >> bytes exist after the CopyMem call.
    >> The real solution was to poke the value of StrPtr(strToken) into

    >VarPtr(asFoo(0)).
    >> Now the string element points to the spot in memory where strToken lives.
    >> Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    >> not allocated any strings, do I still get a memory leak? I don't see

    how,
    >> but I'll leave it the the gurus to tell me.
    >> And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    >> ill-advised. Thus is the price of fast string ops in VB.
    >>
    >> Chris

    >
    >



  9. #39
    Chris Lucas Guest

    Re: Hardcore String Mid$'ing


    Michael,

    Good question, the answer is not much, it doesn't even work. What *I*
    have gained is a better understanding of string arrays and the way they are
    stored in memory (hey, every cloud right?). Yeah, unless the string is "First12Second10Third"
    it won't work. Like someone already pointed out, when I set the string element
    lengths I corrupt the original string. I'm pretty sure I won't be able to
    get around that. Anyway, thanks for the help, I do appreciate it, but it
    looks like Windows wins this round.

    Chris

    "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
    >I am unclear on what the heck you have actually gained here in terms of
    >speed that could not be gained by more effective means? Are you really
    >gaining a **** thing other than job security since no one else will be able
    >to look at this code and have the first clue what you are doing?
    >
    >
    >--
    >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:3c16483d@147.208.176.211...
    >>
    >> Well, this thread has gotten rather long eh? Anyway, I was poking

    my
    >> pointer into the wrong spot. What I originally thought was the solution
    >> was nothing more than a super low level mid. I wound up NOT allocating

    >the
    >> string with the API. You don't have to. By changing 4 to 10 on the

    >CopyMem
    >> call, windows really was copying "First" into asFoo(0). This is too much
    >> work, I was trying to get around actually moving memory. As best as I

    can
    >> tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    >> bytes exist after the CopyMem call.
    >> The real solution was to poke the value of StrPtr(strToken) into

    >VarPtr(asFoo(0)).
    >> Now the string element points to the spot in memory where strToken lives.
    >> Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    >> not allocated any strings, do I still get a memory leak? I don't see

    how,
    >> but I'll leave it the the gurus to tell me.
    >> And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    >> ill-advised. Thus is the price of fast string ops in VB.
    >>
    >> Chris

    >
    >



  10. #40
    Rob Teixeira Guest

    Re: Hardcore String Mid$'ing


    For the sake of completeness:

    "Chris Lucas" <cdl1051@earthlink.net> wrote:
    >
    > The real solution was to poke the value of StrPtr(strToken) into VarPtr(asFoo(0)).
    > Now the string element points to the spot in memory where strToken lives.
    > Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    >not allocated any strings, do I still get a memory leak? I don't see how,
    >but I'll leave it the the gurus to tell me.


    If I remember correctly, creating a string variable, such as

    Dim MyString As String

    doesn't automatically call SysAllocString. It just allocates a new BSTR pointer,
    and its value is zero. SysAllocString is called automatically the first time
    you assign a value to that string.

    MyString = "Hello"

    If I'm not mistaken, SysFreeString is always called when the variable goes
    out of scope. Freeing a null pointer just doesn't do anything.

    So, as you probably already suspect, if you've somehow performed a native
    operation that allocates a string, then you move the pointer around, the
    original string data is orphaned in memory.

    By the way, if you go through the trouble of manually placing the character
    count and null terminator, the only thing you've gained is the heap allocation
    time, which is pretty insignificant at best.

    > And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    >ill-advised. Thus is the price of fast string ops in VB.


    I certainly hope it didn't come across that negatively!

    -Rob

  11. #41
    Rob Teixeira Guest

    Re: Hardcore String Mid$'ing


    For the sake of completeness:

    "Chris Lucas" <cdl1051@earthlink.net> wrote:
    >
    > The real solution was to poke the value of StrPtr(strToken) into VarPtr(asFoo(0)).
    > Now the string element points to the spot in memory where strToken lives.
    > Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    >not allocated any strings, do I still get a memory leak? I don't see how,
    >but I'll leave it the the gurus to tell me.


    If I remember correctly, creating a string variable, such as

    Dim MyString As String

    doesn't automatically call SysAllocString. It just allocates a new BSTR pointer,
    and its value is zero. SysAllocString is called automatically the first time
    you assign a value to that string.

    MyString = "Hello"

    If I'm not mistaken, SysFreeString is always called when the variable goes
    out of scope. Freeing a null pointer just doesn't do anything.

    So, as you probably already suspect, if you've somehow performed a native
    operation that allocates a string, then you move the pointer around, the
    original string data is orphaned in memory.

    By the way, if you go through the trouble of manually placing the character
    count and null terminator, the only thing you've gained is the heap allocation
    time, which is pretty insignificant at best.

    > And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    >ill-advised. Thus is the price of fast string ops in VB.


    I certainly hope it didn't come across that negatively!

    -Rob

  12. #42
    Karl E. Peterson Guest

    Re: Hardcore String Mid$'ing

    Hi Chris --

    Well, I'm back late to the party, I see. <g> Sure sounds like a fun exercise,
    regardless. No better way to learn than to defy stupidity and pay attention to what
    happens, eh!? <vbg>

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


    "Chris Lucas" <cdl1051@earthlink.net> wrote in message
    news:3c166423$1@147.208.176.211...
    >
    > Michael,
    >
    > Good question, the answer is not much, it doesn't even work. What *I*
    > have gained is a better understanding of string arrays and the way they are
    > stored in memory (hey, every cloud right?). Yeah, unless the string is

    "First12Second10Third"
    > it won't work. Like someone already pointed out, when I set the string element
    > lengths I corrupt the original string. I'm pretty sure I won't be able to
    > get around that. Anyway, thanks for the help, I do appreciate it, but it
    > looks like Windows wins this round.
    >
    > Chris
    >
    > "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
    > >I am unclear on what the heck you have actually gained here in terms of
    > >speed that could not be gained by more effective means? Are you really
    > >gaining a **** thing other than job security since no one else will be able
    > >to look at this code and have the first clue what you are doing?
    > >
    > >
    > >--
    > >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:3c16483d@147.208.176.211...
    > >>
    > >> Well, this thread has gotten rather long eh? Anyway, I was poking

    > my
    > >> pointer into the wrong spot. What I originally thought was the solution
    > >> was nothing more than a super low level mid. I wound up NOT allocating

    > >the
    > >> string with the API. You don't have to. By changing 4 to 10 on the

    > >CopyMem
    > >> call, windows really was copying "First" into asFoo(0). This is too much
    > >> work, I was trying to get around actually moving memory. As best as I

    > can
    > >> tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    > >> bytes exist after the CopyMem call.
    > >> The real solution was to poke the value of StrPtr(strToken) into

    > >VarPtr(asFoo(0)).
    > >> Now the string element points to the spot in memory where strToken lives.
    > >> Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    > >> not allocated any strings, do I still get a memory leak? I don't see

    > how,
    > >> but I'll leave it the the gurus to tell me.
    > >> And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    > >> ill-advised. Thus is the price of fast string ops in VB.
    > >>
    > >> Chris

    > >
    > >

    >



  13. #43
    Karl E. Peterson Guest

    Re: Hardcore String Mid$'ing

    Hi Chris --

    Well, I'm back late to the party, I see. <g> Sure sounds like a fun exercise,
    regardless. No better way to learn than to defy stupidity and pay attention to what
    happens, eh!? <vbg>

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


    "Chris Lucas" <cdl1051@earthlink.net> wrote in message
    news:3c166423$1@147.208.176.211...
    >
    > Michael,
    >
    > Good question, the answer is not much, it doesn't even work. What *I*
    > have gained is a better understanding of string arrays and the way they are
    > stored in memory (hey, every cloud right?). Yeah, unless the string is

    "First12Second10Third"
    > it won't work. Like someone already pointed out, when I set the string element
    > lengths I corrupt the original string. I'm pretty sure I won't be able to
    > get around that. Anyway, thanks for the help, I do appreciate it, but it
    > looks like Windows wins this round.
    >
    > Chris
    >
    > "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote:
    > >I am unclear on what the heck you have actually gained here in terms of
    > >speed that could not be gained by more effective means? Are you really
    > >gaining a **** thing other than job security since no one else will be able
    > >to look at this code and have the first clue what you are doing?
    > >
    > >
    > >--
    > >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:3c16483d@147.208.176.211...
    > >>
    > >> Well, this thread has gotten rather long eh? Anyway, I was poking

    > my
    > >> pointer into the wrong spot. What I originally thought was the solution
    > >> was nothing more than a super low level mid. I wound up NOT allocating

    > >the
    > >> string with the API. You don't have to. By changing 4 to 10 on the

    > >CopyMem
    > >> call, windows really was copying "First" into asFoo(0). This is too much
    > >> work, I was trying to get around actually moving memory. As best as I

    > can
    > >> tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of those
    > >> bytes exist after the CopyMem call.
    > >> The real solution was to poke the value of StrPtr(strToken) into

    > >VarPtr(asFoo(0)).
    > >> Now the string element points to the spot in memory where strToken lives.
    > >> Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since I've
    > >> not allocated any strings, do I still get a memory leak? I don't see

    > how,
    > >> but I'll leave it the the gurus to tell me.
    > >> And by the way, I'm glad I've been upgraded from "stupid" to perhaps
    > >> ill-advised. Thus is the price of fast string ops in VB.
    > >>
    > >> Chris

    > >
    > >

    >



  14. #44
    Michael Culley Guest

    Re: Hardcore String Mid$'ing

    I think it would be much better hacking the pointer for a byte array into
    the centre of the string. By setting the byte pointer back to zero all
    memory leaks would be avoided.

    --
    Michael Culley
    www.vbdotcom.com


    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3c191652$1@147.208.176.211...
    > Hi Chris --
    >
    > Well, I'm back late to the party, I see. <g> Sure sounds like a fun

    exercise,
    > regardless. No better way to learn than to defy stupidity and pay

    attention to what
    > happens, eh!? <vbg>
    >
    > Later... Karl
    > --
    > [Microsoft Basic: 1976-2001, RIP]
    >
    >
    > "Chris Lucas" <cdl1051@earthlink.net> wrote in message
    > news:3c166423$1@147.208.176.211...
    > >
    > > Michael,
    > >
    > > Good question, the answer is not much, it doesn't even work. What

    *I*
    > > have gained is a better understanding of string arrays and the way they

    are
    > > stored in memory (hey, every cloud right?). Yeah, unless the string is

    > "First12Second10Third"
    > > it won't work. Like someone already pointed out, when I set the string

    element
    > > lengths I corrupt the original string. I'm pretty sure I won't be able

    to
    > > get around that. Anyway, thanks for the help, I do appreciate it, but

    it
    > > looks like Windows wins this round.
    > >
    > > Chris
    > >
    > > "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com>

    wrote:
    > > >I am unclear on what the heck you have actually gained here in terms of
    > > >speed that could not be gained by more effective means? Are you really
    > > >gaining a **** thing other than job security since no one else will be

    able
    > > >to look at this code and have the first clue what you are doing?
    > > >
    > > >
    > > >--
    > > >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:3c16483d@147.208.176.211...
    > > >>
    > > >> Well, this thread has gotten rather long eh? Anyway, I was

    poking
    > > my
    > > >> pointer into the wrong spot. What I originally thought was the

    solution
    > > >> was nothing more than a super low level mid. I wound up NOT

    allocating
    > > >the
    > > >> string with the API. You don't have to. By changing 4 to 10 on the
    > > >CopyMem
    > > >> call, windows really was copying "First" into asFoo(0). This is too

    much
    > > >> work, I was trying to get around actually moving memory. As best as

    I
    > > can
    > > >> tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of

    those
    > > >> bytes exist after the CopyMem call.
    > > >> The real solution was to poke the value of StrPtr(strToken) into
    > > >VarPtr(asFoo(0)).
    > > >> Now the string element points to the spot in memory where strToken

    lives.
    > > >> Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since

    I've
    > > >> not allocated any strings, do I still get a memory leak? I don't see

    > > how,
    > > >> but I'll leave it the the gurus to tell me.
    > > >> And by the way, I'm glad I've been upgraded from "stupid" to

    perhaps
    > > >> ill-advised. Thus is the price of fast string ops in VB.
    > > >>
    > > >> Chris
    > > >
    > > >

    > >

    >




  15. #45
    Michael Culley Guest

    Re: Hardcore String Mid$'ing

    I think it would be much better hacking the pointer for a byte array into
    the centre of the string. By setting the byte pointer back to zero all
    memory leaks would be avoided.

    --
    Michael Culley
    www.vbdotcom.com


    "Karl E. Peterson" <karl@mvps.org> wrote in message
    news:3c191652$1@147.208.176.211...
    > Hi Chris --
    >
    > Well, I'm back late to the party, I see. <g> Sure sounds like a fun

    exercise,
    > regardless. No better way to learn than to defy stupidity and pay

    attention to what
    > happens, eh!? <vbg>
    >
    > Later... Karl
    > --
    > [Microsoft Basic: 1976-2001, RIP]
    >
    >
    > "Chris Lucas" <cdl1051@earthlink.net> wrote in message
    > news:3c166423$1@147.208.176.211...
    > >
    > > Michael,
    > >
    > > Good question, the answer is not much, it doesn't even work. What

    *I*
    > > have gained is a better understanding of string arrays and the way they

    are
    > > stored in memory (hey, every cloud right?). Yeah, unless the string is

    > "First12Second10Third"
    > > it won't work. Like someone already pointed out, when I set the string

    element
    > > lengths I corrupt the original string. I'm pretty sure I won't be able

    to
    > > get around that. Anyway, thanks for the help, I do appreciate it, but

    it
    > > looks like Windows wins this round.
    > >
    > > Chris
    > >
    > > "Michael \(michka\) Kaplan" <former_mvp@nospam.trigeminal.spamless.com>

    wrote:
    > > >I am unclear on what the heck you have actually gained here in terms of
    > > >speed that could not be gained by more effective means? Are you really
    > > >gaining a **** thing other than job security since no one else will be

    able
    > > >to look at this code and have the first clue what you are doing?
    > > >
    > > >
    > > >--
    > > >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:3c16483d@147.208.176.211...
    > > >>
    > > >> Well, this thread has gotten rather long eh? Anyway, I was

    poking
    > > my
    > > >> pointer into the wrong spot. What I originally thought was the

    solution
    > > >> was nothing more than a super low level mid. I wound up NOT

    allocating
    > > >the
    > > >> string with the API. You don't have to. By changing 4 to 10 on the
    > > >CopyMem
    > > >> call, windows really was copying "First" into asFoo(0). This is too

    much
    > > >> work, I was trying to get around actually moving memory. As best as

    I
    > > can
    > > >> tell, this is simply asFoo(0) = Mid$(strToken,1,5). Two copies of

    those
    > > >> bytes exist after the CopyMem call.
    > > >> The real solution was to poke the value of StrPtr(strToken) into
    > > >VarPtr(asFoo(0)).
    > > >> Now the string element points to the spot in memory where strToken

    lives.
    > > >> Then I poke 10 into StrPtr(asFoo(0))-4. Now my question is, since

    I've
    > > >> not allocated any strings, do I still get a memory leak? I don't see

    > > how,
    > > >> but I'll leave it the the gurus to tell me.
    > > >> And by the way, I'm glad I've been upgraded from "stupid" to

    perhaps
    > > >> ill-advised. Thus is the price of fast string ops in VB.
    > > >>
    > > >> 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