Hi!

Joshua Lehrer wrote:
> I posted a similar suggestion in comp.lang.c++.moderated, and got no response.
>
> http://snipurl.com/9obv

Yes, but I don't want to optionally support higher bit count. I
want to support every bit count. Bit counts not natively
available would need to be simulated. Of course e.g. integral<23>
would be substituted by 32-bit int without any further range
checking (as usual).

Frank

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> In addition, in platforms where 32-bit and 64-bit modes are possible,
> integral types can be interpreted in different sizes depending on the
> mode used. For example, in "narrow" mode, long might be 32 bits and in
> "wide" mode, it might be 64-bits. Hence leaving the type names as it
> is and allowing the implementation to decide the size is good.
> Explicit naming of types with sizes will impair performance.
>
> -Ganesh
>

This is somewhat of a strawman argument.  If I say that I want an
int32, then that doesn't have to say anything about the store behind
that variable.  The compiler could be free to choose a 64bit register
or even larger if that is what is best for the hardware.  Enforcement
of the 32bitness is possible as a debug option or not.  Obviously, if
I overflow 32 bits, it's undefined anyway you look at it.  Personally,
I prefer to let the compiler interface with the hardware and let me
code to my algorithm.  The more specificity I can have, the more the
compiler can tell me when something goes wrong.  I am in the camp that
enforcement of limits should be done in debug builds and otherwise
things can scream along as fast as possible.  Now, there are often
needs to specify exact sizes for data transfer or disk storage, but
that could be a qualifier on the type ('exact' or something like that)
and that would mean that I would possibly lose performance, but you
would never make an index 'exact' any more than you would use 'int' to
specify an exact size today.

Just my thoughts,
joe

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi!

Greg Comeau wrote:
> If such a capability is really needed,
> then we should focus on solutions which don't have to impact the
> core language, really are extensible (perhaps by users), avoids
> being old fashioned language hacks, incorporates a sound conceptual,
> abstraction and ease of use framework, considers applicablity to C,
> and is clearly superior to other approaches.

How about a general purpose integral type? Something like
   template<unsigned bits>  //bits > 0
   class integral;  //allows for 'bits' bit arithmetic

The compiler may use (dependant on hardware) native types such as
'int' as replacement for integral<xx>. If the number of bits
specified to integral is too big for any native type, then there
shall be an emulation of the type. E.g. integral<64> may use two
'long' (32-bit assumed) numbers to emulate the 64 arithmetic. If
ported to a 64-bit architecture, then the type is implemented as
a single 'int'.

Frank

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

bloodymir.crap@gmx.net (Frank Birbacher) wrote in message news:<2smvk8F1n4ek5U1@uni-berlin.de>...
> Hi!
>
> Greg Comeau wrote:
> > If such a capability is really needed,
> > then we should focus on solutions which don't have to impact the
> > core language, really are extensible (perhaps by users), avoids
> > being old fashioned language hacks, incorporates a sound conceptual,
> > abstraction and ease of use framework, considers applicablity to C,
> > and is clearly superior to other approaches.
>
> How about a general purpose integral type? Something like
>    template<unsigned bits>  //bits > 0
>    class integral;  //allows for 'bits' bit arithmetic
>
> The compiler may use (dependant on hardware) native types such as
> 'int' as replacement for integral<xx>. If the number of bits
> specified to integral is too big for any native type, then there
> shall be an emulation of the type. E.g. integral<64> may use two
> 'long' (32-bit assumed) numbers to emulate the 64 arithmetic. If
> ported to a 64-bit architecture, then the type is implemented as
> a single 'int'.
>

I posted a similar suggestion in comp.lang.c++.moderated, and got no response.

http://snipurl.com/9obv

joshua lehrer
factset research systems
NYSE:FDS

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ioannis Vranos wrote:
>
> However the current requirement is int and short to be at least 16-bit
> of storage and long at least 32. So expecting int to be of 32-bit of
> storage is system specific and thus not portable.
>
>
> On the other hand, making it exactly 16-bit and equivalent of int16, is
> a 100% "superset" of the current situation.
>
>
> Currently, code wanting to make sure it uses an at least 32-bit integer
> type should use long.
>

This is true, however many programmers have (rightly or wrongly) taken
int to be "the natural length for an integer on the current processor",
which is 32 bits on a 32 bit architecture. Forcing int to be 16 bits
could in some circumstances make code on 32bit and 64bit architectures
less efficent.

More to the point, far, far, far too many programs on 32bit
architectures have been written to use 32 bits ints, as that is what
their compiler used. While this code may not be strictly standard code,
there is no way compiler writers are going to limit their ints to 16
bits for no obvious real-life advantage and risk breaking (I'd imagine)
80%+ of their users programs.

Chris

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"chris" <caj@cs.york.ac.uk> wrote in message
news:cjoh2i$rvk$1@pump1.york.ac.uk...
> Ioannis Vranos wrote:
> >
> > Currently, code wanting to make sure it uses an at least 32-bit integer
> > type should use long.
>
> This is true, however many programmers have (rightly or wrongly) taken
> int to be "the natural length for an integer on the current processor",

Rightly, I think:

"A ''plain'' int object has the natural size suggested by the architecture
of the execution environment (large enough to contain any value in the range
INT_MIN to INT_MAX as defined in the header <limits.h>)." (6.2.5/5 in C99)

> which is 32 bits on a 32 bit architecture. Forcing int to be 16 bits
> could in some circumstances make code on 32bit and 64bit architectures
> less efficent.
>
> More to the point, far, far, far too many programs on 32bit
> architectures have been written to use 32 bits ints, as that is what
> their compiler used. While this code may not be strictly standard code,

It's standard, alright, just not necessarily portable to architectures with
other word sizes.

Regards,

Terje


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > However the current requirement is int and short to be at least 16-bit
> > of storage and long at least 32. So expecting int to be of 32-bit of
> > storage is system specific and thus not portable.
> >
> > On the other hand, making it exactly 16-bit and equivalent of int16, is
> > a 100% "superset" of the current situation.
> >
> > Currently, code wanting to make sure it uses an at least 32-bit integer
> > type should use long.
> >
> This is true, however many programmers have (rightly or wrongly) taken
> int to be "the natural length for an integer on the current processor",
> which is 32 bits on a 32 bit architecture. Forcing int to be 16 bits
> could in some circumstances make code on 32bit and 64bit architectures
> less efficent.
>

In addition, in platforms where 32-bit and 64-bit modes are possible,
integral types can be interpreted in different sizes depending on the
mode used. For example, in "narrow" mode, long might be 32 bits and in
"wide" mode, it might be 64-bits. Hence leaving the type names as it
is and allowing the implementation to decide the size is good.
Explicit naming of types with sizes will impair performance.

-Ganesh

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ben Hutchings wrote:
> Ioannis Vranos wrote:
>
>>Since there is the need of a new 64-bit integer type, the approach taken
>>should be extensible.
>>
>>What about introducing int64 being exactly 64 bit, int32 being exactly
>>32 bits and int16 being exactly 16 bits,
>
>
> TR1 (in its draft form) specifies the header <stdint.h> which may
> define the types int16_t, int32_t and int64_t (as in C99).  However,
> note that these exact-size types are all optional since not all
> machines naturally support integer types of these sizes.


However since they will support long long,and long long will be 64-bits
minimum (and probably exactly), the truth is that they will support >=64
bits in any case.


So why have those "exotic" typedefs?



> This is nonsensical.  Not only is it impractical to implement on some
> machines, but it's incompatible with most implementations on machines
> that do naturally support such integer types: int is generally 32-bit,
> and so it should be on 32-bit machines.



Ok, consider the proposal int and long being equivalent to int32.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Since there is the need of a new 64-bit integer type, the approach taken
should be extensible.

What about introducing int64 being exactly 64 bit, int32 being exactly
32 bits and int16 being exactly 16 bits, and making short and int
equivalent to int16, and long being equivalent to int32?



--
Ioannis Vranos

http://www23.brinkster.com/noicys

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

To be more obvious, what I propose is:


int16 is introduced and is an exact 16-bit type (of course additional
padding bits are allowed). int and short become equivalent of it.

That is, signed int16, int16, signed, signed int, int, signed short,
short to be all equivalent. The same for the unsigned equivalents. That
is unsigned int16 to be the same as unsigned int and unsigned, etc.

int32 is introduced and holds exactly 32-bit values. long becomes
another name of it, as was the case with the above.

signed int32, int32, signed long, long are all the same.


int64 is introduced and holds 64-bit values. signed int64 is equivalent
and unsigned int64 is the unsigned type.


So we can say:

int64 x;

int32 *p = new int32[10];

long *pp = p;


etc.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ioannis Vranos wrote:
> To be more obvious, what I propose is:
>
>
> int16 is introduced and is an exact 16-bit type (of course additional
> padding bits are allowed). int and short become equivalent of it.
>
> That is, signed int16, int16, signed, signed int, int, signed short,
> short to be all equivalent. The same for the unsigned equivalents. That
> is unsigned int16 to be the same as unsigned int and unsigned, etc.
>
Do you mean that int should become exactly 16 bits? On most systems I
use it is 32 bits, so this would break quite a lot of programs which
expect it to be 32 bits.

Chris

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ioannis Vranos wrote:
> To be more obvious, what I propose is:
>
>
> int16 is introduced and is an exact 16-bit type (of course additional
> padding bits are allowed). int and short become equivalent of it.
>
> That is, signed int16, int16, signed, signed int, int, signed short,
> short to be all equivalent. The same for the unsigned equivalents. That
> is unsigned int16 to be the same as unsigned int and unsigned, etc.
>
Do you mean that int should become exactly 16 bits? On most systems I
use it is 32 bits, so this would break quite a lot of programs which
expect it to be 32 bits.

Chris

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ioannis Vranos" <ivr@guesswh.at.grad.com> wrote in message
news:cip6vr$215s$2@ulysses.noc.ntua.gr...
> To be more obvious, what I propose is:
>
>
> int16 is introduced and is an exact 16-bit type (of course additional
> padding bits are allowed). int and short become equivalent of it.
>
> That is, signed int16, int16, signed, signed int, int, signed short,
> short to be all equivalent. The same for the unsigned equivalents. That
> is unsigned int16 to be the same as unsigned int and unsigned, etc.
>
> int32 is introduced and holds exactly 32-bit values. long becomes
> another name of it, as was the case with the above.
>
> signed int32, int32, signed long, long are all the same.
>
>
> int64 is introduced and holds 64-bit values. signed int64 is equivalent
> and unsigned int64 is the unsigned type.
>
>
> So we can say:
>
> int64 x;
>
> int32 *p = new int32[10];
>
> long *pp = p;
>
>
> etc.

I believe the C standard header <stdint.h> provides these as typedef's.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <cinake$1aje$1@ulysses.noc.ntua.gr>,
Ioannis Vranos  <ivr@guesswh.at.grad.com> wrote:
>Since there is the need of a new 64-bit integer type, the approach taken
>should be extensible.
>
>What about introducing int64 being exactly 64 bit, int32 being exactly
>32 bits and int16 being exactly 16 bits, and making short and int
>equivalent to int16, and long being equivalent to int32?

Besides the obvious debates of no new keywords, ugly spellings,
whether there should be a C99 way and also a unique C++ way,
and that something like the above would/should need to be coordinated
with the C committee, I think it would make sense to focus on the
operative word "extensible".  If such a capability is really needed,
then we should focus on solutions which don't have to impact the
core language, really are extensible (perhaps by users), avoids
being old fashioned language hacks, incorporates a sound conceptual,
abstraction and ease of use framework, considers applicablity to C,
and is clearly superior to other approaches.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ioannis Vranos wrote:
> Since there is the need of a new 64-bit integer type, the approach taken
> should be extensible.
>
> What about introducing int64 being exactly 64 bit, int32 being exactly
> 32 bits and int16 being exactly 16 bits,

TR1 (in its draft form) specifies the header <stdint.h> which may
define the types int16_t, int32_t and int64_t (as in C99).  However,
note that these exact-size types are all optional since not all
machines naturally support integer types of these sizes.

> and making short and int equivalent to int16, and long being
> equivalent to int32?

This is nonsensical.  Not only is it impractical to implement on some
machines, but it's incompatible with most implementations on machines
that do naturally support such integer types: int is generally 32-bit,
and so it should be on 32-bit machines.

--
Ben Hutchings
The generation of random numbers is too important to be left to chance.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

chris wrote:
> Ioannis Vranos wrote:
>
>> To be more obvious, what I propose is:
>>
>>
>> int16 is introduced and is an exact 16-bit type (of course additional
>> padding bits are allowed). int and short become equivalent of it.
>>
>> That is, signed int16, int16, signed, signed int, int, signed short,
>> short to be all equivalent. The same for the unsigned equivalents.
>> That is unsigned int16 to be the same as unsigned int and unsigned, etc.
>>
> Do you mean that int should become exactly 16 bits? On most systems I
> use it is 32 bits, so this would break quite a lot of programs which
> expect it to be 32 bits.


However the current requirement is int and short to be at least 16-bit
of storage and long at least 32. So expecting int to be of 32-bit of
storage is system specific and thus not portable.


On the other hand, making it exactly 16-bit and equivalent of int16, is
a 100% "superset" of the current situation.


Currently, code wanting to make sure it uses an at least 32-bit integer
type should use long.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]