Re: VS2005 doesn't like its own suggestions

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

See below

"Hendrik Schober" <SpamTrap@xxxxxx> wrote in message
news:e9x%23uvpjFHA.320@xxxxxxxxxxxxxxxxxxxxxxx
> Lawrence Groves <lgroves@xxxxxxxxxxxxxxxxxxx> wrote:
> > "John Carson" <jcarson_n_o_sp_am_@xxxxxxxxxxxxxxx> wrote in message
> > news:Oz4UBdjjFHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
> > [...]
> > > 2. The rationale for using INT/UINT typedefs was never specific. It
was
> > > just
> > > based on the general principle that if you use typedefs rather than
> > > hard-coded types, then you can map those typedefs to whatever is most
> > > convenient for the platform you are targetting. As things have turned
out
> > > ex
> > > post, using INT/UINT has been no different to using int/unsigned int.
> >
> > Ok, so its not specific enough in the documentation, or at least its
been
> > amended to say what was CONCEPTUALLY always meant. As an example, how
big
> > are these:
> >
> > BYTE
> > WORD
> >
> > Now you can argue till the cows come home that a byte might not always
be
> > eight bits on all systems, but I wouldn't mind betting that you'de be
hard
> > pushed to find a Windows system where this wasn't the case.
>
> You know why, in my question that spawned this
> subthread, I did not ask why MS introduced
> 'BOOL', but only about 'INT'? (Hint: I wouldn't
> have asked about 'BYTE' and 'WORD' either, but
> would have about 'UINT', had I thought of it.)
>

As the culprit for this entire thread, I did not dream of it to evolve so
far.
But I did learn several things that helped me to arrive with a more
comprehensive conclusion that I should have come to it in the first place...
But first, about BOOL, INT etc.

About INT:
-----------
It is my fault that I missed the complete definition of INT in
the table I have which is 32-bit int, although it is and it is NOT
contradicting ISO C++ at the same time. And most of all, irrelevant
as will be shown here.

It is not condradicting ------ because ISO C++ by definition
leaves the size open (exactly as C does. And by the way, recalling
that "predate 15 years", I forgot to mention in my prior response
that C predates MS alltogether...) so the introduction of INT does
NOTHING with regard to portability, more than if MS would continue
to be consistent in defining int as a 32 bit on their platforms. Also,
one has yet to explain why does MS at least 3 different definitions
(that I know of and maybe more) for 32 bit int: INT, INT32 & LONG32.
Moreover, I have learned from this discussion that it is not even true
that INT was ALWAYS 32 bit.
As far as future is concened: for 64 bit machines, it would be just perfect
if int stays 32 bit and long is 64 bit natively (it should have been 64
always, although could not be native because there were no 64 bit PCs).
Beyond 64: ISO C++ can stay the same and so could int and long.
C++ is likely to evolve and would address that and MS could simple
continue to adher to ISO C++ (which they never did...). But if C++
would start to decline (=not evolving), MS could THEN have a good
justification to introduce INT128, etc., still WITHOUT changing int
and long.
So the size / portability story is baloney. And so is the story about
"perfectness" (or luck thereof) mentioned above. Such a straight
forward logical analysis I described above could be done by any
programmer 20 (and 2000...) years ago (or at least by a real
programmer who was not thrown out of school after few months...:-) ).

It is contradicting ------ simply by its mere existence since ISO C++
does not recognize it.

All in all, INT (and all its relatives, INT32, UINT, DWORD, etc.
etc.) is good for nothing, except for trouble and we can
only resort to my original question about it.

About BOOL:
--------------
In this case, nobody here even tried to excuse it logically because
it is PRECISELY the same definition as bool.

Conclusions
========
As for the reasons BOOL, INT and many other things here exist,
like with many other truths in life, the truth here is likely to be a
combination of both, morbid as well as non-morbid reasons.
The non-morbid reasons, which I lean to believe are the prevalent
one, is sheer incompetency. Otherwise it would mean giving
MS too much professional credit.
The morbid one is MS' struggle to try to dominate the SW
industry and fighting the ISO C++ as much as they can.

The is no shred of THEORETICAL reason that would prevent
MS to EASILY accompllish whatever they want (that is technically)
while having all their APIs adher to PURE ISO C++.


David

> > Loz.
>
>
> Schobi
>
> --
> SpamTrap@xxxxxx 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
>
>


.

Relevant Pages

  • Re: All programs are undefined, Re: Why this works???
    ... terms of the capabilities of a particular machine about whose details ISO ... void printat(const char *s, int x, int y, int bg, int fg) ... If this technique were not well-defined under the above circumstances, ... these programs were able to rely on the well-definedness of this technique ...
    (comp.lang.c)
  • Re: VS2005 doesnt like its own suggestions
    ... I don't see how the PCH not existing in ISO C++ is relevant. ... >> After all, are there any non-morbid reasons of having BOOL, ... >> INT which are identical to bool & int? ... If I remember correct, the first SDK, which I doubt if incl. ...
    (microsoft.public.vc.language)
  • Re: Number of weeks in year?
    ... >produce results incompatible with ISO 8601" ... >private int WeekNumber_Entire4DayWeekRule ... > StartWeekDayOfYear = StartWeekDayOfYear; ... > EndWeekDayOfYear = EndWeekDayOfYear; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Garbage Collection - Stop Making Trash
    ... > as soon as the ECMA standard is ratified, it will be submitted to ISO. ... int main ... pointer, it cannot be moved by the GC and will not be garbage collected. ...
    (comp.lang.cpp)
  • Re: code portability
    ... All the ISO guys had to do was - nothing at all! ... wrongly assumes long int is precisely 32 bits is already broken, ... long as you can spare the space), and don't worry about changing data ... most companies don't switch compilers too often. ...
    (comp.lang.c)