Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++.moderated > #7277 > unrolled thread

Avoid 'int' and associates.

Back to article view | Back to comp.lang.c++.moderated

Contents

  Avoid 'int' and associates. Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2015-06-14 06:36 -0600
    Re: Avoid 'int' and associates. Melzzzzz <mel@zzzzz.com> - 2015-06-14 18:00 -0600
    Re: Avoid 'int' and associates. Francis Glassborow <francis.glassborow@btinternet.com> - 2015-06-14 18:07 -0600
    Re: Avoid 'int' and associates. "James K. Lowden" <jklowden@speakeasy.net> - 2015-06-14 18:11 -0600
    Re: Avoid 'int' and associates. James Kuyper <jameskuyper@verizon.net> - 2015-06-14 18:11 -0600
    Re: Avoid 'int' and associates. Maciej Sobczak <see.my.homepage@googlemail.com> - 2015-06-14 18:11 -0600
    Re: Avoid 'int' and associates. Paavo Helde <myfirstname@osa.pri.ee> - 2015-06-14 20:24 -0600
      Re: Avoid 'int' and associates. David Brown <david.brown@hesbynett.no> - 2015-06-15 07:13 -0600
        Re: Avoid 'int' and associates. Francis Glassborow <francis.glassborow@btinternet.com> - 2015-06-15 11:22 -0600
          Re: Avoid 'int' and associates. Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2015-06-15 13:02 -0600
            Re: Avoid 'int' and associates. Francis Glassborow <francis.glassborow@btinternet.com> - 2015-06-15 14:54 -0600
              Re: Avoid 'int' and associates. Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2015-06-15 15:54 -0600
                Re: Avoid 'int' and associates. James Kuyper <jameskuyper@verizon.net> - 2015-06-15 21:04 -0600
                  Re: Avoid 'int' and associates. David Brown <david.brown@hesbynett.no> - 2015-06-16 07:05 -0600
                    Re: Avoid 'int' and associates. James Kuyper <jameskuyper@verizon.net> - 2015-06-16 14:59 -0600
                      Re: Avoid 'int' and associates. David Brown <david.brown@hesbynett.no> - 2015-06-16 16:47 -0600
                Re: Avoid 'int' and associates. scott@slp53.sl.home (Scott Lurndal) - 2015-06-16 09:54 -0600
                  Re: Avoid 'int' and associates. legalize+jeeves@mail.xmission.com (Richard) - 2015-06-16 14:59 -0600
                    Re: Avoid 'int' and associates. Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2015-06-16 16:47 -0600
                Re: Avoid 'int' and associates. "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-06-16 15:03 -0600
                  Re: Avoid 'int' and associates. Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2015-06-16 16:47 -0600
                    Re: Avoid 'int' and associates. pip010 <pip010@googlemail.com> - 2015-08-03 06:54 -0600
                      Re: Avoid 'int' and associates. maddoxr@acm.org - 2015-08-03 10:01 -0600
              Re: Avoid 'int' and associates. James Kuyper <jameskuyper@verizon.net> - 2015-06-15 21:04 -0600
            Re: Avoid 'int' and associates. James Kuyper <jameskuyper@verizon.net> - 2015-06-15 15:55 -0600
          Re: Avoid 'int' and associates. David Brown <david.brown@hesbynett.no> - 2015-06-16 07:04 -0600
    Re: Avoid 'int' and associates. Öö Tiib <ootiib@hot.ee> - 2015-06-27 14:17 -0600

Page 1 of 2  [1] 2  Next page →

#7277 — Avoid 'int' and associates.

In modern C++ we should avoid using 'int' and its associates such as 
'short' and 'long' as they are all non-portable and unsafe (their size 
and value range can differ from one implementation to the next); instead 
one should use the typedefs from <cstdint> instead.

A consequence of this rule is that we must never use 'auto' with integer 
literals such as:

auto i = 42;

or

auto i = 42u;

instead we write:

int32_t i = 42;

or

uint32_t i = 42u;

The fact we have to do this is due to shortcoming of the current C++ 
Standard; what we need is something like:

auto i = 42s32; // signed, 32-bits

or

auto i = 42u32; // unsigned, 32-bits

/Flibble


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [next] | [standalone]

#7278

On Sun, 14 Jun 2015 06:36:18 CST
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:

> 
> In modern C++ we should avoid using 'int' and its associates such as 
> 'short' and 'long' as they are all non-portable and unsafe (their
> size and value range can differ from one implementation to the next);
> instead one should use the typedefs from <cstdint> instead.
> 
> A consequence of this rule is that we must never use 'auto' with
> integer literals such as:
> 
> auto i = 42;
> 
> or
> 
> auto i = 42u;
> 
> instead we write:
> 
> int32_t i = 42;
> 
> or
> 
> uint32_t i = 42u;

I would never use auto for simple initialization and when types are
obvious (like int), rather I would use auto to avoid long templates.



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7279

On 14/06/2015 13:36, Mr Flibble wrote:
>
> In modern C++ we should avoid using 'int' and its associates such as
> 'short' and 'long' as they are all non-portable and unsafe (their size
> and value range can differ from one implementation to the next); instead
> one should use the typedefs from <cstdint> instead.
>

If it matters then your program is already dangerous and relying on 
undefined behaviour. Note that unless your program results in 
overflow/underflow there is no problem with signed types.

If your program is using unsigned types and is relying on the defined 
behaviour for over/underflow then you already have an essentially 
non-portable program because there is no requirement for exact sizes to 
exist. It is perfectly OK for all unsigned int types to be 64-bit. I do 
not know any system where this is the case but there are certainly 
systems where unsigned char, unsigned short, unsigned int and unsigned 
long are all 32-bit.

In almost all cases you should simply use the standard type that 
guarantees sufficient range for your needs.

Finally, you can simply use long long and unsigned long long everywhere 
and mark all literals as either LL or ULL.

I think the added complexity of using the <cstdint> typedefs routinely 
whether needed or not is a recipe for error.

Francis




-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7280

On Sun, 14 Jun 2015 06:36:18 CST
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:

> In modern C++ we should avoid using 'int' and its associates such as 
> 'short' and 'long' as they are all non-portable and unsafe (their
> size and value range can differ from one implementation to the next);
> instead one should use the typedefs from <cstdint> instead.

I disagree with this assertion.  Hardware evolves, and nonspecialized
variables evolve along with it.  

It's not strictly correct that "int" and "long" are nonportable.  It's
more correct to say their size is adapted by the compiler to the
machine.  Except in the case of I/O, ISTM that's an advantage.  

We have working code today written in the era of 16-bit machines, when
32-bit accesses required two memory reads and extra CPU cycles to
compute.  We have even more code dating from the VAX era, including
every operating system in common use.  The transition to 64-bit
hardware was made easier, I would argue, by *not* specifying variable
sizes in terms of bits.  Indeed, the biggest change has been away from
bare "int" to semantic, opaque types like size_t and off_t.  

I'm very glad we have <cstdint>.  It makes simple something that used
to ugly and arcane, and it a pleasure to use for e.g. network
programming.  It's a mistake to think it makes ordinary variables
obsolete.  Size usually doesn't matter very much, and is relative, and
changes over time.  

--jkl


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7281

On 06/14/2015 08:36 AM, Mr Flibble wrote:
> 
> In modern C++ we should avoid using 'int' and its associates such as 
> 'short' and 'long' as they are all non-portable and unsafe (their size 
> and value range can differ from one implementation to the next); instead 
> one should use the typedefs from <cstdint> instead.
> 
> A consequence of this rule is that we must never use 'auto' with integer 
> literals such as:
> 
> auto i = 42;
> 
> or
> 
> auto i = 42u;
> 
> instead we write:
> 
> int32_t i = 42;
> 
> or
> 
> uint32_t i = 42u;
> 
> The fact we have to do this is due to shortcoming of the current C++ 
> Standard; what we need is something like:
> 
> auto i = 42s32; // signed, 32-bits
> 
> or
> 
> auto i = 42u32; // unsigned, 32-bits

That's going a bit too far, in my opinion. First of all, whenever using
an interface, it's generally best to use the types specified for that
interface, even if they include 'int', 'short', or 'long'.

Secondly, if there's a traditional type name that's essentially
equivalent to one of the size-named types, I'll normally use the
traditional name instead, simply to save on my typing (though the
savings are bigger for the signed types). Types I consider essentially
equivalent are:

[u]int_least8_t     [un]signed char
[u]int_least16_t    [unsigned] short
[u]int_fast16_t     [unsigned] int
[u]int_fast32_t     [unsigned] long

Much of my code is targeted specifically at POSIX, which guarantees that
CHAR_BIT == 8, in which case I'm also willing to treat [un]signed char
as equivalent to [u]int8_t, but only if I've inserted the following
protection in the same translation unit:

#include <limits.h>
#if CHAR_BIT != 8
#error CHAR_BIT != 8
#endif
-- 
James Kuyper


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7282

> In modern C++ we should avoid using 'int' and its associates such as 
> 'short' and 'long' as they are all non-portable

Nonsense. They are very portable - the standard carefully specifies the minimum ranges that the implementation has to cover with
these types, so it is possible to write a portable program with them.

It is not these types which are a problem - the problem is with people who try to rely on the representation of these types to do
things that are very likely undefined anyway (like direct I/O, object overlays, etc.). This is why the coding standards that are
mostly obsessed with replacing these types with their "sized" alternatives (like int32_t) are those that usually target embedded
systems, where such practices are common. But it has nothing to do with being "modern".

> and unsafe

There is nothing inherently unsafe (except perhaps from overflows, but this exists also with sized types) in these types. Again, the
problem is with people who use them for things that are very likely undefined anyway.

> what we need is something like:
> 
> auto i = 42s32; // signed, 32-bits

Nonsense. There is absolutely no added value in specifying the exact type on the right side and pretend that the left side is
"automatically" inferred. You might as well write this:

int32_t i = 42;

without introducing any new crap to the language.

Side note: check how Ada solved all of these problems, it gives some refreshing perspective.

--
Maciej Sobczak * http://www.inspirel.com


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7283

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in 
news:cZOdnSRj9NsZweHInZ2dnUU7-IudnZ2d@giganews.com:

> 
> In modern C++ we should avoid using 'int' and its associates such as 
> 'short' and 'long' as they are all non-portable and unsafe (their size 
> and value range can differ from one implementation to the next); 
instead 
> one should use the typedefs from <cstdint> instead.

Sorry, int is extremely portable, every C and C++ implementation has it 
and it is guaranteed to work in a pretty large range (the actual range 
can be checked quite easily via std::numeric_limits, BTW).

Note that the actually needed range often depends on the application 
domain requirements and the hardware capabilities, both of which are out 
of the control of the programmer and can change in time. So, at the time 
of writing the programmer often does not have sufficient knowledge to 
select the "correct" fixed-size type. The only exception is when it is 
known that the numbers are relatively small and the limits do not matter, 
and this is exactly what the generic int type is meant for.

For example, it used to be that the number of pixels in a single medical 
image (2D or 3D) fits in 32 bits, but this assumption is slowly starting 
to break. So all those apps who have used e.g. std::uint32_t for the 
pixel index type will probably need a potentially painful upgrade cycle 
in the future.

Instead of relying on a fixed type, the program should define a typedef 
for each different usage case of int, which can be upgraded more cleanly 
and easily when the need arises. The typedef itself can be based on a 
fixed-size type or then not, this is not so crucial any more.

This is not something new, there is a reason why STL contains several 
such typedefs as e.g. std::string::size_type. Using fixed-size types 
would not be possible here. Fixed-size types should be directly used only 
in places where the type sizes are indeed fixed, e.g. when composing a 
TIFF file IFD in memory or something like that.

Cheers
Paavo


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7284

On 15/06/15 04:24, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in 
> news:cZOdnSRj9NsZweHInZ2dnUU7-IudnZ2d@giganews.com:
> 
>>
>> In modern C++ we should avoid using 'int' and its associates such as 
>> 'short' and 'long' as they are all non-portable and unsafe (their size 
>> and value range can differ from one implementation to the next); 
> instead 
>> one should use the typedefs from <cstdint> instead.
> 
> Sorry, int is extremely portable, every C and C++ implementation has it 
> and it is guaranteed to work in a pretty large range (the actual range 
> can be checked quite easily via std::numeric_limits, BTW).
> 

This all comes down to what is meant by "portable".  An integer type has
several characteristics, such as availability, minimum range, size, etc.
 For some of these, "int" is highly portable - it is found on any C++
system, and is guaranteed a minimum range of -32767 to +32767.  But
other characteristics, such as its actual size, lack portability.
"int32_t" (and friends) on the other hand do not exist on all systems -
but when they /do/ exist, they give you cross-target portability
guarantees on size and range that you cannot get with plain "int".

If you need some or all of the additional characteristics of int32_t,
then int32_t is the most portable way to get that.  If you just want a
counter or index, with a range up to +/- 32767, then "int" is the most
portable choice.


We should use the most appropriate type for the task in hand (which
could well be "auto") - sometimes it is "int", sometimes it is "int32_t".

Personally, I have very little use of "short" or "long", however.  Bar
consistency with existing code, I can't see any use of "(unsigned)
short" that would not be better suited with "(u)int16_t", nor any use of
"long" that would not be better with "int32_t" or "int64_t", according
to what you actually /need/.  And I think "unsigned char" and "signed
char" are meaningless monstrosities - plain "char" is good for character
data, while "uint8_t" and "int8_t" are appropriate for data bytes and
small unsigned or signed numbers.  (On platforms without 8-bit chars,
(u)int_least8_t is better than (un)signed char.)



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7285

On 15/06/2015 14:13, David Brown wrote:
>
> On 15/06/15 04:24, Paavo Helde wrote:
>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in
>> news:cZOdnSRj9NsZweHInZ2dnUU7-IudnZ2d@giganews.com:
>>
>>>
>>> In modern C++ we should avoid using 'int' and its associates such as
>>> 'short' and 'long' as they are all non-portable and unsafe (their size
>>> and value range can differ from one implementation to the next);
>> instead
>>> one should use the typedefs from <cstdint> instead.
>>
>> Sorry, int is extremely portable, every C and C++ implementation has it
>> and it is guaranteed to work in a pretty large range (the actual range
>> can be checked quite easily via std::numeric_limits, BTW).
>>
>
> This all comes down to what is meant by "portable".  An integer type has
> several characteristics, such as availability, minimum range, size, etc.
>   For some of these, "int" is highly portable - it is found on any C++
> system, and is guaranteed a minimum range of -32767 to +32767.  But
> other characteristics, such as its actual size, lack portability.
> "int32_t" (and friends) on the other hand do not exist on all systems -
> but when they /do/ exist, they give you cross-target portability
> guarantees on size and range that you cannot get with plain "int".
>
> If you need some or all of the additional characteristics of int32_t,
> then int32_t is the most portable way to get that.  If you just want a
> counter or index, with a range up to +/- 32767, then "int" is the most
> portable choice.
>
>
> We should use the most appropriate type for the task in hand (which
> could well be "auto") - sometimes it is "int", sometimes it is "int32_t".
>
> Personally, I have very little use of "short" or "long", however.

So both C and C++ provide an integer type that is guaranteed to be at 
least 32-bits, so why would I not use that when I need a 32-bit integer? 
  That is why int32_t better? Note that on systems with 32-bit int, long 
int is usually also 32 bits.

And where I need 64 bits the (ugly) long long int meets my need.

If I use real types I do not have to worry about places where the 
behaviour varies according to the underlying type (most commonly i/o in C)


I agree that short is pretty useless these days. It would have made more 
sense if it had been an exact 16-bit integer type.

Francis


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7286

On 15/06/2015 18:22, Francis Glassborow wrote:
>
> On 15/06/2015 14:13, David Brown wrote:
>>
>> On 15/06/15 04:24, Paavo Helde wrote:
>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in
>>> news:cZOdnSRj9NsZweHInZ2dnUU7-IudnZ2d@giganews.com:
>>>
>>>>
>>>> In modern C++ we should avoid using 'int' and its associates such as
>>>> 'short' and 'long' as they are all non-portable and unsafe (their size
>>>> and value range can differ from one implementation to the next);
>>> instead
>>>> one should use the typedefs from <cstdint> instead.
>>>
>>> Sorry, int is extremely portable, every C and C++ implementation has it
>>> and it is guaranteed to work in a pretty large range (the actual range
>>> can be checked quite easily via std::numeric_limits, BTW).
>>>
>>
>> This all comes down to what is meant by "portable".  An integer type has
>> several characteristics, such as availability, minimum range, size, etc.
>>   For some of these, "int" is highly portable - it is found on any C++
>> system, and is guaranteed a minimum range of -32767 to +32767.  But
>> other characteristics, such as its actual size, lack portability.
>> "int32_t" (and friends) on the other hand do not exist on all systems -
>> but when they /do/ exist, they give you cross-target portability
>> guarantees on size and range that you cannot get with plain "int".
>>
>> If you need some or all of the additional characteristics of int32_t,
>> then int32_t is the most portable way to get that.  If you just want a
>> counter or index, with a range up to +/- 32767, then "int" is the most
>> portable choice.
>>
>>
>> We should use the most appropriate type for the task in hand (which
>> could well be "auto") - sometimes it is "int", sometimes it is "int32_t".
>>
>> Personally, I have very little use of "short" or "long", however.
>
> So both C and C++ provide an integer type that is guaranteed to be at
> least 32-bits, so why would I not use that when I need a 32-bit integer?
>   That is why int32_t better? Note that on systems with 32-bit int, long
> int is usually also 32 bits.

'int' is only guaranteed to be at least 16 bits but the actual problem 
is the *at least* part: it can mean *different* sizes and value ranges 
on *different* implementations resulting in *different* or even 
*dangerous behaviour*.  If you want a type that behaves like 'int' then 
you should be explicit about it in your code by using 'int_fast16_t' but 
absolute care must be taken when using such variable types.

>
> And where I need 64 bits the (ugly) long long int meets my need.
>
> If I use real types I do not have to worry about places where the
> behaviour varies according to the underlying type (most commonly i/o in C)

You should be writing code such that the underlying type doesn't 
actually matter; that is part of the rationale for <cstdint> in the 
first place.

/Flibble


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7287

On 15/06/2015 20:02, Mr Flibble wrote:
>
> On 15/06/2015 18:22, Francis Glassborow wrote:
>>
>> On 15/06/2015 14:13, David Brown wrote:
>>>
>>> On 15/06/15 04:24, Paavo Helde wrote:
>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in
>>>> news:cZOdnSRj9NsZweHInZ2dnUU7-IudnZ2d@giganews.com:
>>>>
>>>>>
>>>>> In modern C++ we should avoid using 'int' and its associates such as
>>>>> 'short' and 'long' as they are all non-portable and unsafe (their size
>>>>> and value range can differ from one implementation to the next);
>>>> instead
>>>>> one should use the typedefs from <cstdint> instead.
>>>>
>>>> Sorry, int is extremely portable, every C and C++ implementation has it
>>>> and it is guaranteed to work in a pretty large range (the actual range
>>>> can be checked quite easily via std::numeric_limits, BTW).
>>>>
>>>
>>> This all comes down to what is meant by "portable".  An integer type has
>>> several characteristics, such as availability, minimum range, size, etc.
>>>   For some of these, "int" is highly portable - it is found on any C++
>>> system, and is guaranteed a minimum range of -32767 to +32767.  But
>>> other characteristics, such as its actual size, lack portability.
>>> "int32_t" (and friends) on the other hand do not exist on all systems -
>>> but when they /do/ exist, they give you cross-target portability
>>> guarantees on size and range that you cannot get with plain "int".
>>>
>>> If you need some or all of the additional characteristics of int32_t,
>>> then int32_t is the most portable way to get that.  If you just want a
>>> counter or index, with a range up to +/- 32767, then "int" is the most
>>> portable choice.
>>>
>>>
>>> We should use the most appropriate type for the task in hand (which
>>> could well be "auto") - sometimes it is "int", sometimes it is
>>> "int32_t".
>>>
>>> Personally, I have very little use of "short" or "long", however.
>>
>> So both C and C++ provide an integer type that is guaranteed to be at
>> least 32-bits, so why would I not use that when I need a 32-bit integer?
>>   That is why int32_t better? Note that on systems with 32-bit int, long
>> int is usually also 32 bits.
>
> 'int' is only guaranteed to be at least 16 bits but the actual problem
> is the *at least* part: it can mean *different* sizes and value ranges
> on *different* implementations resulting in *different* or even
> *dangerous behaviour*.  If you want a type that behaves like 'int' then
> you should be explicit about it in your code by using 'int_fast16_t' but
> absolute care must be taken when using such variable types.

If my code becomes dangerous I am already in undefined behaviour land 
and that effectively means that I am relying on some behaviour that 
breaks if int has more than 16-bits. Please give an example of code 
which works for a 16-bit int but is broken for an int with more bits.


>
>>
>> And where I need 64 bits the (ugly) long long int meets my need.
>>
>> If I use real types I do not have to worry about places where the
>> behaviour varies according to the underlying type (most commonly i/o
>> in C)
>
> You should be writing code such that the underlying type doesn't
> actually matter; that is part of the rationale for <cstdint> in the
> first place.

Not really, the idea was to allow systems that had more types available 
over and above those required by the standard to allow programmers to 
express their needs. And the rationale was a purely C one and I doubt 
that it would be in C++ other than for compatibility reasons.

For example it is possible that on a particular platform a 32-bit 
integer type performs faster than a 16-bit one. However that has a smell 
of premature optimisation.

  In reality very few if any programmers have ever made use of those 
extended types, and where they have, they are often not portable (there 
is no guarantee that any of the exact types exist on a platform)

Anyway you are free to use anything you want even if most of us would 
not do so and would often ask for change in a code review. Typedefs are 
a potential source of problems, particularly in C++ where overloading 
can be changed by a change in an underlying type.



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7288

On 15/06/2015 21:54, Francis Glassborow wrote:
>
> On 15/06/2015 20:02, Mr Flibble wrote:
>>
>> On 15/06/2015 18:22, Francis Glassborow wrote:
>>>
>>> On 15/06/2015 14:13, David Brown wrote:
>>>>
>>>> On 15/06/15 04:24, Paavo Helde wrote:
>>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in
>>>>> news:cZOdnSRj9NsZweHInZ2dnUU7-IudnZ2d@giganews.com:
>>>>>
>>>>>>
>>>>>> In modern C++ we should avoid using 'int' and its associates such as
>>>>>> 'short' and 'long' as they are all non-portable and unsafe (their
>>>>>> size
>>>>>> and value range can differ from one implementation to the next);
>>>>> instead
>>>>>> one should use the typedefs from <cstdint> instead.
>>>>>
>>>>> Sorry, int is extremely portable, every C and C++ implementation
>>>>> has it
>>>>> and it is guaranteed to work in a pretty large range (the actual range
>>>>> can be checked quite easily via std::numeric_limits, BTW).
>>>>>
>>>>
>>>> This all comes down to what is meant by "portable".  An integer type
>>>> has
>>>> several characteristics, such as availability, minimum range, size,
>>>> etc.
>>>>   For some of these, "int" is highly portable - it is found on any C++
>>>> system, and is guaranteed a minimum range of -32767 to +32767.  But
>>>> other characteristics, such as its actual size, lack portability.
>>>> "int32_t" (and friends) on the other hand do not exist on all systems -
>>>> but when they /do/ exist, they give you cross-target portability
>>>> guarantees on size and range that you cannot get with plain "int".
>>>>
>>>> If you need some or all of the additional characteristics of int32_t,
>>>> then int32_t is the most portable way to get that.  If you just want a
>>>> counter or index, with a range up to +/- 32767, then "int" is the most
>>>> portable choice.
>>>>
>>>>
>>>> We should use the most appropriate type for the task in hand (which
>>>> could well be "auto") - sometimes it is "int", sometimes it is
>>>> "int32_t".
>>>>
>>>> Personally, I have very little use of "short" or "long", however.
>>>
>>> So both C and C++ provide an integer type that is guaranteed to be at
>>> least 32-bits, so why would I not use that when I need a 32-bit integer?
>>>   That is why int32_t better? Note that on systems with 32-bit int, long
>>> int is usually also 32 bits.
>>
>> 'int' is only guaranteed to be at least 16 bits but the actual problem
>> is the *at least* part: it can mean *different* sizes and value ranges
>> on *different* implementations resulting in *different* or even
>> *dangerous behaviour*.  If you want a type that behaves like 'int' then
>> you should be explicit about it in your code by using 'int_fast16_t' but
>> absolute care must be taken when using such variable types.
>
> If my code becomes dangerous I am already in undefined behaviour land
> and that effectively means that I am relying on some behaviour that
> breaks if int has more than 16-bits. Please give an example of code
> which works for a 16-bit int but is broken for an int with more bits.
>
>
>>
>>>
>>> And where I need 64 bits the (ugly) long long int meets my need.
>>>
>>> If I use real types I do not have to worry about places where the
>>> behaviour varies according to the underlying type (most commonly i/o
>>> in C)
>>
>> You should be writing code such that the underlying type doesn't
>> actually matter; that is part of the rationale for <cstdint> in the
>> first place.
>
> Not really, the idea was to allow systems that had more types available
> over and above those required by the standard to allow programmers to
> express their needs. And the rationale was a purely C one and I doubt
> that it would be in C++ other than for compatibility reasons.
>
> For example it is possible that on a particular platform a 32-bit
> integer type performs faster than a 16-bit one. However that has a smell
> of premature optimisation.
>
>   In reality very few if any programmers have ever made use of those
> extended types, and where they have, they are often not portable (there
> is no guarantee that any of the exact types exist on a platform)

Can you back that assertion up with any facts at all?

>
> Anyway you are free to use anything you want even if most of us would
> not do so and would often ask for change in a code review. Typedefs are
> a potential source of problems, particularly in C++ where overloading
> can be changed by a change in an underlying type.

You are speaking for a lot of people there. As far as code reviews are 
concerned the MISRA C++ coding standard for safey critical systems 
prohibits the use of basic numerical types and mandates the use of the 
typedefs from <cstdint> (or an equivalent).

You should be coding to an interface; if the interface is legacy and 
takes an 'int' then you should of course perform a safe type conversion 
to an 'int' however any new interfaces that are within your remit to 
define should be using the typedefs from <cstdint> to ensure 
cross-platform portability and correct program operation.

/Flibble


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7290

On 06/15/2015 05:54 PM, Mr Flibble wrote:
> 
> On 15/06/2015 21:54, Francis Glassborow wrote:
...
>>   In reality very few if any programmers have ever made use of those
>> extended types, and where they have, they are often not portable (there
>> is no guarantee that any of the exact types exist on a platform)
> 
> Can you back that assertion up with any facts at all?

Which assertion are you referring to? Normally, "that" refers to the
most recently mentioned thing that it could refer to, but his very last
assertion is easy to back up: 7.20.1.1, describing the Exact-width
Types, says in paragraph 3: "These types are optional". His earlier
assertions are much more questionable, but if you meant to refer to one
of them, you should have used some phrase other than "that assertion".

...
> concerned the MISRA C++ coding standard for safey critical systems 
> prohibits the use of basic numerical types and mandates the use of the 
> typedefs from <cstdint> (or an equivalent).

I'm not impressed by MISRA's guidelines in general, and this one fits
into that pattern. I've only heard of them second-hand; a copy of those
guidelines is too expensive to justify buying one if you don't have an
obligation to follow those guidelines. However, what I've heard from
other people about those guidelines has not impressed me (and most of
those people were MISRA supporters).
-- 
James Kuyper


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7293

On 16/06/15 05:04, James Kuyper wrote:
> 
> On 06/15/2015 05:54 PM, Mr Flibble wrote:
>>
>> On 15/06/2015 21:54, Francis Glassborow wrote:
> ...
>>>   In reality very few if any programmers have ever made use of those
>>> extended types, and where they have, they are often not portable (there
>>> is no guarantee that any of the exact types exist on a platform)
>>
>> Can you back that assertion up with any facts at all?
> 
> Which assertion are you referring to? Normally, "that" refers to the
> most recently mentioned thing that it could refer to, but his very last
> assertion is easy to back up: 7.20.1.1, describing the Exact-width
> Types, says in paragraph 3: "These types are optional". His earlier
> assertions are much more questionable, but if you meant to refer to one
> of them, you should have used some phrase other than "that assertion".
> 
> ...
>> concerned the MISRA C++ coding standard for safey critical systems 
>> prohibits the use of basic numerical types and mandates the use of the 
>> typedefs from <cstdint> (or an equivalent).
> 
> I'm not impressed by MISRA's guidelines in general, and this one fits
> into that pattern. I've only heard of them second-hand; a copy of those
> guidelines is too expensive to justify buying one if you don't have an
> obligation to follow those guidelines. However, what I've heard from
> other people about those guidelines has not impressed me (and most of
> those people were MISRA supporters).
> 

MISRA standards are only £10 or £15 for the pdfs - it's not /that/
expensive!  (But of course any cost makes the whole process a lot more
inconvenient, especially if you just want a quick look for curiosity.)


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7296

On 06/16/2015 09:05 AM, David Brown wrote:
...
>> I'm not impressed by MISRA's guidelines in general, and this one fits
>> into that pattern. I've only heard of them second-hand; a copy of those
>> guidelines is too expensive to justify buying one if you don't have an
>> obligation to follow those guidelines. However, what I've heard from
>> other people about those guidelines has not impressed me (and most of
>> those people were MISRA supporters).
>>
> 
> MISRA standards are only £10 or £15 for the pdfs - it's not /that/
> expensive!  (But of course any cost makes the whole process a lot more
> inconvenient, especially if you just want a quick look for curiosity.)

IIRC, the last time I looked it was several hundred US$. A year ago, I
would have thought that £10 it would be almost worth paying for, just
out of curiosity. However, since the twins arrived I'm paying closer
attention to my money.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7299

On 16/06/15 22:59, James Kuyper wrote:
>
> On 06/16/2015 09:05 AM, David Brown wrote:
> ...
>>> I'm not impressed by MISRA's guidelines in general, and this one fits
>>> into that pattern. I've only heard of them second-hand; a copy of those
>>> guidelines is too expensive to justify buying one if you don't have an
>>> obligation to follow those guidelines. However, what I've heard from
>>> other people about those guidelines has not impressed me (and most of
>>> those people were MISRA supporters).
>>>
>>
>> MISRA standards are only £10 or £15 for the pdfs - it's not /that/
>> expensive!  (But of course any cost makes the whole process a lot more
>> inconvenient, especially if you just want a quick look for curiosity.)
>
> IIRC, the last time I looked it was several hundred US$. A year ago, I
> would have thought that £10 it would be almost worth paying for, just
> out of curiosity. However, since the twins arrived I'm paying closer
> attention to my money.
>

That must have been a /long/ time ago - or perhaps you are mixing it 
with some other standards (such as the current C++ standard, which is an 
absurd $265).

If you have anything specific you want to ask about MISRA, let me know 
and I can look it up - I can't send you a copy (since it would be 
copyright infringement, and the pdf is watermarked with my name).



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7294

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>
>On 15/06/2015 21:54, Francis Glassborow wrote:

>> For example it is possible that on a particular platform a 32-bit
>> integer type performs faster than a 16-bit one. However that has a smell
>> of premature optimisation.
>>
>>   In reality very few if any programmers have ever made use of those
>> extended types, and where they have, they are often not portable (there
>> is no guarantee that any of the exact types exist on a platform)
>
>Can you back that assertion up with any facts at all?

Probably not.  Most of the C++ code that I've worked on over the
last 20+ years uses these types (before they were standardized,
and with names like u32, uint32, uint32_t etc).

Granted most of that code ran sans OS (it was the OS), and required
fixed types to map to various hardware registers.

However, absent API requirements for other types, I would prefer
using types for which I understand the characteristics in all
conditions, thus I prefer the explicitly sized types.  Having
run into many issues in the past porting software from 16-bit
ints to 32-bit ints (and from 32-bit longs to 64-bit longs),
I would never advocating using 'int' for anything.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7295

[Please do not mail me a copy of your followup]

slp53@pacbell.net spake the secret code
<utVfx.149824$Lj1.95451@fx07.iad> thusly:

>Granted most of that code ran sans OS (it was the OS), and required
>fixed types to map to various hardware registers.

This is the situation where I think the size of the data really *does*
matter and it's important to use sized types and not the implicit size
of int, long, etc.  Things like structures representing byte streams
passed across the network (and you might do network-to-host byte
reordering in place on that structure), raw byte streams read from or
written to files, raw bytes transmitted between processes through
shared memory segments and so-on.

I've got some code im my open source project that doesn't use
specifically sized types for some binary file I/O and it's a mess right
because they used generic types.  So I am certainly sympathetic to
cases where it matters.

My assertion is that it simply doesn't matter in *every* case.

>However, absent API requirements for other types, I would prefer
>using types for which I understand the characteristics in all
>conditions, thus I prefer the explicitly sized types.  Having
>run into many issues in the past porting software from 16-bit
>ints to 32-bit ints (and from 32-bit longs to 64-bit longs),
>I would never advocating using 'int' for anything.

Here, I disagree.  The size of every int in a program isn't a
portability concern.  What's important is deciding which variables need
specific sizes and which don't.[*]

I've seen code where the compiler's default size of an int was 16-bits
and everywhere they wanted to iterate over containers or whatnot it was
int16_t all over the place.  Then you move to a compiler where the
defaault size of an int is 32-bits.  The fact that all those ints were
marked as 16-bits is now erroneous and simply a distraction.  How do
you know which ones really needed to be 16-bits and which were 16-bits
simply because that was the default size of an int?  Forcing them all
into a 16-bit straight jacket impedes portability instead of enhancing
it.

In other words, like most things in programming, it's a matter of good
judgment.  Simplistically applying a rule like "never use int" is
opening up your skull and dumping your brains in the garbage.  There is
a time when specifically sized types are important.

For most of the C++ I have worked on in the past 25 years, it was
important in only a very few cases.  Working on code where the team
insisted on sizing every single named quantity in the application was
tedious and yielded little to no value.  I have done very little
programming in embedded environments with strict resource limits and I
can see how someone who spent 25 years in that environment would
consider it indispensible that everything be specifically sized.  So it
varies with experience and problem domain.

But this is just another reason to advocate for proper application of
good judgment for your problem domain instead of adopting a simplistic
rule.  Even within a problem domain, things can change over time.
Embedded processors today have access to many more resources than they
did in the 80s when 64 users time shared out of 128KB of main memory
and an embedded CPU was lucky to have 128 bytes of RAM and 16K of ROM.

[*] Aside: if sizing is all that important, does that mean you encode
the byte size of a struct into its name?  I mean, if it's really that
important for int to be declared to be a specific size, but you don't
similarly mandate the same thing for structs and classes, then this
is an academic exercise in pedantry.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7298

On 16/06/2015 21:59, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> slp53@pacbell.net spake the secret code
> <utVfx.149824$Lj1.95451@fx07.iad> thusly:
>
>> Granted most of that code ran sans OS (it was the OS), and required
>> fixed types to map to various hardware registers.
>
> This is the situation where I think the size of the data really *does*
> matter and it's important to use sized types and not the implicit size
> of int, long, etc.  Things like structures representing byte streams
> passed across the network (and you might do network-to-host byte
> reordering in place on that structure), raw byte streams read from or
> written to files, raw bytes transmitted between processes through
> shared memory segments and so-on.
>
> I've got some code im my open source project that doesn't use
> specifically sized types for some binary file I/O and it's a mess right
> because they used generic types.  So I am certainly sympathetic to
> cases where it matters.
>
> My assertion is that it simply doesn't matter in *every* case.
>
>> However, absent API requirements for other types, I would prefer
>> using types for which I understand the characteristics in all
>> conditions, thus I prefer the explicitly sized types.  Having
>> run into many issues in the past porting software from 16-bit
>> ints to 32-bit ints (and from 32-bit longs to 64-bit longs),
>> I would never advocating using 'int' for anything.
>
> Here, I disagree.  The size of every int in a program isn't a
> portability concern.  What's important is deciding which variables need
> specific sizes and which don't.[*]
>
> I've seen code where the compiler's default size of an int was 16-bits
> and everywhere they wanted to iterate over containers or whatnot it was
> int16_t all over the place.  Then you move to a compiler where the
> defaault size of an int is 32-bits.  The fact that all those ints were
> marked as 16-bits is now erroneous and simply a distraction.  How do
> you know which ones really needed to be 16-bits and which were 16-bits
> simply because that was the default size of an int?  Forcing them all
> into a 16-bit straight jacket impedes portability instead of enhancing
> it.

This is why you should design things properly perhaps by the use of a 
traits class specialized for different hardware which has its own public 
typedefs:

template <typename HardwareType>
struct foo_traits;

template <>
struct foo_traits<ZXSpectrum48K>
{
	typedef uint16_t index_type;
};

typedef foo_traits<ZXSpectrum48K>::index_type index_type;

/* use index_type rather than uint16_t directly. */

/Flibble


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

#7297

>"Mr Flibble"  wrote in message 
>news:y6OdnUG8htn2rOLInZ2dnUU7-KOdnZ2d@giganews.com...

> [...]
> You are speaking for a lot of people there. As far as code reviews are 
> concerned the MISRA C++ coding standard for safey critical systems 
> prohibits the use of basic numerical types and mandates the use of the 
> typedefs from <cstdint> (or an equivalent).

Programming a warplane, anyone?:

http://www.stroustrup.com/JSF-AV-rules.pdf

;^) 


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++.moderated

csiph-web