Type Equivalence Issues and Solutions for long long int, long int, and int64_t in C++

Type Definitions and Platform Variations

In C++ programming, precise width definitions of integer types are crucial for cross-platform compatibility. The standard header <cstdint> provides fixed-width integer types such as int64_t, but their implementations depend on the compiler's target architecture. For instance, in the GCC compiler, int64_t is defined as follows:

#if __WORDSIZE == 64
typedef long int int64_t;
#else
__extension__
typedef long long int int64_t;
#endif

This conditional compilation results in int64_t being defined as long int on 64-bit systems and as long long int on 32-bit systems. Consequently, in 64-bit GCC compilation, the template specialization is_int64<long int> returns true, while is_int64<long long int> returns false; the opposite occurs in 32-bit compilation or with MSVC. This behavior stems from the strictness of the C++ type system, where long int and long long int are treated as distinct types, even if they have the same size and representation on specific platforms.

Problem Instances and Impacts

Consider a template function is_int64 that detects the int64_t type via specialization:

template <typename T>
bool is_int64() { return false; }

template <>
bool is_int64<int64_t>() { return true; }

In 64-bit GCC compilation, calling is_int64<long int>() returns 1, while is_int64<long long int>() returns 0, which can lead to inconsistent behavior in cross-platform code based on type traits. Similar issues arise in type trait templates:

template <typename T>
struct some_type_trait : boost::false_type { };

template <>
struct some_type_trait<int64_t> : boost::true_type { };

Here, some_type_trait<long int> inherits from boost::true_type, but some_type_trait<long long int> does not, even though both represent 64-bit integers on a 64-bit system. Additionally, function overloading or same_type checks may fail due to type differences, for example:

template <typename T>
void same_type(T, T) { }

void foo() {
    long int x;
    long long int y;
    same_type(x, y); // Compilation error: type mismatch
}

This type disparity is particularly problematic in overloaded functions, where erroneously treating long int and int64_t as equivalent could cause overload conflicts.

Solutions and Best Practices

Forcing type equivalence directly is not feasible in C++, as it would undermine the integrity of the type system and potentially cause overload ambiguities. Instead, rely on type properties rather than specific type names. Using C++11's std::enable_if and std::is_same allows for conditional function definitions:

#include <type_traits>

long foo(long x) {
    return x;
}

template <typename T>
typename std::enable_if<std::is_same<T, int64_t>::value && !std::is_same<int64_t, long>::value, T>::type foo(T x) {
    return x;
}

This code defines the foo(int64_t) overload only when int64_t is not the same as long, avoiding redefinition. In C++20, concepts can simplify this further:

#include <concepts>

long foo(long x) {
    return x;
}

int64_t foo(int64_t x) requires (!std::is_same_v<int64_t, long>) {
    return x;
}

This approach ensures code portability and type safety without the need for platform-specific conditional compilation. For type traits, detection can be based on size rather than type name, such as using sizeof(T) == 8 combined with std::is_integral to identify 64-bit integer types.

Reference Cases and Extensions

Similar issues occur with int32_t definitions, which may be int or long on 32-bit systems. The referenced article illustrates overload ambiguity: when the long type is 64-bit on a 64-bit system, calling foo(123L) might match both foo(std::int32_t) and foo(std::int64_t), leading to compilation errors. The solution involves adding a foo(long) overload, but care must be taken to maintain cross-platform compatibility and avoid redefinition conflicts with int64_t.

In summary, addressing type equivalence issues in C++ should prioritize standard type traits and conditional compilation over reliance on specific type names. Through property-based programming, robust and portable code can be written to adapt to various compilation environments and architectures.