for those who still create COM servers

[Egbert Nierop \(MVP for IIS\)]

Boost BSTR performance by 3000%

http://technolog.nl/eprogrammer/arch...7/25/1009.aspx

[Bronek Kozicki]

Egbert Nierop (MVP for IIS) <eg***********@nospam.invalidwrote:

Boost BSTR performance by 3000%
http://technolog.nl/eprogrammer/arch...7/25/1009.aspx

anyone willing to rewrite _bstr_t ? ;)
B.

[Egbert Nierop \(MVP for IIS\)]

"Bronek Kozicki" <br**@spamcop.netwrote in message
news:OQ**************@TK2MSFTNGP05.phx.gbl...

Egbert Nierop (MVP for IIS) <eg***********@nospam.invalidwrote:

>Boost BSTR performance by 3000%
http://technolog.nl/eprogrammer/arch...7/25/1009.aspx

anyone willing to rewrite _bstr_t ? ;)

That would be a hard task :<

I've been looking into the source, and that one looks much more dependent on
tiny subroutines, while the member functions of CComBSTR are independently
written.
Whynot just use CComBSTR instead of _bstr_t ?

in addition, CComBSTR2 also has methods like CString has (formatting), so if
you manipulate strings (in/out or retval) you even do not have to cast to
CString and BSTR back, thus again improving scalability. I only would like
someone to improve Join and Split on the CComBSTR2 class. These functions
are really slow.

[Bronek Kozicki]

Egbert Nierop (MVP for IIS) <eg***********@nospam.invalidwrote:

Whynot just use CComBSTR instead of _bstr_t ?

maybe because _bstr_t is already in your project if you use #import? Or
because it's more const-safe than CComBSTR? Or because it does simple
and nice Unicode<>ANSI conversions?
B.

[Egbert Nierop \(MVP for IIS\)]

"Bronek Kozicki" <br**@spamcop.netwrote in message
news:u0**************@TK2MSFTNGP03.phx.gbl...

Egbert Nierop (MVP for IIS) <eg***********@nospam.invalidwrote:

>Whynot just use CComBSTR instead of _bstr_t ?

maybe because _bstr_t is already in your project if you use #import? Or

that would be 500bytes extra code on your compiled project ;-)

because it's more const-safe than CComBSTR? Or because it does simple and
nice Unicode<>ANSI conversions?

Possibly. I never do Unicode <-ansi conversions since I simply never
develop for Win9x/ME :).

There are very nice ATL conversion macro's that do the task already. But
since I don't know _bstr_t for sure, I cannot speak about this.

[Bronek Kozicki]

Egbert Nierop (MVP for IIS) <eg***********@nospam.invalidwrote:

>maybe because _bstr_t is already in your project if you use #import?
Or

that would be 500bytes extra code on your compiled project ;-)

and yet another string class, with different ownership semantics than
others. Mistakes in ownership handling can be pretty expensive, if you
forget the semantics of class you use. Thus I simply do not use the ones
I do not really need.

>because it's more const-safe than CComBSTR? Or because it does
simple and nice Unicode<>ANSI conversions?

Possibly. I never do Unicode <-ansi conversions since I simply never
develop for Win9x/ME :).

I do use std::runtime_error (or actually my own classes derived from
thereof) and the problem is that it does not accept const wchar_t* :-(
B.