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.
"BobF" <nothanks(a)no.spam> wrote in message
> 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 ...
>> "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
>>>> 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
>>>> m_cs - CString
>>>> m_b - boolean
>>>> m_n - numeric type
>>>> m_p - pointer
>>>> m_c - control
>>>> 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
>>> 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
>>> 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
>>> WCHAR * pszS1 = L"Foo";
>>> BSTR bstrS2;
>>> bstrS2 = pszS1;
>>> --> wrong assignment (prefixes don't match: can't assign a BSTR from a
>>> 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
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
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
> One of the reasons HN no longer has any value whatsoever!
> 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!