Basic Types

Discussion in 'C++' started by nvangogh, Mar 10, 2014.

  1. nvangogh

    nvangogh Guest

    Is it fair (and technically accurate) to say that the only differences
    between int, long, long long and short is the number of bits that is
    required to represent the type in the computer? Or is there additional
    differences than size?
     
    nvangogh, Mar 10, 2014
    #1
    1. Advertisements

  2. AFA other differences go, they are likely to be derivative of the size,
    like the alignment requirement. Also, the size can dictate whether
    certain operations could be done intrinsically or need to be emulated.
    For instance, 'long' may not fit in the CPU register and operations on
    it would be more complex (in machine code) than on 'int', for example.

    V
     
    Victor Bazarov, Mar 10, 2014
    #2
    1. Advertisements

  3. Am 10.03.2014 18:42, schrieb nvangogh:
    There are implications on other things like CPU usage, compiled code
    size and memory layout. But all of them are platform dependant.

    I.e some platforms may not be able to deal natively with all operand
    sizes. In general only char and int are safely supported native. Other
    types may or may not be supported. Strictly speaking even this is not
    guaranteed, but except for some DSPs it should be reliable. I.e. x64
    code does not handle short int (16 bit) efficiently.

    Although many platforms require that the operands are aligned to the
    operand size in memory. Everything else is either slow or impossible. So
    if you think you could save some memory by using small types you might
    only end up with the overhead of the smaller type without any memory
    saving because the compiler adds padding.


    Marcel
     
    Marcel Müller, Mar 10, 2014
    #3
  4. If you specify unsigned, the compiler has no option but to use
    unsigned int.
     
    Barry Schwarz, Mar 10, 2014
    #4
  5. Yeh, in a strongly typed computer language such as C, C++, JAVA, PASCAL
    and etc. the basic operations of
    different types might result in
    truncated unexpected results.

    But in a true OOP language in the
    5-6-7 th gens such as python, pike,
    ruby, and erlang, things are different
    in the design concepts of the
    various languages.
     
    88888 Dihedral, Mar 11, 2014
    #5
  6. Even if the sizes for some of the types are the same, they are still
    considered distinct types: typeid's are different, for example.
    So obviously there are additional differences other than the size.
     
    Seungbeom Kim, Mar 11, 2014
    #6
  7. For such purposes, I tend to choose the smallest type, no smaller
    than int, whose minimum range specified by the standard is enough
    for the usage. For example, int is guaranteed to cover -32767..+32767,
    so I use that for anything no greater, and the next candidate is long,
    modulo signedness. (Booleans and characters are exceptions.)
    Yes, intN_t types seem to be a little overused; especially when
    int_fastN_t or int_leastN_t is a better choice.
    Right, but choosing long over int when you need to represent 100,000
    is a better choice and doesn't hurt either. :)
     
    Seungbeom Kim, Mar 11, 2014
    #7
  8. nvangogh

    Öö Tiib Guest

    Standard does avoid defining bits for those types. Instead it has such
    minimum required ranges for them:

    signed char: -127 to 127
    unsigned char: 0 to 255
    char: -127 to 127 or 0 to 255 (depends on default char signedness)
    short: -32767 to 32767
    unsigned short: 0 to 65535
    int: -32767 to 32767
    unsigned int: 0 to 65535
    long: -2147483647 to 2147483647
    unsigned long: 0 to 4294967295
    long long: -9223372036854775807 to 9223372036854775807
    unsigned long long: 0 to 18446744073709551615

    Note that minimum range for 'short' and 'int' is same. Since 'int' is
    required to be quick and also no inbuilt arithmetic operation returns
    'short' it makes 'short' somewhat pointless type.

    Bits are defined by standard for types like int32_t from <stdint.h> but
    for my taste those types are too overused in actual code. There are
    plenty of information about the mundane types.

    Precise details about actual ranges and bits of integral types
    of implementation one can get from std::numeric_limits<T>.
     
    Öö Tiib, Mar 11, 2014
    #8
  9. nvangogh

    Luca Risolia Guest

    Given one C++ implementation, you can see the all differences in detail by
    comparing the all various std::numeric_limits<T> instantiations (where T is an
    arithmetic type). For the difference between minimum requirements and other
    constraints you should refer to the standard.
     
    Luca Risolia, Mar 11, 2014
    #9
  10. nvangogh

    Ian Collins Guest

    Maybe the standard got it wrong and rather than fixed width types, we
    should fixed bounds types?

    up_to_100K_t anyone?

    :)
     
    Ian Collins, Mar 11, 2014
    #10
  11. nvangogh

    Öö Tiib Guest

    Why such things are needed? Even the exact bit types are heavily overused
    for my taste (and it looked like also for Kim's taste).

    If there is need for int with exact bounds then a template
    (most ideas described there http://accu.org/index.php/journals/313)
    is fine enough. Not a rocket science so it is unsure why neither
    boost nor standard contains such thing already.
     
    Öö Tiib, Mar 12, 2014
    #11
  12. nvangogh

    Stuart Guest

    On 12.03.14, Öö Tiib:
    [snip]
    +1.

    That would be the first step to catch up with Ada95. Unfortunately,
    other features of Ada95 cannot so easily be simulated by a C++ template,
    like choosing the right integer type depending on the specified range.
    Or am I wrong there?

    For example, the declaration of up_to_100K_t leaves the underlying type
    open, whereas up_to_100K_t_int explicitely states that Integer should be
    used for this type.
    type up_to_100K_t is range 0 .. 100000;
    type up_to_100K_t is Integer range 0 .. 100000;

    Most often it is not necessary to care about the size of the underlying
    integer type (whether a loop index is 16 bit, 32 bit or 64 bit is mostly
    irrelevant, the compiler should select the most appropriate type).
    However, if the size of a type actually matters, you still specify your
    restrictions:
    for up_to_100K_t use 16; // now the compiler must use a 16 bit type.

    IMHO, C++ has still a long way to go ...

    Regards,
    Stuart

    PS: Don't get me wrong, C++ is still my favorite language. In my option
    it is far better than Objective C, which I am forced to use for Mac
    development.
     
    Stuart, Mar 12, 2014
    #12
  13. nvangogh

    Jorgen Grahn Guest

    You say "safely", but you seem to mean "efficiently". True, you might
    end up on a CPU where e.g. division of 'long' is ten or a hundred
    times slower than division of 'int' -- but it still /works/, or it's
    not C++.

    /Jorgen
     
    Jorgen Grahn, Mar 12, 2014
    #13
  14. nvangogh

    Stuart Guest

    LOL, you got me there.

    gcc actually says:
    "size for "up_to_100K_t" too small, minimum allowed is 17"
    so I should have tried to compile it. And the size specification must be
    for up_to_100K_t'SIZE use 32;

    Regards,
    Stuart
     
    Stuart, Mar 12, 2014
    #14
  15. nvangogh

    Öö Tiib Guest

    Possibly you are wrong ... for example ...

    boost::int_max_value_t<100000>::least

    .... is the smallest, built-in, signed integral type that can hold all the
    values in the inclusive range 0 - 100000. The parameter should be a
    positive number. Things like that can be used to determine underlying
    type.
    There can be other issues (like speed) why one or other underlying type
    has to be preferred despite best matching size.
    It has, but I do not feel that determining underlying type can be
    issue. ;) That feels only to be issue how to make convenient interface
    while keeping flexibility.
     
    Öö Tiib, Mar 13, 2014
    #15
  16. nvangogh

    nvangogh Guest

    On 10/03/14 17:42, nvangogh wrote:
    I have a related follow up question on basic types. As I have limited
    understanding I maths I need to ask this. This is from C++ Primer 5th
    edition p41:

    "What ,if any, are the differences between
    int month = 9, day = 7;
    int month = 09, day = 07"

    I cannot see any material difference. The first line initializes the
    variables with decimal values. The second line uses octal notation - as
    the literals are preceded by 0. Do these two values work out exactly the
    same or is octal 09 different from decimal 9 (& octal 07 decimal 7)?
     
    nvangogh, Mar 13, 2014
    #16
  17. There is no "octal 09" since there is no octal digit '9'.

    V
     
    Victor Bazarov, Mar 13, 2014
    #17
  18. nvangogh

    Öö Tiib Guest

    Octal is base 8 number. That means it contains digits from 0 to 7.
    Integer literal like 09 is illegal and so second line is syntax error.

    Usually, when someone is using octal constants in code then it is
    either typo or sly obfuscation; very rare people can recognise
    immediately that 042 means 34. Therefore it is good idea to avoid
    them without very good reason despite it is valid C++.
     
    Öö Tiib, Mar 13, 2014
    #18
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.