Page MenuHomePhabricator

USENET
Updated 2,639 Days AgoPublic

This is a whiteboard for funny and useful stuff gathered from USENET.

Determine Endianness in C++

NEWSLETTER: comp.lang.c++
DATE: 19 May 2015
BY: @jcmcdonald
SUBJECT: Determining endianess at compile time

Juha Nieminen:
Is it possible to determine endianess at compile time (in C++14)?

At runtime it can be determined, for example, like this:

bool isLittleEndianSystem()
{
    unsigned value = 1;
    unsigned char* ptr = (unsigned char*)&value;
    return *ptr == 1;
}

Changing that to a constexpr function, however, doesn't seem so trivial
(unless I'm missing something obvious). Any ideas?

Scott Lurndal:
on linux it is, regardless of the C++ version. Several of our
C++ projects need to run on both LE and BE systems, we have
this in a common header file then use the appropriate accessors
in the code. Yes, it works with C as well.

#include <endian.h>
#ifndef __BYTE_ORDER
    #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
        #define __BYTE_ORDER __BIG_ENDIAN
    #elif !defined(__BIG_ENDIAN) && defined(__LITTLE_ENDIAN)
        #define __BYTE_ORDER __LITTLE_ENDIAN
        #define __BIG_ENDIAN 4321
    #elif !defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN)
        #define __BIG_ENDIAN 4321
        #define __BYTE_ORDER __BIG_ENDIAN
    #else
        #error Unable to determine Endian mode
    #endif
#endif

#if !defined(htobe16)
# if __BYTE_ORDER == __LITTLE_ENDIAN
#  define htobe16(x) __bswap_16 (x)
#  define htole16(x) (x)
#  define be16toh(x) __bswap_16 (x)
#  define le16toh(x) (x)

#  define htobe32(x) __bswap_32 (x)
#  define htole32(x) (x)
#  define be32toh(x) __bswap_32 (x)
#  define le32toh(x) (x)

#  define htobe64(x) __bswap_64 (x)
#  define htole64(x) (x)
#  define be64toh(x) __bswap_64 (x)
#  define le64toh(x) (x)
# else
#  define htobe16(x) (x)
#  define htole16(x) __bswap_16 (x)
#  define be16toh(x) (x)
#  define le16toh(x) __bswap_16 (x)

#  define htobe32(x) (x)
#  define htole32(x) __bswap_32 (x)
#  define be32toh(x) (x)
#  define le32toh(x) __bswap_32 (x)

#  define htobe64(x) (x)
#  define htole64(x) __bswap_64 (x)
#  define be64toh(x) (x)
#  define le64toh(x) __bswap_64 (x)
# endif
# endif

Red Floyd:
Just to be snarky, where's PDP Endian -- 2143?

Richard:
All identifiers beginning with __ are reserved for the implementation;
you should never define these yourself.

Victor Bazarov:
Nit-pick: not only beginning with __, but containing __. As to the beginning, it's the "an underscore and a capital letter", according to the Holy Standard.

Scott Lurndal:

I'm quite well aware of that, having spent a decade on various
standards committees (88open, UI, TOG).

Regardless, you'll find it quite common in the real world, particularly
amongst operating system programmers, who consider themselves part of
the implementation.

Richard:
Just because it's commonplace, doesn't mean it's a good idea.

One should always strive to produce code that works by design instead
of working by accident.

Unless you are the implementor of the compiler or the standard
library, there is never any need to introduce identifiers that begin
with __.

The presented code was suggested as a way for an application
programmer to determine endianness at compile time. In such code,
using identifiers beginning with __ is simply a bad idea and in
violation of the standard, whether is compiles or not.

Specifically, we're talking about 17.6.4.3.2 Global names [globl.names]:

"Certain sets of names and function signatures are always reserved to
the implementation:"

  • Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
  • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Non-Alphanumeric Languages (Funny)

NEWSLETTER: comp.lang.c++
DATE: 19 May 2015
BY: @jcmcdonald
SUBJECT: Broad Question for C++ coders

udtelco:
Defining programmers as those who authored any amount of C++ code that made it into production environment -
If you could add one thing - anything at all - to the core language or the new standard, what would it be ?
And in a same way, but trickier, what if anything would you like to see removed ? (in a sense of not just not having to use a feature or a paradigm, but also not having to deal with it or consider it's use by others)

Christopher Pisz:
Add:
datetime more like boost's
timezone not like boost's
exceptions with call stack built in
ability to see "who started the thread" when debugging
naming of threads

Remove:
globals
goto
variadic argument lists

Victor Bazarov:
That way we'll end up with the language called "++", which is neither here nor there.

Jason McDonald:

So...we once had the attack of the one-letter languages. Now we'll have the attack of the non-alphanumeric languages?

++

-- (for the minimalists)

?? (for absolute beginners)
!! (for quick-and-dirty programming by people who reject all standards)
!%#*&@^ (for irritating the heck out of people)

Christian Gollwitzer:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Last Author
jcmcdonald
Last Edited
May 19 2015, 7:17 PM