Home > Archive > VC Language > June 2005 > Moving from C++ to VC++
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Moving from C++ to VC++
|
|
| NoName 2005-06-02, 8:59 pm |
| 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.
Thanks,
Mike
| |
| andré m.a 2005-06-03, 3:59 am |
|
"NoName"
> 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.
>
> Thanks,
> Mike
There's plenty of info here ;
http://support.microsoft.com/ph/3003
The MSDN library that ships with VS6 is helpfull as well.
| |
| Guido Stercken-Sorrenti [MVP VC++] 2005-06-04, 4:02 am |
| > Moving from C++ to VC++
I see some confusion here. C++ is a language. VC++ is a product (a C++
compiler which comes along with an IDE, a linker, a resource editor and much
else). So that's not really a "move", it's just a tool you use to write and
compile C++ code. "Moving from C++ to VC++" sounds like "moving from text to
MS Word".
> I don't necessarily need to know MFC inside and out, as MSDN is
> sufficient for that.
MFC is a different story - MFC is a class library which wraps parts of the
Win32 API. However, you can use VC++ to write code without MFC, and you can
use MFC without VC++.
> 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.
Now you're asking about something else: Developing code for Windows
platforms (using the Win32 SDK). The Win32 SDK is basically a collection of
APIs which can theoretically be called from any language (although it's
tailored to C). Again, it has nothing to do with "C++ vs. VC++" - you can,
in theory, download the Windows SDK and use any C/C++ compiler you like to
create applications for the Windows platform.
> I'm a good C++ coder, but my VC++ apps
> seem to be lacking when I peruse the code presented in this NG.
That sounds like you're proficient with the C++ language, but have no
experience so far with Win32 development. It's not so much a matter of VC++
(again, it's just a tool) but rather of knowing the special requirements of
a multitasked, multithreaded, message-based multi-window GUI system. I would
recommend reading Charles Petzold's "Programming Windows" (5th Edition) to
get into the subject. After that, you will see how the Visual C++
environment helps you developing Windows apps, and especially how MFC can
save from writing tons of boilerplate code.
--
Guido Stercken-Sorrenti
MVP - Visual Developer / Visual C++
| |
| andré m.a 2005-06-04, 4:02 am |
|
> I see some confusion here. C++ is a language. VC++ is a product (a C++
> compiler which comes along with an IDE, a linker, a resource editor and
> much else). So that's not really a "move", it's just a tool you use to
> write and compile C++ code. "Moving from C++ to VC++" sounds like "moving
> from text to MS Word".
the title is the reason for the confusion.
but the message he wrote clearly indicates his needs
wich as far as im concerned are not confusing at all.
| |
| Severian [MVP] 2005-06-04, 8:58 am |
| On Thu, 02 Jun 2005 15:44:06 -0400, NoName <anon@reply.to.group>
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.
| |
| Alan J. McFarlane 2005-06-04, 8:58 am |
| In article news:m4ou9197nma0urh9vjqd4ch2hgla939ojd@
4ax.com, NoName
wrote:
> 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
Well, for Win32 Types and Header files usage see the following.
http://msdn.microsoft.com/library/e..._start_page.asp
is a good area to read. For instance there's a list of all the data
types at
http://msdn.microsoft.com/library/e..._data_types.asp
e.g.
* DWORD
32-bit unsigned integer.
This type is declared in WinDef.h as follows:
typedef unsigned long DWORD;
*LPCTSTR
An LPCWSTR if UNICODE is defined, an LPCSTR otherwise.
This type is declared in WinNT.h as follows:
#ifdef UNICODE
typedef LPCWSTR LPCTSTR;
#else
typedef LPCSTR LPCTSTR;
#endif
* LPCWSTR
Pointer to a constant null-terminated string of 16-bit Unicode
characters. For more information, see Character Sets Used By Fonts.
This type is declared in WinNT.h as follows:
typedef CONST WCHAR *LPCWSTR;
It however doesn't discuss the WIN32_LEAN_AND_MEAN #define, but see
some words on that at:
http://msdn.microsoft.com/library/e...
iles.asp
And there's no discussion of the UNICODE #define, such as at:
http://msdn.microsoft.com/library/e...nicode_28c3.asp
http://msdn.microsoft.com/library/e...nicode_8zzn.asp
http://msdn.microsoft.com/library/e...nicode_1cmr.asp
Nor does it reference anything on the _UNICODE #define, such as at:
http://msdn.microsoft.com/library/e...ing_Summary.asp
http://msdn.microsoft.com/library/e...xt_mappings.asp
I'd recommend all three are set in all projects.
> 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.
>
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.
| |
| Victor Bazarov 2005-06-05, 3:58 am |
| Severian [MVP] wrote:
> [...]
> For example, DWORD translates to 'unsigned long', which is a 32-bit
> integer on all Win32/Win64 platforms.
'long' is 32 bits on a 64-bit platform? Wow... No, really? I am
blown away, honestly.
>[...]
| |
| Carl Daniel [VC++ MVP] 2005-06-05, 3:58 am |
| Victor Bazarov wrote:
> Severian [MVP] wrote:
>
> 'long' is 32 bits on a 64-bit platform? Wow... No, really? I am
> blown away, honestly.
On 64 bit Windows, yes. Many 64-bit *nix's chose to make long be 64 bits.
This decision was based on a survey of several million lines of code that
revealed that a great deal more code would be broken by chanigng long to 64
bits than would benefit from the change.
-cd
| |
| Severian [MVP] 2005-06-05, 3:58 am |
| On Sat, 4 Jun 2005 20:42:10 -0400, "Victor Bazarov"
<v.Abazarov@comAcast.net> wrote:
>Severian [MVP] wrote:
>
>'long' is 32 bits on a 64-bit platform? Wow... No, really? I am
>blown away, honestly.
Unusually, yes. So many people have used long, LONG or ULONG to refer
to 32-bit ints that MS chose this path.
Personally, I would prefer a more logical approach.
But I'm not MS!
>
--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.
| |
| andré m.a 2005-06-06, 3:59 am |
|
Woudnt it be more efficient for a 64 bit CPU to utilize
64 bit instruction rather then 32 ? I guess it would depend
on the CPU. For exemple the old P200 PRO was much
slower running 16 bit code rather then 32.
| |
| Carl Daniel [VC++ MVP] 2005-06-06, 3:59 am |
| andré m.a wrote:
> Woudnt it be more efficient for a 64 bit CPU to utilize
> 64 bit instruction rather then 32 ? I guess it would depend
> on the CPU. For exemple the old P200 PRO was much
> slower running 16 bit code rather then 32.
Not with current 64-bit CPUs. Access to an aligned 64-bit word and an
aligned 32-bit word most likely take the same amount of time, as are most
likely the execution times for logic/arithmetic operations.
-cd
| |
|
|
| Simon Trew 2005-06-07, 3:58 am |
| "andré m.a" <a.m.a@videotron.ca> wrote in message
news:2xPoe.25888$Ab4.352954@weber.videotron.net...
>
> Woudnt it be more efficient for a 64 bit CPU to utilize
> 64 bit instruction rather then 32 ? I guess it would depend
> on the CPU. For exemple the old P200 PRO was much
> slower running 16 bit code rather then 32.
It would depend partly on the width of the memory bus. Remember the 8088
only had an 8-bit memory bus (that's the last 8 in 8088), so 16-bit
instructions would require two memory fetches (back in those days, memory
fetches were relatively slow, like, um, they are now). If a 64-bit processor
were coupled with a 32-bit bus, that would still generally produce the same
effect. I guess they learned their lesson, though.
But apparently 32-bit apps generally get a small speedup (for the same
processor clock speed) when they ru on 64-bit systems due to other factors
(more stuff in the level 2 cache, generally reduced clock cycles per
instruction, etc).
S.
| |
| Hendrik Schober 2005-06-07, 4:05 pm |
| Carl Daniel [VC++ MVP] <cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote:
> Victor Bazarov wrote:
> [...]
>
> On 64 bit Windows, yes. Many 64-bit *nix's chose to make long be 64 bits.
>
> This decision was based on a survey of several million lines of code that
> revealed that a great deal more code would be broken by chanigng long to 64
> bits than would benefit from the change.
Good approach, really. Everybody played it
stupid, so we just adapt to stupidity.
Honestly, what will do we do when 128bit
processors come? Keep 'long' at 32bit, just
because it's been this way for decades???
(Can you tell that this attitude to value
the past over the future is really getting
on my nerves?)
> -cd
Schobi
--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
| |
| William DePalo [MVP VC++] 2005-06-07, 4:05 pm |
| "Hendrik Schober" <SpamTrap@gmx.de> wrote in message
news:uiZ0Jf2aFHA.2876@TK2MSFTNGP09.phx.gbl...
> (Can you tell that this attitude to value
> the past over the future is really getting
> on my nerves?)
Yup, its a point a view that favors pragmatism over esthetics.
IMO, small fry. like, say Apple, can ignore backwards compatibility as they
did yesterday, but the big guns like MS and Intel have no choice.
Regards,
Will
| |
| Victor Bazarov 2005-06-07, 4:05 pm |
| William DePalo [MVP VC++] wrote:
> "Hendrik Schober" <SpamTrap@gmx.de> wrote in message
> news:uiZ0Jf2aFHA.2876@TK2MSFTNGP09.phx.gbl...
>
>
>
> Yup, its a point a view that favors pragmatism over esthetics.
>
> IMO, small fry. like, say Apple, can ignore backwards compatibility as they
> did yesterday, but the big guns like MS and Intel have no choice.
Bullshit. They have a choice. They just need to apply some brain and
think a bit harder how to make it work. They _choose_ not to.
| |
| Bo Persson 2005-06-07, 4:05 pm |
|
"Hendrik Schober" <SpamTrap@gmx.de> skrev i meddelandet
news:uiZ0Jf2aFHA.2876@TK2MSFTNGP09.phx.gbl...
> Carl Daniel [VC++ MVP]
> <cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote:
>
> Good approach, really. Everybody played it
> stupid, so we just adapt to stupidity.
> Honestly, what will do we do when 128bit
> processors come? Keep 'long' at 32bit, just
> because it's been this way for decades???
Sure, we now have long for 32 bits, and long long for 64 bits. Next time
it will be long long long, of course, meaning normal size.
>
> (Can you tell that this attitude to value
> the past over the future is really getting
> on my nerves?)
Never remove anything, just add more features. :-)
Bo Persson
| |
| Hendrik Schober 2005-06-08, 9:00 am |
| William DePalo [MVP VC++] <willd.no.spam@mvps.org> wrote:
> "Hendrik Schober" <SpamTrap@gmx.de> wrote in message
> news:uiZ0Jf2aFHA.2876@TK2MSFTNGP09.phx.gbl...
>
> Yup, its a point a view that favors pragmatism over esthetics.
That's not a question of esthetics, really.
In ten years from now, I will have a lot
more code written after today then before.
/That's/ why I'd rather have tools support
the code I write within the next ten years
even if that makes it a bit harder to keep
the code of the last ten years.
I still have quite a while to hack until
retirement. There will eb a lot more code
ahead of me than there is behind me. The
same goes for the company I work for. So
the future is ultimately more important to
me than the past.
And the same attitude is used regarding
standard C++: Never ever break backwards
compatibility, at the expense of forward
compatibility. Call me unpatient, but I
need to be compatible with the future more
than with the past.
> [...]
> Will
Schobi
--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
| |
| William DePalo [MVP VC++] 2005-06-08, 4:02 pm |
| "Hendrik Schober" <SpamTrap@gmx.de> wrote in message
news:%23sd2V9AbFHA.2668@TK2MSFTNGP12.phx.gbl...
>
> That's not a question of esthetics, really.
> In ten years from now, I will have a lot
> more code written after today then before.
> /That's/ why I'd rather have tools support
> the code I write within the next ten years
> even if that makes it a bit harder to keep
> the code of the last ten years.
I get it. I'm sure _that_ they get it in Redmond, too.
What I don't think that you get is that there are tens of millions of lines
of code in an operating system and assorted servers and services and drivers
and applications in Redmond that need to be ported. Now comes the choice:
widen the types in the canonical way and delay the port or take some short
cuts and ship an operating system. _They_ mad the right choice.
> Call me unpatient, but I
> need to be compatible with the future more
> than with the past.
Huh? More compatible with that which does not exist than that which does?
Seems patently untrue on its face to me.
Regards,
Wukk
| |
| Carl Daniel [VC++ MVP] 2005-06-08, 4:02 pm |
| Hendrik Schober wrote:
> Carl Daniel [VC++ MVP]
> <cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote:
>
> Good approach, really. Everybody played it
> stupid, so we just adapt to stupidity.
> Honestly, what will do we do when 128bit
> processors come? Keep 'long' at 32bit, just
> because it's been this way for decades???
>
> (Can you tell that this attitude to value
> the past over the future is really getting
> on my nerves?)
The fact is, very few applications will ever need to use a 64-bit integer
type, even fewer will need a 128-bit integer. Breaking compatibility with
untold scores of current programs to favor those very few future programs
that need the larger type just doesn't make sense. Those few programs that
do need that large integer size can simply use __int64 (or int_t<64>, or
whatever other new integer types we may see in C++ in the future).
The legitimate, common uses I can see for a 64 bit integer type involve
representation of values of or differences between 64 bit pointers, and we
have size_t and prtdiff_t for that (and yes, they're both 64 bits on 64 bit
Windows).
-cd
| |
| Hendrik Schober 2005-06-09, 9:00 am |
| Carl Daniel [VC++ MVP] <cpdaniel_remove_this_and_nospam@mvps.org.nospam> wrote:
> [...]
> The fact is, very few applications will ever need to use a 64-bit integer
> type, even fewer will need a 128-bit integer. Breaking compatibility with
> untold scores of current programs to favor those very few future programs
> that need the larger type just doesn't make sense. Those few programs that
> do need that large integer size can simply use __int64 (or int_t<64>, or
> whatever other new integer types we may see in C++ in the future).
>
> The legitimate, common uses I can see for a 64 bit integer type involve
> representation of values of or differences between 64 bit pointers, and we
> have size_t and prtdiff_t for that (and yes, they're both 64 bits on 64 bit
> Windows).
One would assume (that is, I would anyway) the
native integer size on a 64bit platform to be
64bit. AFAIK, according to the C/C++ standards,
even 'int' should be 64bit then. I agree that
the usefulness of this is at least debatable.
(Even though I would prefer 'int' to be the
native integer type of the platform. If you need
less than that, use 'short' or 'int32_t' or
whatever.)
But I really don't see any excuse for not making
'long' 64bit on a 64bit platform.
> -cd
Schobi
--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
| |
| Hendrik Schober 2005-06-09, 9:00 am |
| William DePalo [MVP VC++] <willd.no.spam@mvps.org> wrote:
> "Hendrik Schober" <SpamTrap@gmx.de> wrote in message
> news:%23sd2V9AbFHA.2668@TK2MSFTNGP12.phx.gbl...
>
> I get it. I'm sure _that_ they get it in Redmond, too.
I'm not.
> What I don't think that you get is that there are tens of millions of lines
> of code in an operating system and assorted servers and services and drivers
> and applications in Redmond that need to be ported. Now comes the choice:
> widen the types in the canonical way and delay the port or take some short
> cuts and ship an operating system. _They_ mad the right choice.
Why not include a switch for backwards
compatibiliy? Yeah, I know, there's those
switch haters. So what? If I need to compile
code that errornously makes wrong assumptions
about some types I'd be happy to throw a
switch if this let's me get away without
porting 1MLOC.
And all others aren't bothered with this.
>
> Huh? More compatible with that which does not exist than that which does?
> Seems patently untrue on its face to me.
FWIW, we're talking of code that gets written
/now/, not in ten years.
Also I've run into enough problems because of
developers who didn't clean up their mess for
years. It will bite back, it it will do worse
the longer you try to hack around it.
> Regards,
> Wukk
Schobi
--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
| |
| Doug Harrison [MVP] 2005-06-09, 4:02 pm |
| On Thu, 9 Jun 2005 09:23:35 +0200, Hendrik Schober wrote:
> One would assume (that is, I would anyway) the
> native integer size on a 64bit platform to be
> 64bit. AFAIK, according to the C/C++ standards,
> even 'int' should be 64bit then. I agree that
> the usefulness of this is at least debatable.
> (Even though I would prefer 'int' to be the
> native integer type of the platform. If you need
> less than that, use 'short' or 'int32_t' or
> whatever.)
The main argument for int reflecting the "native" word size has been
efficiency. Anyone know how well these 64 bit CPUs implement 32 bit data
types?
> But I really don't see any excuse for not making
> 'long' 64bit on a 64bit platform.
Portable code can't assume long is larger than 32 bits. If you care about
anything beyond the minimum sizes, you have no business using the native
types. I know we all violated that with int and 32 bit platforms, but times
change. I can't remember the last time I wrote "long" on a 32 bit platform,
where I know int is 32 bits, and long is the same size. Well, that's not
entirely true. Like a lot of people, I assumed size_t would fit in an
unsigned long when using printf and friends and cast accordingly. That
assumption does fail in Win64, but hopefully the compiler will warn about
the possible (very rare) truncation.
--
Doug Harrison
Microsoft MVP - Visual C++
| |
| Bo Persson 2005-06-09, 4:02 pm |
|
"Doug Harrison [MVP]" <dsh@mvps.org> skrev i meddelandet
news:wpshvx62gqed.en6auc4oe3pr.dlg@40tude.net...
> On Thu, 9 Jun 2005 09:23:35 +0200, Hendrik Schober wrote:
>
>
> The main argument for int reflecting the "native" word size has been
> efficiency. Anyone know how well these 64 bit CPUs implement 32 bit
> data
> types?
On the x64 hardware, 32 bit int *is* the natural size. You need a size
override code to operate on 64 bit data.
That doesn't say that we need long as another 32 bit type, though. :-)
>
>
> Portable code can't assume long is larger than 32 bits. If you care
> about
> anything beyond the minimum sizes, you have no business using the
> native
> types. I know we all violated that with int and 32 bit platforms, but
> times
> change. I can't remember the last time I wrote "long" on a 32 bit
> platform,
> where I know int is 32 bits, and long is the same size. Well, that's
> not
> entirely true. Like a lot of people, I assumed size_t would fit in an
> unsigned long when using printf and friends and cast accordingly. That
> assumption does fail in Win64, but hopefully the compiler will warn
> about
> the possible (very rare) truncation.
>
The absurdity here is that you cannot even write portable code at all,
since there is now *no* 64 bit standard type available on some 64 bit
systems. You have to use __int64, or long long, or borrow int64_t from
C99. None of this is Standard C++, but extensions!
Bo Persson
| |
| Hendrik Schober 2005-06-10, 8:59 am |
| Doug Harrison [MVP] <dsh@mvps.org> wrote:
> [...]
>
> Portable code can't assume long is larger than 32 bits.
By the same resoning, it can't assume 'long' to
be 32bits. Yet this was named as the reason for
'long' being 32bits on a 64bits platform.
> If you care about
> anything beyond the minimum sizes, you have no business using the native
> types. I know we all violated that with int and 32 bit platforms [...]
I don't think I have ever assumed anything about
any of the integer type except for small (100LOC)
toy programs. (I might have accidently done this,
but then I'd be happy to have my nose pointed at
it.)
> [...] I can't remember the last time I wrote "long" on a 32 bit platform,
> where I know int is 32 bits, and long is the same size. Well, that's not
> entirely true. Like a lot of people, I assumed size_t would fit in an
> unsigned long when using printf and friends and cast accordingly. [...]
I haven't done any of those either.
Maybe that's because I started to work for a
company where all code gets ported to a couple
of platform shortly after starting to work in
this field at all. That teaches a lot about
what you can assume and what you can't.
Schobi
--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
| |
| Doug Harrison [MVP] 2005-06-10, 4:03 pm |
| On Fri, 10 Jun 2005 10:20:34 +0200, Hendrik Schober wrote:
>
> By the same resoning, it can't assume 'long' to
> be 32bits. Yet this was named as the reason for
> 'long' being 32bits on a 64bits platform.
The 32 bit long choice for Win64 was a consideration for backward
compatibility, not some abstract notion of portability. My comment was
directed to purists who don't care about invalidating existing code.
Clearly, such a person shouldn't care what size long is, as long as it
satisfies the requirements for long. In the message I replied to, you
pretty much conceded that 32 bits were OK, but then you went on to say that
you "don't see any excuse for not making 'long' 64bit on a 64bit platform."
When I put on my purist cap, if I accept 32 bit ints, I don't see any
particular reason to _make_ long 64 bits on a 64 bit platform, because a 32
bit long is all that's required.
> I don't think I have ever assumed anything about
> any of the integer type except for small (100LOC)
> toy programs. (I might have accidently done this,
> but then I'd be happy to have my nose pointed at
> it.)
>
> I haven't done any of those either.
>
> Maybe that's because I started to work for a
> company where all code gets ported to a couple
> of platform shortly after starting to work in
> this field at all. That teaches a lot about
> what you can assume and what you can't.
I guess you're more a purist than the rest of us. Or at least you think you
are. :) Statements like this one from your last post make me wonder:
[color=darkred]
There's no guarantee short is smaller than int, and we're back to what I
said about portable code and minimum sizes. Not to mention, your "no
excuse" comment about 64 bit longs suggests you might use it non-portably
if it were available to you. I mean, if you're such a portable guy, why
would you even care about this?
There are many subtle ways non-portable assumptions creep into code. Here's
one. In your 32 bit programming, if you've ever used int to represent a
size, index, or anything having to do with capacity in a data structure,
loop index, etc, and your users can reasonably expect to work with data
sets containing more than 32,767 items, you might have been non-portable.
Here's another. If you've ever written code that cannot work in a 16 bit
(non-VM) address space, perhaps due to large auxiliary data structures it
needs to function, you might have been non-portable.
--
Doug Harrison
Microsoft MVP - Visual C++
|
|
|
|
|