From -4173385664387398747 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,9684813612e15361 X-Google-Attributes: gidf78e5,public From: David R Tribble Subject: Re: pointers: sizeof(pointer) Date: 1998/06/29 Message-ID: <35981EE8.1C2E@noSPAM.central.beasys.com>#1/1 X-Deja-AN: 367263369 X-NNTP-Posting-Host: dalnt9.beasys.com Content-Transfer-Encoding: 7bit Approved: stephen.clamage@sun.com (comp.std.c++) References: <6mkkaq$dgu@engnews1.Eng.Sun.COM> <3591A612.15DA@aristeia.com> <6mu1lq$fon@engnews1.Eng.Sun.COM> <35930246.1692@noSPAM.central.beasys.com> <35942D10.24F0@aristeia.com> X-UID: 0000000001 X-Status: $$$$ Content-Type: text/plain; charset=us-ascii Organization: File by Pile Mime-Version: 1.0 Reply-To: dtribble@technologist.com Newsgroups: comp.std.c++ Originator: clamage@taumet I, David R Tribble, dumped on M$ by writing: >> Leave it to Microsoft to come up with a different, and inherently >> worse, solution. ... Scott Meyers wrote: > I like dumping on Microsoft (or IBM or Sun or HP...) as much as > anybody, because, well, because it's fun to pick on companies. > However, I got the impression from Pietrek's article that Microsoft > made its decision based on the kinds of technical considerations Steve > described for Sun and you described for DEC. > > From Matt's article: > The second scenario for a 64-bit type model is ... leave the int as > 32 bits while using 64 bits for longs and pointers. This is the > model that 64-bit Unix implementations use. For Unix, [this] is a > good choice from the portability perspective, since most Unix APIs > use int parameters, rather than longs. Many of those 'int' parameters are cleverly disguised as typedefs (such as 'size_t', 'time_t', and 'pid_t'). > Windows, on the other hand, uses lots of types that ultimately > resolve down to a long, and hence would be 64 bits in this model. Many of those 'long' parameters are cleverly disguised as typedefs (such as 'WORD', 'DWORD', and 'LPARAM'). In fact, MOST of the Win32 API parameters are declared using typedef names; it's rare to see a regular 'int' or 'char *' in . > For this reason, a [64-bit long] Windows implementation would have > many of the same problems as the [64-bit int] model. Of course, they could easily fix it by adding something like this to their header files: #if _WIN_64BIT typedef int DWORD; #else typedef long DWORD; #endif They seem to have a history of doing this to some extent already, e.g., '#ifdef _X86_' and '#ifdef _M_ALPHA_'. > In addition, > code that currently gets away with assuming that ints and longs are > equivalent would break under [the 32-bit int, 64-bit long] model. This is true in either world (where world #1 has sizeof(long) == 32 and world #2 has sizeof(long) == 64). This kind of bad coding usually shows up when porting to a different word-sized environment, regardless of the O/S involved. > Of course, it's possible that this seemingly-technical justification > is a smokescreen crafted by Chris Carter and his X-File cronies to > hide the REAL reason for doing things this way, but then again, maybe > not. Har har. So what IS the real reason they can't change the typedef for 'DWORD' so that it works in a 64-bit environment? They've gone to so much trouble to make the parameter and variable declarations use those hideous typedef names (and pushing us to use them), why don't they put them to good use now? -- David R. Tribble, dtribble@technologist.com -- -- C++, the PL/1 of the 90s. [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]