STL icon indicating copy to clipboard operation
STL copied to clipboard

STL: Non-standard non-reserved identifiers available via standard headers

Open frederick-vs-ja opened this issue 4 years ago • 3 comments
trafficstars

Describe the bug The C++ standard allows user-defined macros to have non-reserved names. However, MSVC STL introduces some non-standard non-reserved via standard headers, which makes user-defined macros with such names able to paralyze the MSVC STL implementation.

The list of names may be incomplete:

  • stdext related:
    • <xhash>, <iterator> (also used in <yvals_core.h>): stdext
    • <unordered_map>, <unordered_set> (ultimately, <xhash>): hash_compare
    • <iterator>: checked_array_iterator, unchecked_array_iterator, make_checked_array_iterator, make_unchecked_array_iterator (related: #951)
  • TR1 related (#183, #1002):
    • <random>: linear_congruential, subtract_with_carry, mersenne_twister, discard_block, uniform_int, uniform_real
  • Miscellaneous
    • <typeinfo> (ultimately, <vcruntime_typeinfo.h>): raw_name (#2195)
    • ~<chrono> (ultimately, <xtimec.h>): xtime_get, xtime, sec, nsec~ (related: #274) this is fixed except for the symbol name xtime_get

May be all of them shoud be either removed or have their names changed to reseved identifiers in vNext.

The namespace tr1 and some non-standard names inside it are not counted as they are guarded by _HAS_TR1_NAMESPACE. Can we handle some stdext components like tr1 before vNext arrives?

Command-line test case

C:\Temp>type repro.cpp
#define raw_name                      delete // <vcruntime_typeinfo.h>, via <typeinfo>

#define xtime_get                     delete // <xtimec.h>, via <chrono>, <xthreads.h>, <thread>, <mutex>, <condition_variable>
#define xtime                         delete // same as above
#define sec                           delete // same as above
#define nsec                          delete // same as above

#define stdext                        delete // <xhash>, <yvals_core.h>, via <iterator>

#define hash_compare                  delete // <xhash>, via <unordered_map>, <unordered_set>

#define checked_array_iterator        delete // <iterator>
#define unchecked_array_iterator      delete // <iterator>
#define make_checked_array_iterator   delete // <iterator>
#define make_unchecked_array_iterator delete // <iterator>

#define linear_congruential           delete // <random>
#define subtract_with_carry           delete // same as above
#define mersenne_twister              delete // same as above
#define discard_block                 delete // same as above
#define uniform_int                   delete // same as above
#define uniform_real                  delete // same as above

#include <typeinfo>
#include <chrono>
#include <unordered_map>
#include <random>
#include <iterator>

int main()
{
}

C:\Temp>cl /EHsc /W4 /WX /std:c++17 .\repro.cpp
用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.29.30133 版
版权所有(C) Microsoft Corporation。保留所有权利。

repro.cpp
(omitted for short)
C1003: 错误计数超过 100;正在停止编译

Expected behavior This program should compile.

STL version Microsoft Visual Studio Community 2019 版本 16.11.2

Additional context The MS CRT also provides some non-standard non-reserved names (e.g. fread_s). I don't know whether such issue has been reported or how to report it.

frederick-vs-ja avatar Sep 16 '21 07:09 frederick-vs-ja

<future> includes <ppltasks.h> and thus drags a bunch of (more than 60) non-Standard non-reserved identifiers in.

frederick-vs-ja avatar Mar 26 '23 11:03 frederick-vs-ja

As an aside, the Standard Library Modules are the first way to avoid this problem.

StephanTLavavej avatar Mar 27 '23 07:03 StephanTLavavej

🙀<arm64_neon.h> (usage added in #2127) is extremely problematic. It drags in thousands of pretty names.

Edit: this is resolved by #4695!

frederick-vs-ja avatar May 20 '23 15:05 frederick-vs-ja