Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work
From: Tom Serface on 23 Feb 2010 13:43
Yes. That's another reason to upgrade from VC6 to more recent versions. I
couldn't live without Datatips (not necessarily tooltips, but the instant
information during debugging). So many nice features.

Tom

"BobF" <nothanks(a)no.spam> wrote in message
news:egu7gBKtKHA.3904(a)TK2MSFTNGP02.phx.gbl...
>
> I find the little tooltips that pop up showing how vars are defined helps
> a bunch too!
>
>
>
> Tom Serface wrote:
>> Yeah, I guess there is no perfect method. I'm not sure how to solve that
>> debate. I guess we all have to use what means the most to us and just do
>> a lot of commenting. I've found that right clicking and selecting Go to
>> declaration is a great help ...
>>
>> Tom
>>
>> "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in
>> message news:ukvHe3GtKHA.3360(a)TK2MSFTNGP06.phx.gbl...
>>> "Tom Serface" <tom(a)camaswood.com> ha scritto nel messaggio
>>> news:e6Wytp#sKHA.4752(a)TK2MSFTNGP04.phx.gbl...
>>>
>>>> I find using some sort of indication of the variable type in the name
>>>> makes it easier for me when I read my own code. For example, I often
>>>> use:
>>>>
>>>> m_cs - CString
>>>> m_b - boolean
>>>> m_n - numeric type
>>>> m_p - pointer
>>>> m_c - control
>>>> etc.
>>>>
>>>> Not "Hungarian", but still somewhat descriptive. I would never want to
>>>> type lpstr... just too lazy.
>>>
>>> One problem of the prefixes is that they could be ambiguous...
>>> For example, I used to choose "b" prefix for BYTEs (like the Win32 SDK
>>> does).
>>>
>>> However, I think that sometimes Hungarian Notation is misinterpreted.
>>> My understanding of the *real* HN is that its intent is to help the
>>> programmer catching errors that the compiler can't catch.
>>> I'll give you a sample here:
>>>
>>> Consider a Unicode NUL-terminated string (i.e. WCHAR * or LPWSTR) and a
>>> BSTR.
>>> From the C/C++ type system point of view, a BSTR is just a LPWSTR!
>>> So, the following C++ code would compile just fine:
>>>
>>> WCHAR * s1 = L"Foo";
>>> BSTR s2;
>>> ...
>>> ...
>>> s2 = s1;
>>>
>>> But the above code is *wrong*. In fact, for example, a BSTR is length
>>> prefixed (and this condition is not met by above code); moreover, the
>>> BSTR's should be allocated using SysAllocString, etc.
>>> So, you have a C++ code that compiles but has a hidden bug in the 's2 =
>>> s1' statement.
>>>
>>> Instead, if you use proper notation, you can identify the bug reading
>>> code:
>>>
>>> WCHAR * pszS1 = L"Foo";
>>> BSTR bstrS2;
>>> ...
>>> ..
>>> bstrS2 = pszS1;
>>>
>>> --> wrong assignment (prefixes don't match: can't assign a BSTR from a
>>> LPWSTR).
>>>
>>> Another similar case is the 'cch' vs. 'cb'. Both can be integer types,
>>> but you know that one is the count of characters, the other is the count
>>> of bytes.
>>>
>>> I have mixed feelings about HN, but a properly used notation about the
>>> *semantics* of the variable (not about the raw underlying C++ type) may
>>> help.
>>>
>>> Giovanni
>>>
>>>
From: Tom Serface on 23 Feb 2010 13:45
I'm not sure it ever did have any value as a "standard". That's like trying
to standardize on where to put curly braces and how to indent. Unless
forced by some corporate mandate programmers will just use what they want
anyway.

Tom

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:do78o5h05v725ibadpehn1cu1tko8daafa(a)4ax.com...
> One of the reasons HN no longer has any value whatsoever!
> joe
>
> On Tue, 23 Feb 2010 09:53:42 -0600, BobF <nothanks(a)no.spam> wrote:
>
>>
>>I find the little tooltips that pop up showing how vars are defined
>>helps a bunch too!


First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work