Prev: Expand max. status bar pane text length?
Next: MiniDumpWriteDump(...) now showing 'local' variables
From: Hector Santos on 14 May 2010 03:13
JCO wrote:

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


Yes, if you wish to ignore any performance lost due to the extra
overhead. But today's computers are fast so who cares? :)

But the other thing is issues may rear its ugly head when you are
passing it across boundaries, like between the exe and dlls.

For example, if you put your functions in a DLL, now they are highly
dependent on MFC being included in the DLL when it might have to be if
you are using passing a const string pointer and can work with it with
out needing the help from CString member functions.

You shouldn't have problems but you have to keep it in the back of
your mind for any heap related issues.

--
HLS
From: JCO on 14 May 2010 16:13
Got it....thanks

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:7jgpu5h5t6vkdm4iuu4k399f5vrhnr6e4j(a)4ax.com...
> 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: John H. on 14 May 2010 17:01
Goran wrote:
> On May 14, 3:04 am, "JCO" <some...(a)somewhere.com> wrote:
> > 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,

Although probably a rare case, but in a multithreaded app, the
difference between CString and CString const & could be important.
e.g.

// Global resource:
CString csName("Albert");

// Thread 1:
....
DoSomething(csName); // line 1
....

// Thread 2:
....
csName = "Alex"; // line 2
....

Now consider if DoSomething is defined as
void DoSomething(CString csFriend)
{
...
cout << csFriend<< endl; // line 3
}

Now consider line1 begins execution, and the name "Albert" is copied
into the csFriend argument. Then control switches to thread 2 and
line 2 is executed. Then control goes back to thread 1 and line 3 is
executed. "Albert" will be printed.

If on the other hand DoSomething is defined with reference:
void DoSomething(CString const & csFriend)
{
...
cout << csFriend<< endl; // line 3
}

With the same serious of executions steps, "Alex" would be printed.

Depending on what you are trying to do, either one could be the
desired behavior.
From: JCO on 14 May 2010 17:37
I certainly understand when to use CString vs CString (and conversely using
const).
My original thread pertained concerns over LPTSTR, LPCTSTR (along with
TCHAR).... I plan to avoid this if posible.
Thanks

"John H." <oldman_fromthec(a)yahoo.com> wrote in message
news:2c44a0ec-d68b-4a3a-b795-cd23c5e11ec1(a)s41g2000vba.googlegroups.com...
> Goran wrote:
>> On May 14, 3:04 am, "JCO" <some...(a)somewhere.com> wrote:
>> > 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,
>
> Although probably a rare case, but in a multithreaded app, the
> difference between CString and CString const & could be important.
> e.g.
>
> // Global resource:
> CString csName("Albert");
>
> // Thread 1:
> ...
> DoSomething(csName); // line 1
> ...
>
> // Thread 2:
> ...
> csName = "Alex"; // line 2
> ...
>
> Now consider if DoSomething is defined as
> void DoSomething(CString csFriend)
> {
> ...
> cout << csFriend<< endl; // line 3
> }
>
> Now consider line1 begins execution, and the name "Albert" is copied
> into the csFriend argument. Then control switches to thread 2 and
> line 2 is executed. Then control goes back to thread 1 and line 3 is
> executed. "Albert" will be printed.
>
> If on the other hand DoSomething is defined with reference:
> void DoSomething(CString const & csFriend)
> {
> ...
> cout << csFriend<< endl; // line 3
> }
>
> With the same serious of executions steps, "Alex" would be printed.
>
> Depending on what you are trying to do, either one could be the
> desired behavior.

From: Goran on 16 May 2010 04:12
On May 14, 11:01 pm, "John H." <oldman_fromt...(a)yahoo.com> wrote:
> Goran wrote:
> > On May 14, 3:04 am, "JCO" <some...(a)somewhere.com> wrote:
> > > 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,
>
> Although probably a rare case, but in a multithreaded app, the
> difference between CString and CString const & could be important.
> e.g.
>
> // Global resource:
> CString csName("Albert");
>
> // Thread 1:
> ...
> DoSomething(csName);  // line 1
> ...
>
> // Thread 2:
> ...
> csName = "Alex";  // line 2
> ...
>
> Now consider if DoSomething is defined as
> void DoSomething(CString csFriend)
> {
>   ...
>    cout << csFriend<< endl;  // line 3
>
> }
>
> Now consider line1 begins execution, and the name "Albert" is copied
> into the csFriend argument.  Then control switches to thread 2 and
> line 2 is executed.  Then control goes back to thread 1 and line 3 is
> executed.  "Albert" will be printed.
>
> If on the other hand DoSomething is defined with reference:
> void DoSomething(CString const & csFriend)
> {
>   ...
>    cout << csFriend<< endl;  // line 3
>
> }
>
> With the same serious of executions steps, "Alex" would be printed.
>
> Depending on what you are trying to do, either one could be the
> desired behavior.

Well, that is true, but the problem is at a much lower level: code is
attempting to read/write a shared datum from multiple threads. That
does not work in a general case. Your example just muddies the waters
and tries to apply them to a CString&.

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