Strings and memory management

I think you would be amazed how often VB converts those strings, anyway....

--
MichKa
"Cause it's a bittersweet symphony, thats life..." -- The Verve

random junk of dubious value, at the multilingual,
no scripts required, http://www.trigeminal.com/

"Oren" <CompuMight@erols.com> wrote in message
news:39674bd7$1@news.devx.com...
> First of all, usually strings have to do with UI, the user is the slowest
part of a computer, :o), therefore if you must do "a" + "
> b" + "c", they most likely won't notice the less than a milisecond
difference, :o)
>
> Second of all, if you create an AX dll there is no unicode/ansi
conversion. You can cheat the conversion via type libraries.
>
>
> Oren
>
>

I think you would be amazed how often VB converts those strings, anyway....

--
MichKa
"Cause it's a bittersweet symphony, thats life..." -- The Verve

random junk of dubious value, at the multilingual,
no scripts required, http://www.trigeminal.com/

"Oren" <CompuMight@erols.com> wrote in message
news:39674bd7$1@news.devx.com...
> First of all, usually strings have to do with UI, the user is the slowest
part of a computer, :o), therefore if you must do "a" + "
> b" + "c", they most likely won't notice the less than a milisecond
difference, :o)
>
> Second of all, if you create an AX dll there is no unicode/ansi
conversion. You can cheat the conversion via type libraries.
>
>
> Oren
>
>

I know how many times, I've done many a dumps, :o)

Oren

I know how many times, I've done many a dumps, :o)

Oren

Brian,

> I program in C++ as well as VB and considered writing a function to do
this
> in C++.
> I envisioned passing Unicode strings to C++ and having to convert them to
> ANSI and then back
> again as well as having to copy them into a C++ string before casting it
> into a BSTR and passing
> it back. Alternatively, I suppose I could use byte arrays as strings and
> the API copyMemory into a
> fixed length string after determining the total length of the final
string.

Huh? If you are trying to optmize this process, why would you convert
Unicode to ANSI and then back?

If you use a typelib, VB can pass the Unicode strings unchanged. I would
think you'd then want to work with and return Unicode strings.

Also, be careful with CopyMemory (RtlMoveMemory) because it will convert the
strings to ANSI and back unless you use something like StrPtr to pass the
address of the Unicode data.

> I suppose the slowest step would probably be writing
> these strings to file rather than
> memory management of even large strings.

Amen to that!

Jonathan

Brian,

> I program in C++ as well as VB and considered writing a function to do
this
> in C++.
> I envisioned passing Unicode strings to C++ and having to convert them to
> ANSI and then back
> again as well as having to copy them into a C++ string before casting it
> into a BSTR and passing
> it back. Alternatively, I suppose I could use byte arrays as strings and
> the API copyMemory into a
> fixed length string after determining the total length of the final
string.

Huh? If you are trying to optmize this process, why would you convert
Unicode to ANSI and then back?

If you use a typelib, VB can pass the Unicode strings unchanged. I would
think you'd then want to work with and return Unicode strings.

Also, be careful with CopyMemory (RtlMoveMemory) because it will convert the
strings to ANSI and back unless you use something like StrPtr to pass the
address of the Unicode data.

> I suppose the slowest step would probably be writing
> these strings to file rather than
> memory management of even large strings.

Amen to that!

Jonathan

Oren,

> [...] I've done many a dumps, :o)

Please keep your bathroom habits private.

Jonathan

Oren,

> [...] I've done many a dumps, :o)

Please keep your bathroom habits private.

Jonathan

Hi Oren,

Sounds like you're looking at what VB does behind the scenes.
I don't know how to do this, but would like to find out.
Can you point me to any sites or books?

Thanks,

Brian


"Oren" <CompuMight@erols.com> wrote:
>I know how many times, I've done many a dumps, :o)
>
> Oren
>
>

Hi Oren,

Sounds like you're looking at what VB does behind the scenes.
I don't know how to do this, but would like to find out.
Can you point me to any sites or books?

Thanks,

Brian


"Oren" <CompuMight@erols.com> wrote:
>I know how many times, I've done many a dumps, :o)
>
> Oren
>
>

Hi Jonathan,
>
>Huh? If you are trying to optmize this process, why would you convert
>Unicode to ANSI and then back?

I wouldn't want to, which is why I didn't like this idea.

>
>If you use a typelib, VB can pass the Unicode strings unchanged. I would
>think you'd then want to work with and return Unicode strings.

Yes. that sounds like a better option. I should probably learn
how to do that, but until now have only been programming with
standard C++ features.

>
>Also, be careful with CopyMemory (RtlMoveMemory) because it will convert
the
>strings to ANSI and back unless you use something like StrPtr to pass the
>address of the Unicode data.

I hadn't considered that.

>
>> I suppose the slowest step would probably be writing
>> these strings to file rather than
>> memory management of even large strings.
>
>Amen to that!

Any suggestions on how best to write to file? i.e., is it
better to concatenate a large string and write that rather than
writing separate small string?? Is there a optimal string
length to write at a time?

Cheers,

Brian
>
>Jonathan
>
>
>

Hi Jonathan,
>
>Huh? If you are trying to optmize this process, why would you convert
>Unicode to ANSI and then back?

I wouldn't want to, which is why I didn't like this idea.

>
>If you use a typelib, VB can pass the Unicode strings unchanged. I would
>think you'd then want to work with and return Unicode strings.

Yes. that sounds like a better option. I should probably learn
how to do that, but until now have only been programming with
standard C++ features.

>
>Also, be careful with CopyMemory (RtlMoveMemory) because it will convert
the
>strings to ANSI and back unless you use something like StrPtr to pass the
>address of the Unicode data.

I hadn't considered that.

>
>> I suppose the slowest step would probably be writing
>> these strings to file rather than
>> memory management of even large strings.
>
>Amen to that!

Any suggestions on how best to write to file? i.e., is it
better to concatenate a large string and write that rather than
writing separate small string?? Is there a optimal string
length to write at a time?

Cheers,

Brian
>
>Jonathan
>
>
>

click the "create symbolic debug info" in the compile options and do a standard debug, VC++ is perfectly fine for this.

Oren

p.s. Since you can't exactly call int's from your vb code, <sob>, :o), you can use the DebugBreak api call to force the default
system debugger to be called

click the "create symbolic debug info" in the compile options and do a standard debug, VC++ is perfectly fine for this.

Oren

p.s. Since you can't exactly call int's from your vb code, <sob>, :o), you can use the DebugBreak api call to force the default
system debugger to be called

Brian,

> Yes. that sounds like a better option. I should probably learn
> how to do that, but until now have only been programming with
> standard C++ features.

Like I said, we do this type of thing all the type for ourselves and various
clients.

> Any suggestions on how best to write to file? i.e., is it
> better to concatenate a large string and write that rather than
> writing separate small string?? Is there a optimal string
> length to write at a time?

Disk access is always slow. For the most part, any code that must be as fast
as possible will not include disk access. There are times where the data is
organized in such a way that it can be written in a large chunk without a
bunch of conversions. But for many cases, the benefits do not justify
worrying about it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com