Liste des Groupes | Revenir à co vms |
On 2024-08-14, Arne Vajhøj <arne@vajhoej.dk> wrote:Absolutely, must have come from an assembler background, where the use of signed branches and arithmetic, can get you into serious trouble.On 8/14/2024 2:33 PM, Arne Vajhøj wrote:That works great until you need to interface to the OS unfortunately.And it has different size of long and pointers. Causing problems>
for two cases:
* code that make implicit assumptions that those are 32 bit
* mixing C and C++
I am getting more and more convinced that C and C++
code should completely switch to the explicit length
model.
>
So:
>
#include <stdint.h>
>
or:
>
#include <cstdint>
>
and use:
>
int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t
>
and consider putting:
>
#define int ">>>> DO NOT USE INT <<<<"
#define short ">>>> DO NOT USE SHORT <<<<"
#define long ">>>> DO NOT USE LONG <<<<"
>
in as well to enforce.
>
Where did I put that asbestos suit to protect me
from the C/C++ crowd?
>
BTW, I've been writing my own code with explicit sizing for many years.
To extend this, I also know the difference between signed and unsigned
variables and I have a default-unsigned approach unless I absolutely
_need_ a signed variable.
Unfortunately, a lot of the material out there doesn't seem to understand
that designing a program is about modelling a real-world problem and that
it isn't OK to just use a signed integer to store an unsigned value.
Simon.
Les messages affichés proviennent d'usenet.