Should STL support exotic MSVC pointers?

[AlexGuteniev]

It may sound surprising, but:

• 32-bit pointers are available for 64-bit compilation, and vice versa
• There are explicitly signed and unsinged pointers, and "normal" pointers behave as signed

STL does not support this feature fully. They work with is_pointer_v, but not with atomic.
Example:

#include <Windows.h>
#include <atomic>
#include <iostream>
#include <type_traits>

int main() {
    std::cout << std::is_pointer_v<int* POINTER_32> << '\n'; // prints 1
    std::cout << std::is_pointer_v<int* POINTER_64> << '\n'; // prints 1

    
    std::atomic<int* POINTER_32> sp32;
    sp32.fetch_add(1); // this does not compile on 64-bit

    std::atomic<int* POINTER_64> sp64;
    sp64.fetch_add(1); // this does not compile on 32-bit

}

Should they be supported fully by STL?

[StephanTLavavej]

I believe that increasing support for non-Standard compiler extensions falls under our Non-Goals. In this case, supporting such types would dramatically complicate our implementation for very little value (note that we have somehow survived the last 20+ years without such support), and for zero portability gains. (I have also seen virtually zero attempted usage of these extensions throughout my career.) Having to support non-Standard calling conventions is an example of how such complexity can propagate through the system (and as painful as that support is, at least it provides value because calling conventions are widely used).

(edited to reduce silliness)

[AlexGuteniev]

Well, it is silly question, but just wanted to be sure. I've noticed this when working on #986 .
And there are also __based pointers by the way, and they also can be 32/64 bit.

I've used them in production code.
(But sure would not expect that STL or some other library would work with them by default).

[CaseyCarter]

One person's extension is another person's technical debt. I think we should continue to not support these types in hopes that the compiler will be able to drop support for them that much sooner.

[StephanTLavavej]

We talked about this and there's consensus that this is a non-goal. Thanks for raising the question!