Prev: Expand max. status bar pane text length?
Next: MiniDumpWriteDump(...) now showing 'local' variables
From: JCO on 13 May 2010 20:32
Whats the purpose of passing a "const CString &"?
I will read the article.. thanks
Any reason why you would prefer to use "const TCHAR" over "const CString &"
in your function parameters?

"Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message
news:#y804je8KHA.5900(a)TK2MSFTNGP04.phx.gbl...
> "JCO" <someone(a)somewhere.com> ha scritto nel messaggio
> news:ux4k3Be8KHA.2248(a)TK2MSFTNGP05.phx.gbl...
>
>> As I get back into MFC Coding, I'm reminded of the different data types
>> that can be used for proper & efficient coding. Generally, I see
>> functions that use LPTSTR & LPCTSTR. I'm wondering why the CString is
>> not used as much as a parameter. If you pass "CString &", of course, it
>> would be efficient as compared to passing the entire CString class.
>
> The equivalence would be between LPCTSTR (i.e. 'const TCHAR *') and 'const
> CString &'.
>
> If you pass strings as read-only parameters to a function or method, I
> would suggest to use LPCTSTR (i.e. 'const TCHAR *').
> This way, you could pass both a string literal (without creating a new
> temporary instance of CString) and a CString instance (in fact, there is
> an implicit LPCTSTR conversion operator defined for the CString class).
>
> Instead, if you want to pass modifyable string parameters, then I would
> suggest to use 'CString &'.
>
> If you return a string from a function or a method, I would suggest to
> just pass an instance of CString.
>
> e.g.
>
> CString DoSomethingAndReturnString(
> LPCTSTR psz // [input] const TCHAR *
> CString & str // [input/output] reference to CString
> );
>
>
>> I'm confused as to why these seem to be the most popular parameter types.
>
> You may want to read:
>
> CString Argument Passing
> http://msdn.microsoft.com/en-us/library/acttytz3(v=VS.80).aspx
>
>
> Giovanni
>
>
>
From: JCO on 13 May 2010 21:00
Yes I saw that. Thanks

"Hector Santos" <sant9442(a)gmail.com> wrote in message
news:hsgbb3$1epm$1(a)news.ett.com.ua...
> I think a key point for the OP to understand that I didn't see pointed out
> is that the CString object has a LPCTSTR (const char *) overload operator
> to return a pointer to the CString internal asciiz string (null terminated
> string) buffer.
>
> --
> HLS
>
> Joseph M. Newcomer wrote:
>
>> It is a popular parameter type because it is "POD" (Plain Old Data).
>> Therefore, functions
>> that use LPCTSTR can be used by both C callers and C++ callers. If you
>> are in MFC,
>> Giovanni has already pointed out the issues, which is you really want to
>> use const
>> CString& most of the time. Remember that a lot of the people writing
>> this code learned to
>> write C code first and never outgrew the bad habits they developed then.
>> But the API
>> calls use LPCTSTR because they have to be compatible with C programmers
>> as well.
>>
>> You should never pass a parameter as non-const if it is never modified.
>> The const
>> qualifier helps users identify if the string passed will be modified or
>> not, and also the
>> compiler can produce slightly better code if a const is involved. But
>> the documentation
>> value of const is far more important.
>> joe
>>
>> On Wed, 12 May 2010 09:36:09 -0500, "JCO" <someone(a)somewhere.com> wrote:
>>
>>> As I get back into MFC Coding, I'm reminded of the different data types
>>> that can be used for proper & efficient coding. Generally, I see
>>> functions that use LPTSTR & LPCTSTR. I'm wondering why the CString is
>>> not used as much as a parameter. If you pass "CString &", of course, it
>>> would be efficient as compared to passing the entire CString class.
>>>
>>> My understanding it that
>>> LPSTR == char*
>>> LPCSTR == const char*
>>>
>>> Then you can throw your "T" in for Unicode conversion.
>>> LPTSTR == LPWSTR or LPSTR
>>> LPCTSTR == LPCWSTR or LPCSTR
>>>
>>> I'm confused as to why these seem to be the most popular parameter
>>> types. Typically I convert these types to a local CString in a function
>>> .. .then do my work. Is this okay?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
From: JCO on 13 May 2010 21:04
It really sounds like (for MFC) it's better to completely stay away from
LPCTSTR & TCHAR.
Use CString, CString& or similarly with the "const" in front for Read Only.

"Goran" <goran.pusic(a)gmail.com> wrote in message
news:ca32288f-04d8-49e3-8b20-ff460f304ce3(a)n15g2000yqf.googlegroups.com...
> On May 12, 4:36 pm, "JCO" <some...(a)somewhere.com> wrote:
>> As I get back into MFC Coding, I'm reminded of the different data types
>> that
>> can be used for proper & efficient coding. Generally, I see functions
>> that
>> use LPTSTR & LPCTSTR. I'm wondering why the CString is not used as much
>> as
>> a parameter. If you pass "CString &", of course, it would be efficient
>> as
>> compared to passing the entire CString class.
>
> That is correct. In context of MFC it is normally a major performance
> fault to pass LPCTSTR around, because of e.g. this:
>
> f(LPCTSTR param)
> {
> CString s(param); // Allocation!
> // or similar use.
> }
>
> CString s = ...;
> f(s);
>
> Compare this to:
> f(const CString& param)
> {
> CString s(param); // NO ALLOCATION, I win.
> }
>
> CString s = ...;
> f(s);
>
> In other words, one should use LPCTSTR only when sure that it will not
> be converted to a CString, or somehow mixed with one, somewhere down
> the line. And that's typically a tall order.
>
> Goran.

From: Joseph M. Newcomer on 13 May 2010 23:27
See below...
On Thu, 13 May 2010 19:32:18 -0500, "JCO" <someone(a)somewhere.com> wrote:

>Whats the purpose of passing a "const CString &"?
>I will read the article.. thanks
>Any reason why you would prefer to use "const TCHAR" over "const CString &"
>in your function parameters?
****
I presume you mean "const TCHAR *", because "const TCHAR" is a simple scalar value which
is nominally sizeof(TCHAR) but is more likely 32 bits because of how parameters are
passed.

But a const TCHAR * can accept any constant string pointer, whereas "const CString &" can
only accept a CString. So if you pass _T("abc"), it will actually call the CString
constructor to create a CString object to pass in.

When I'm programming in MFC, I almost never have a data type OTHER than CString, so I tend
to use const CString & when I'm working within my native framework. I rarely have a raw
string literal in such cases, and in the extremely rare cases I do, I don't really care
about the constructor cost.
joe

>
>"Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message
>news:#y804je8KHA.5900(a)TK2MSFTNGP04.phx.gbl...
>> "JCO" <someone(a)somewhere.com> ha scritto nel messaggio
>> news:ux4k3Be8KHA.2248(a)TK2MSFTNGP05.phx.gbl...
>>
>>> As I get back into MFC Coding, I'm reminded of the different data types
>>> that can be used for proper & efficient coding. Generally, I see
>>> functions that use LPTSTR & LPCTSTR. I'm wondering why the CString is
>>> not used as much as a parameter. If you pass "CString &", of course, it
>>> would be efficient as compared to passing the entire CString class.
>>
>> The equivalence would be between LPCTSTR (i.e. 'const TCHAR *') and 'const
>> CString &'.
>>
>> If you pass strings as read-only parameters to a function or method, I
>> would suggest to use LPCTSTR (i.e. 'const TCHAR *').
>> This way, you could pass both a string literal (without creating a new
>> temporary instance of CString) and a CString instance (in fact, there is
>> an implicit LPCTSTR conversion operator defined for the CString class).
>>
>> Instead, if you want to pass modifyable string parameters, then I would
>> suggest to use 'CString &'.
>>
>> If you return a string from a function or a method, I would suggest to
>> just pass an instance of CString.
>>
>> e.g.
>>
>> CString DoSomethingAndReturnString(
>> LPCTSTR psz // [input] const TCHAR *
>> CString & str // [input/output] reference to CString
>> );
>>
>>
>>> I'm confused as to why these seem to be the most popular parameter types.
>>
>> You may want to read:
>>
>> CString Argument Passing
>> http://msdn.microsoft.com/en-us/library/acttytz3(v=VS.80).aspx
>>
>>
>> Giovanni
>>
>>
>>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Goran on 14 May 2010 02:47
On May 14, 3:04 am, "JCO" <some...(a)somewhere.com> 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;
someOtherFunc(s);
}

But that's just the same as:

void f(const CString& s)
{
CString local(s)
if (whatever) local = val1; else local = val2;
someOtherFunc(s);
}

(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).

Goran.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Expand max. status bar pane text length?
Next: MiniDumpWriteDump(...) now showing 'local' variables