Re: General Question: CString vs LPTSTR & LPCTSTR
- From: Goran <goran.pusic@xxxxxxxxx>
- Date: Thu, 13 May 2010 23:47:43 -0700 (PDT)
On May 14, 3:04 am, "JCO" <some...@xxxxxxxxxxxxx> wrote:
It really sounds like (for MFC) it's better to completely stay away from
LPCTSTR & TCHAR.
Pretty much, yeah. At any rate, whenever you have a CString, and you
interact with a C API that has C string parameter, you'll either go
through directly through CString's "C string" conversion operators
(see operator PCXSTR in CString), or you will be forced to use one of
"buffer" routines for non-const params.
Use CString, CString& or similarly with the "const" in front for Read Only.
Yes. It's not "Read only", it's more "input", really. Normally, you
really rarely want to use plain CString. You want that when you want
to pass it as an input (by value), and you want to modify it inside,
e.g. (warning: hugely contrived example):
void f(CString s)
if (whatever) s = val1; else s = val2;
But that's just the same as:
void f(const CString& s)
if (whatever) local = val1; else local = val2;
(BTW, I bet you that you won't be able to see performance difference
in an optimized build between the two versions, and it's even possible
that compiler will compile the two to the exact same code).
As Joe said, using const for "input" parameters has a good
"documentation" value. I wonder if this will ever become a part of
typical coding guidelines for C and C++ (it should have, by now, but C
is an old language, and if it still isn't there for C code, so chances
of that ever happening are slim).
- Prev by Date: Re: Newcomer's CAsyncSocket example: trouble connecting with other clients
- Next by Date: Re: MiniDumpWriteDump(...) now showing 'local' variables
- Previous by thread: Re: General Question: CString vs LPTSTR & LPCTSTR
- Next by thread: Re: General Question: CString vs LPTSTR & LPCTSTR