From 31f930330de174e28e940d8134735a756b2dc4a9 Mon Sep 17 00:00:00 2001
From: Beman
A need to save overall time when I/O time is more important than + numeric variable CPU time.
A need to simplify program logic and eliminate logic errors. Since the endian types mimic the built-in types, there is no need to reason about the current endianness of variables and that can simplify program logic and eliminate logic errors.
A need to use unusual integer sizes (i.e. 3, 5, 6, or 7 bytes) to reduce internal and external space usage and save I/O time.
A need to use unaligned variables. Endian types can eliminate padding bytes in - structures, reducing internal and external space usage and saving I/O - time. They can deals with structures defined like this: +
A need to portably use unaligned variables or eliminate padding bytes in + structures, either to save I/O time by reducing internal and external space usage, + or to conform to a data layout over which you have no control. For + example, the structure below relies on a compiler extension, so is + non-portable, and operations on S::b will fail on hardware platforms that + require 32-bit alignment.
struct S {
-
uint16_t a;
uint32_t b;
} __attribute__ ((packed));
These problems are eliminated by defining S like this:
+++
struct S {
+
+ big_uint16_t a;
+ big_uint32_t b;
+ };
Programmer preference.
A need to leverage knowledge of developers who have been using C byte - swapping - functions for years.
A need to pass structures to third-party libraries expecting a specific structure format.
A need to leverage knowledge of developers who have been using C byte + swapping + functions for years.
Programmer preference.
Warning: Endian conversion functions are dangerous unless the current +endianness of a variable is always known. For example, if an exception is thrown +and there is no way in a catch block to know a variable's current endianness, +then any use of that variable including I/O is inherently unsafe. This danger is +not limited to exceptions; all uses of a variable whose endianness is unknown +are unsafe, period.
+Recent compilers, including GCC, Clang, and Microsoft, supply built-in support for byte swapping intrinsics. Such support is automatically detected and diff --git a/doc/mini_review_topics.html b/doc/mini_review_topics.html index ca07cc0..1409e76 100644 --- a/doc/mini_review_topics.html +++ b/doc/mini_review_topics.html @@ -29,7 +29,8 @@ integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications.
-+
Done. See Choosing between endian types and + endian conversion functions.
Conversion functions supplying results via return should be provided.