-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unique endian macros #130
Comments
The last example looks like the first example. Why you think it would work differently? https://www.boost.org/doc/libs/1_82_0/boost/predef/other/endian.h #if BOOST_ENDIAN_BIG_BYTE
# define BOOST_ENDIAN_BIG_BYTE_AVAILABLE
#endif
#if BOOST_ENDIAN_BIG_WORD
# define BOOST_ENDIAN_BIG_WORD_BYTE_AVAILABLE
#endif
#if BOOST_ENDIAN_LITTLE_BYTE
# define BOOST_ENDIAN_LITTLE_BYTE_AVAILABLE
#endif
#if BOOST_ENDIAN_LITTLE_WORD
# define BOOST_ENDIAN_LITTLE_WORD_BYTE_AVAILABLE
#endif
#define BOOST_ENDIAN_BIG_BYTE_NAME "Byte-Swapped Big-Endian"
#define BOOST_ENDIAN_BIG_WORD_NAME "Word-Swapped Big-Endian"
#define BOOST_ENDIAN_LITTLE_BYTE_NAME "Byte-Swapped Little-Endian"
#define BOOST_ENDIAN_LITTLE_WORD_NAME "Word-Swapped Little-Endian" |
You have overlooked the UNIQUE in the macro. In the first example, as I said, several cases can occur in the else branch:
With the UNIQUE-macros these ambiguities are excluded. thx & regards |
I am not.
It still not clear how. If you wrote something like: #if defined(BOOST_ENDIAN_LITTLE_BYTE_LITTLE_WORD_LITTLE_DWORD_LITTLE_QWORD_BLABLABLA_AVAILABLE) then, it would be more unique. |
I thought my (brief) comments would be sufficient. But I would like to explain it to you in detail: // WORD ? // BYTE ? // unique WORD or BYTE ? // unique WORD // unique BYTE // unique LITTLE_WORD // unique BIG_WORD This can rule out that there is a BYTE-based endianness. // unique LITTLE_BYTE // unique BIG_BYTE This can be ruled out that a WORD-based endianness is present. cu |
#if defined(BOOST_ENDIAN_LITTLE_WORD_BYTE_AVAILABLE) || defined(BOOST_ENDIAN_BIG_WORD_BYTE_AVAILABLE) Why you need to check both? Either you use little or big endian. Your These lines of code is quite hard to read mess. Why not write directly? #if BOOST_ENDIAN_BIG_BYTE || BOOST_ENDIAN_LITTLE_BYTE
# define BOOST_ENDIAN_BYTE_UNIQUE_AVAILABLE
# if !BOOST_ENDIAN_BIG_WORD
# if !BOOST_ENDIAN_LITTLE_WORD
# define BOOST_ENDIAN_UNIQUE_AVAILABLE
//...
#endif
#if BOOST_ENDIAN_BIG_WORD || BOOST_ENDIAN_LITTLE_WORD
# define BOOST_ENDIAN_WORD_UNIQUE_AVAILABLE
# if !BOOST_ENDIAN_BIG_BYTE
# if !BOOST_ENDIAN_LITTLE_BYTE
# define BOOST_ENDIAN_UNIQUE_AVAILABLE
//...
#endif It would be much more readable. |
This is exactly the conclusion. It is NOT guaranteed that in the case
because other combinations can occur
https://en.cppreference.com/w/cpp/types/endian (mixed-end, PDP). thx |
It does not guarantee either in your case, because you always need to write the else branch no matter what macro you are using. In both cases you can forget that. So it still is not clear why this need. |
Hello,
often the mistake is made (happened to me too) to consider only 2 cases when checking the endianess, eg:
struct foo
{
#if defined(BOOST_ENDIAN_LITTLE_BYTE_AVAILABLE)
uint32_t a : 16;
uint32_t b : 16;
#else
uint32_t b : 16;
uint32_t a : 16;
#endif
};
because the else branch is not necessarily BOOST_ENDIAN_BIG_BYTE_AVAILABLE. More correctly, this example must read:
struct foo
{
#if defined(BOOST_ENDIAN_LITTLE_BYTE_AVAILABLE)
uint32_t a : 16;
uint32_t b : 16;
#elif defined(BOOST_ENDIAN_BIG_BYTE_AVAILABLE)
uint32_t b : 16;
uint32_t a : 16;
#else
#error or
specializations for BOOST_ENDIAN_LITTLE_WORD_BYTE_AVAILABLE/BOOST_ENDIAN_BIG_WORD_BYTE_AVAILABLE
#endif
};
This is error-prone and usually overlooked.
Therefore it would make sense to provide unique macros that guarantee that ONLY the contrary endianess is used in the else-branch, eg endian.hpp.txt. Now we can use correctly:
struct foo
{
#if defined(BOOST_ENDIAN_LITTLE_BYTE_UNIQUE_AVAILABLE)
uint32_t a : 16;
uint32_t b : 16;
#else
uint32_t b : 16;
uint32_t a : 16;
#endif
};
But this means that these unique-macros are actually used. It would probably make more sense to "teach" this behavior to the existing macros.
thx & regards
Gero
The text was updated successfully, but these errors were encountered: