Hubert HOLIN wrote:
...
>        I agree that different types having the same length is silly,
> and an horror for true portability, but unfortunately this state of
> things is not going to disappear soon... We would be better off with an
> addition of types of explicit length (int_8, int_16,... whatever).

The new C9X standard will include explicitly sized integer types; any
such change to C++ should conform with C9X as closely as possible.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Nathan Myers wrote:

> J. Kanze <kanze@gabi-soft.fr> wrote:
> > Just a quick note: "long long" will probably not be an extension,
> > soon.  It is part of the C9x CD1, and unless serious opposition can
> > be mustered in the national bodies, will become part of C.  From
> > there, it is almost certain that 99.9% of the C++ compilers will
> > offer it (as an extension), and that it will be incorporated in the
> > next revision of C++.
>
> I hope that such opposition can be mustered.
>
> By the time "long long" is implemented widely enough to be
> considered portable, 64-bit machines on which int, long, and
> "long long" are all 64 bits will be the norm.  Hence, "long long"
> will be useless in portable code.
>
> Meanwhile, on 32-bit machines, "int" and "long" will continue,
> uselessly, to be the same.  Without "long long", compilers would
> have begun to offer an option to make "long" be 64 bits on 32-bit
> machines.  I don't know who expects to benefit from a "long long"
> type.
>
> The signal merit of C has been its stability.  Take that away
> and what remains?

[SNIP]

 I believe that having one integer data type 64 bits long is
only part of the question, albeit an important one. It is desirable,
IMHO, to have integer data types of *different* length. It might be
interesting for performance reasons (faster operations on smaller
types, for storage reasons...). It also allows one to be certain of the
inexistance of overflows (other means do exist, but this one is
extremely convenient).

       I agree that different types having the same length is silly,
and an horror for true portability, but unfortunately this state of
things is not going to disappear soon... We would be better off with an
addition of types of explicit length (int_8, int_16,... whatever).

       As for your question, I, for one, would benefit from the "long long"
type, as I perform integer-based graphics algorithms.

            Hubert Holin
            holin@mathp7.jussieu.fr
            hh@ArtQuest.fr
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

ncm@nospam.cantrip.org (Nathan Myers) writes:

|>  and would work on compilers that don't support
|>  (or need) any "long long" extension.

Just a quick note: "long long" will probably not be an extension soon.
It is part of the C9x CD1, and unless serious opposition can be
mustered in the national bodies, will become part of C.  From there, it
is almost certain that 99.9% of the C++ compilers will offer it (as an
extension), and that it will be incorporated in the next revision of
C++.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientie objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze <kanze@gabi-soft.fr> wrote:
> Just a quick note: "long long" will probably not be an extension,
> soon.  It is part of the C9x CD1, and unless serious opposition can
> be mustered in the national bodies, will become part of C.  From
> there, it is almost certain that 99.9% of the C++ compilers will
> offer it (as an extension), and that it will be incorporated in the
> next revision of C++.

I hope that such opposition can be mustered.

By the time "long long" is implemented widely enough to be
considered portable, 64-bit machines on which int, long, and
"long long" are all 64 bits will be the norm.  Hence, "long long"
will be useless in portable code.

Meanwhile, on 32-bit machines, "int" and "long" will continue,
uselessly, to be the same.  Without "long long", compilers would
have begun to offer an option to make "long" be 64 bits on 32-bit
machines.  I don't know who expects to benefit from a "long long"
type.

The signal merit of C has been its stability.  Take that away
and what remains?

Nathan Myers
ncm@cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Nathan Myers <ncm@nospam.cantrip.org> wrote:
: The signal merit of C has been its stability.  Take that away
: and what remains?

Correct abstraction of _a_ computer. The best one.

Not that it has anything to do with long long. I am not touching
that.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]