Proposal: New types in C++0x

Discussion in 'C++' started by Ioannis Vranos, Sep 22, 2004.

  1. 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?




    My proposal more thoroughly:

    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.

    unsigned long is another name of unsigned int32.


    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;

    vector<int32> someVector;

    list<unsigned int64> someList;


    int32 *p = new int32[10];

    long *pp = p;


    etc.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 22, 2004
    #1
    1. Advertising

  2. Ioannis Vranos

    David Hilsee Guest

    "Ioannis Vranos" <> wrote in message
    news:ciqc9o$1fi7$...
    > 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?
    >
    >
    >
    >
    > My proposal more thoroughly:
    >
    > 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.
    >
    > unsigned long is another name of unsigned int32.
    >
    >
    > 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;
    >
    > vector<int32> someVector;
    >
    > list<unsigned int64> someList;
    >
    >
    > int32 *p = new int32[10];
    >
    > long *pp = p;


    Wouldn't imposing exact requirements on existing types potentially cause
    incompatibility problems? If, for example, there exists a platform that
    makes int a 32-bit value (which would include many platforms, I reckon),
    then replacing int's representation with a 16 bit representation would break
    old programs. I think it's best to define more specific types like int16,
    int32, and int64, leave the other types alone, and let programs use the new
    types as they are needed. That way, explicit representations are only used
    as they are required. I believe this is the approach taken by the new C
    standard, but I could be wrong.

    --
    David Hilsee
     
    David Hilsee, Sep 22, 2004
    #2
    1. Advertising

  3. Ioannis Vranos

    Jack Klein Guest

    On Wed, 22 Sep 2004 02:08:41 +0300, Ioannis Vranos
    <> wrote in comp.lang.c++:

    > 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?


    Gee, you are only some 5 years behind the times, since the October,
    1999 adoption of ISO 9899:1999 Programming Languages -- C.

    Your proposal is actually poorly thought out and harmful. What of
    platforms that don't have 16-bit objects at all? There are some, you
    know, and C++ compilers for some of them.

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


    If it has padding bits, it is not an exact-width 16-bit type.

    > 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.


    This would break an extremely large amount of conforming, if not
    strictly portable, code that expects ints to be at least 32 bits.
    There are millions of lines of such code in existence in working
    programs where portability to 16-bit platforms is not considered
    important.

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


    On at least some 64-bit processor implementations, (un)signed long
    will be 64 bits.

    > signed int32, int32, signed long, long are all the same.
    >
    > unsigned long is another name of unsigned int32.
    >
    >
    > int64 is introduced and holds 64-bit values. signed int64 is equivalent
    > and unsigned int64 is the unsigned type.


    The original 1989 ANSI standard mentioned the already popular
    extension 'long long' for an integer type with at least 64 bits. It
    has been standardized in C for 5 years, and will be standardized, with
    that name, in C++.

    Do you actually think that both C and C++ have completely avoided
    specifying exact representations for the integer types for 30 plus
    years because nobody thought of it before you did? If you want
    exactly specified sizes and ranges for all the arithmetic types, you
    know where to find Java.

    And for a portable and standardized method of providing ways to
    specify integer types with various attributes, including such
    exact-width types as an implementation can support, do a web search
    for "stdint.h", part of standard C.

    Finally, the place to propose new features for C++ is in the moderated
    group news:comp.std.c++, not here. Read the FAQ first, of course.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Sep 22, 2004
    #3
  4. Jack Klein wrote:
    > On Wed, 22 Sep 2004 02:08:41 +0300, Ioannis Vranos
    > <> wrote in comp.lang.c++:
    >>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.

    >
    > This would break an extremely large amount of conforming, if not
    > strictly portable, code that expects ints to be at least 32 bits.
    > There are millions of lines of such code in existence in working
    > programs where portability to 16-bit platforms is not considered
    > important.


    Also 16-bit ints would slowdown code on many 32-bit platforms. int has
    traditionally been the fastest type of at least 16 bits for a given
    platform.

    --
    Peter van Merkerk
    peter.van.merkerk(at)dse.nl
     
    Peter van Merkerk, Sep 22, 2004
    #4
  5. Ioannis Vranos

    Tom Widmer Guest

    On Wed, 22 Sep 2004 02:08:41 +0300, 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, and making short and int
    >equivalent to int16, and long being equivalent to int32?


    I just posted this in the moderated group, but here it is again, for
    expediency's sake:

    http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
    (read from page 37 onwards).

    Tom
     
    Tom Widmer, Sep 22, 2004
    #5
  6. Ioannis Vranos

    Pete Becker Guest

    Jack Klein wrote:
    >
    > Finally, the place to propose new features for C++ is in the moderated
    > group news:comp.std.c++, not here. Read the FAQ first, of course.
    >


    He posted it there, as well as on comp.lang.c++.moderated, and got the
    same answers he's getting here.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Sep 22, 2004
    #6
  7. Tom Widmer wrote:

    > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
    > (read from page 37 onwards).



    Thanks for the very informational link. However long long is not an
    extensible name approach, and immediately 128 bit integers come to mind.


    So why not use suitable names from now? long64 comes to mind. Eventually
    integer types are bound to size, so we had better get used to this.


    In any case a longx/intx scheme is better to be chosen.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 22, 2004
    #7
  8. Ioannis Vranos wrote:
    > [...]
    > In any case a longx/intx scheme is better to be chosen.


    I think we just have to live with the fact that you simply don't\
    realise that if it _were_ better, it would have been already in use.
     
    Victor Bazarov, Sep 22, 2004
    #8
  9. Victor Bazarov wrote:

    > I think we just have to live with the fact that you simply don't\
    > realise that if it _were_ better, it would have been already in use.



    Victor being always sincere. :)



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 22, 2004
    #9
  10. Victor Bazarov wrote:

    > I think we just have to live with the fact that you simply don't\
    > realise that if it _were_ better, it would have been already in use.



    However what will happen in the C1x revision when an 128 bit type will
    have to be introduced? We will call it long long long or we will have a
    new long128 or something and the total types will be


    char
    short
    int
    long
    long long
    long128



    Why not "fix" this from now?



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 22, 2004
    #10
  11. Ioannis Vranos

    Greg Comeau Guest

    In article <cisbft$2vej$>,
    Ioannis Vranos <> wrote:
    >Victor Bazarov wrote:
    >
    >> I think we just have to live with the fact that you simply don't\
    >> realise that if it _were_ better, it would have been already in use.

    >
    >
    >However what will happen in the C1x revision when an 128 bit type will
    >have to be introduced? We will call it long long long or we will have a
    >new long128 or something and the total types will be
    >
    >
    >char
    >short
    >int
    >long
    >long long
    >long128
    >
    >
    >
    >Why not "fix" this from now?


    Another wrench: What if neither of these is the "fix"?
    --
    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?
     
    Greg Comeau, Sep 22, 2004
    #11
  12. Greg Comeau wrote:

    > Another wrench: What if neither of these is the "fix"?


    OK, I am open to alternatives! :)

    Anything in mind?



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 22, 2004
    #12
  13. Ioannis Vranos

    scott urban Guest

    In article <cisbft$2vej$>, Ioannis Vranos wrote:
    > Victor Bazarov wrote:
    >
    >> I think we just have to live with the fact that you simply don't\
    >> realise that if it _were_ better, it would have been already in use.

    >
    >
    > However what will happen in the C1x revision when an 128 bit type will
    > have to be introduced? We will call it long long long or we will have a
    > new long128 or something and the total types will be


    I propose the keyword 'really'. For your hypothetical problem:

    long long int b; // >= 64-buts
    really long int c; // >= 128-bits
    really really long int d; // >= 256-bits
    etc

    Also, these extensions and overloads:

    really short int e; // 4-bits

    really really short int f; // 2-bits

    really volatile bool b; // a solution for the DCL problem

    really mutable int x; // accessing x changes x in random ways

    really inline void foo () { ... } // non-optional

    int foo (really const int & x); // can't cast away const

    class X
    {
    really private: // disallow access from friends

    really virtual void foo (); // instead of = 0 syntax

    };


    JK, of course. This may be foolish, but I don't for see the need for a
    native 128-bit type anytime soon. I hope to be retired before the need
    for that kind of address space is even remotely conceivable, and for
    other applications (cryptography, calculating pi, whatever) there are
    libraries for Bignums.

    Scott
     
    scott urban, Sep 24, 2004
    #13
  14. scott urban wrote:

    > JK, of course. This may be foolish, but I don't for see the need for a
    > native 128-bit type anytime soon. I hope to be retired before the need
    > for that kind of address space is even remotely conceivable, and for
    > other applications (cryptography, calculating pi, whatever) there are
    > libraries for Bignums.



    :) Well 128 bit game consoles have been around for a long time

    http://www.viewz.com/shoppingguide/consoleguide6.shtml

    http://www.worldhistory.com/wiki/1/128-bit-era.htm


    so I guess in those machines there is definitely an 128 bit type.



    I do not think that bits are only convenient for addressing memory but
    also for providing larger numbers and more accuracy.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Sep 24, 2004
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gerrit Holl

    Proposal: new peps always in clpa

    Gerrit Holl, Jan 4, 2004, in forum: Python
    Replies:
    3
    Views:
    261
  2. glomde
    Replies:
    34
    Views:
    771
    bruno at modulix
    May 19, 2006
  3. James Thiele

    Proposal for new option -U extending -u

    James Thiele, Jul 29, 2006, in forum: Python
    Replies:
    2
    Views:
    236
    Carl Banks
    Jul 30, 2006
  4. Christopher Granade
    Replies:
    4
    Views:
    424
    Christopher Granade
    Aug 16, 2006
  5. Replies:
    2
    Views:
    499
    Thomas 'PointedEars' Lahn
    Mar 11, 2008
Loading...

Share This Page