Re: Moving from C++ to VC++

On Thu, 02 Jun 2005 15:44:06 -0400, NoName <anon@xxxxxxxxxxxxxx>
wrote:

>Hi all.
>Are there any good web tutorials that teach how to make this move? I
>don't necessarily need to know MFC inside and out, as MSDN is
>sufficient for that. Code conventions, MS typedef's that should be
>used (DWORD for example), and other things that accomplish the same
>thing in C++ but in VC++ style. I'm a good C++ coder, but my VC++ apps
>seem to be lacking when I peruse the code presented in this NG. Any
>help is very much appreciated.

My opinion (having programmed for 35 years, in C for 25 years, in C++
for 12, and on MS platforms since Windows 1.0):

Programming for windows depends on the Windows framework, which is
full of historical and hysterical requirements and guidelines,
including word size and pointer size. I would class Hungarian notation
-- warts -- as hysterical, and LP (for long [far] pointer, designed
for the original x86 segmented architecture) as historical and
obsolete.

Your knowledge of C++ will serve you well, as long as you are familiar
with any other framework for extensive programming on any platform.
Any typedefs or defines useful for a other platforms or projects are
congruous to the DWORDs, PSTRs, etc. of Windows.

Use the Browse ability of the IDE to find the definition for things
you don't understand.

For example, DWORD translates to 'unsigned long', which is a 32-bit
integer on all Win32/Win64 platforms. Likewise, PSTR translates to
'char *'.

This level of abstraction seemed useful to MS in the dark ages; as
examples, on Win 1-3.x, WPARAM was WORD was unsigned int (16-bit),
while LPARAM was unsigned long (32-bit). This was an attempt to
provide simple upward compatibility for systems that did not yet
exist, and thus was fraught with gotchas when that new system actually
was created (NT)! [WPARAM became 32 bits, and some changes were
required for parsing WPARAM and LPARAM for some messages.]

(At heart, Windows UI uses message-passing with specific and
fixed-size parameters for each message.)

Likewise, moving to 64-bit Windows will require a lot of things;
pointers are no longer 32 bits, and cannot be passed in 32-bit
variables in messages. Thus, MS created DWORD_PTR, which is actually
64 bits. IIRC, LPARAM is equivalent to DWORD_PTR on Win64.

Microsoft's attempts to make hardware changes transparent to
applications have failed to some degree, but are still useful. It may
take a while, but with a bit of experience, you will be able to switch
back and forth between "pure" C or C++ and Microsoft's uses.

C example: Newer abstractions include TCHAR availability. Depending on
compiler settings and includes, a TCHAR may be a simple char or a
wchar_t (likewise, PTSTR is either a char * or a wchar_t *). IMO,
LPTSTR is useless; the L is meaningless and I don't use it -- it's a
holdover from 16-bit Windows.

For such character-oriented functions, MS supplies ANSI (strcpy),
multi-byte (_mbcscpy) and Unicode (wcscpy) functions. But by including
<tchar.h>, you can call _tcscpy and it will work properly depending on
the compiler setting for text characters. I find this quite useful: it
avoids numerous places in my application where I would have to check
(#ifdef) the character mode to determine the correct function to call.
Of course, I have a need for this -- my application must run on both
Unicode (NT/2K/XP) and non-Unicode (Win9x) systems.

I believe C++ text handling is handled similarly, though I am less
familiar with it.

With regard to the latest versions of VC+, I would opine that managed
VC++NET is instead a new language: it's something other than C++,
created mostly by Microsoft. It requires significant compiler changes,
and seems mainly designed to prevent shitty programmers -- now a dime
a dozen -- from making simple errors, such as null pointer exceptions,
buffer overflows and security breaches.

PS. COM sucks. Anything.NET sucks worse.

PPS. Comments welcome. I've been wrong before, I'll be wrong again,
and I welcome dissenting opinions and lively discussions.

--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.
.