Re: Top 10 most common hard skills listed on resumes...

Kaz Kylheku <643-408-1753@kylheku.com> writes:

[edited for brevity]

How can we write a program which, in an implementation which has a
__int128 type, outputs "yes" if it is an integer type, otherwise "no"?

>
I'd like the program to have well-defined behavior, under the test
assumption (that a documented, conforming extension is provided in
the form of __int128).
>
Integer types don't have to have their own matching constants.
The types char and short don't have their own constants;  they
borrow int.  Library support can be missing, in regard to
formatting __int128 to text and back.
>
The __int128 type better support all integer arithmetic, though:
and there should be conversion rules regarding when __int128 is
opposite to an operand of a different type.  An __int128 should be
usable as a displacement in pointer arithmetic.  It should be
possible to switch() on an __int128, even if a constant cannot be
expressed for every possible value.

To clarify, what you want is (I think) an integer-like type, not
necessarily an extended integer type.  As long as expressions and
values having the type in question behave like other expressions and
values of integer types (as the C standard uses the term), it's all
good.

Something that I think you want but isn't mentioned is casting:  you
want to be able to use explicit conversions (in other words, casts)
to force values or subexpressions to take on the new type.

As long as the regular arithmetic operations works and casting
works, and like you say switch() works with the new type, then
switch() statements are available, because 'case' needs only an
integer constant expression, and is not limited to constants.

Assuming all that is right, I recommend

    typedef  __uint128_t  U128;
    typedef   __int128_t  S128;

which works in both gcc and clang (I don't know yet about
Visual Studio).

(Let me add parenthetically that I don't see why you want the
program described.  Just put those typedefs in your code, and
if compiling the code barfs then you know they aren't supported.
On platforms where those particular names are not supported
but other ways of supplying the types are, using a #define or
two might rescue the situation (and the #define's can be
#undef'ed after the typedef statements are processed).)