Upcoming removal of std::auto_ptr (in C++1z)

The upcoming C++1z (probably C++17) standard will not contain several things - most notably auto_ptr.

Soon, libc++ will not be providing auto_ptr by default when building in C++1z mode.
You’ll be able to get it back with a
“-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR” on your command line, or “#define _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR” before including any libc++ header files.

Grepping through the LLVM code base, I found several references to auto_ptr that should be investigated. Most, if not all of them are in test cases.

Tests that reference auto_ptr

llvm/test/CodeGen/X86/negate-add-zero.ll
llvm/test/Transforms/DeadStoreElimination/2011-09-06-EndOfFunction.ll
llvm/test/Transforms/MemCpyOpt/loadstore-sret.ll

Things that define their own auto_ptr

llvm/tools/clang/test/Analysis/diagnostics/Inputs/include/report-issues-within-main-file.h
llvm/tools/clang/test/Analysis/diagnostics/report-issues-within-main-file.cpp
llvm/tools/clang/test/CodeGenCXX/2010-07-23-DeclLoc.cpp

clang-tidy bits that reference auto_ptr

llvm/tools/clang/tools/extra/clang-tidy/modernize/ReplaceAutoPtrCheck.cpp
llvm/tools/clang/tools/extra/clang-tidy/modernize/ReplaceAutoPtrCheck.h
llvm/tools/clang/tools/extra/docs/clang-tidy/checks/modernize-use-emplace.rst
llvm/tools/clang/tools/extra/include-fixer/find-all-symbols/STLPostfixHeaderMap.cpp
llvm/tools/clang/tools/extra/test/clang-tidy/Inputs/modernize-replace-auto-ptr/memory.h
llvm/tools/clang/tools/extra/test/clang-tidy/modernize-replace-auto-ptr.cpp
llvm/tools/clang/www/analyzer/potential_checkers.html

The first three files should be investigated.
I believe that the second group should not be affected by this change.
The third group (the clang-tidy changes) probably will not be affected.

– Marshall

Thanks Marshall,

Regarding the first group - these are all LLVM IR-level optimizer tests, so they don’t actually care about what a particular version of C++ does or does not contain.

Thanks,
Michael

Purely for my own edification, is the rationale for this available somewhere?

Thank you,

Steve

According to [1] it has been deprecated since C++11 and using unique_ptr should be prefered.

Cheers,
  Roel

[1] auto_ptr - C++ Reference

>
> The upcoming C++1z (probably C++17) standard will not contain several
things - most notably auto_ptr.

Purely for my own edification, is the rationale for this available
somewhere?

Here is a draft of the paper <https://isocpp.org/files/papers/N4190.txt&gt;
which removed it.

The short and sweet rational for it is that auto_ptr was designed before
C++ had move semantics.
and because of that it doesn't behave like a move-only type should and is
unsafe because of it.

Landed as revision 292986.

-- Marshall

Thanks! Makes perfect sense.

Will LibC++ still enable ‘auto_ptr’ when ‘-std=c++[98|11|15]’ are chosen? I assume that it will. If ‘auto_ptr’ is entirely in the headers, I don’t see any problems, but if some support is in the library, how should the library itself be built so that a single library build supports all of the Standards? Will we need to provide Multilib builds of the libraries for C++17 versus its predecessors?

Thanks,

MartinO

Will LibC++ still enable ‘auto_ptr’ when ‘-std=c++[98|11|15]’ are
chosen? I assume that it will. If ‘auto_ptr’ is entirely in the
headers, I don’t see any problems, but if some support is in the library,
how should the library itself be built so that a single library build
supports all of the Standards? Will we need to provide Multilib builds of
the libraries for C++17 versus its predecessors?

There will never be a need for multilib builds of Libc++ for different
dialects.

/Eric

Thanks Eric, the assurance that there will never be a need for a MultiLib build is more comforting than you might guess J, and to me, it is further weight against the incumbent.

So from that, I would like to expand - with an out-of-tree - CMake “incompatible” library cross-compiler, what flags should I pass while building LibC++? Usually I follow whatever ‘buildit’ recommends, but ‘buildit’ looks likely to be removed soon.

Thanks,

MartinO

Thanks Eric, the assurance that there will never be a need for a MultiLib
build is more comforting than you might guess J, and to me, it is further
weight against the incumbent.

It would be really unfortunate if different dylibs were needed for
different dialects. :slight_smile:

So from that, I would like to expand - with an out-of-tree - CMake
“incompatible” library cross-compiler, what flags should I pass while
building LibC++? Usually I follow whatever ‘buildit’ recommends, but ‘
buildit’ looks likely to be removed soon.

That's unfortunate that you can't use the CMake build. The reason buildit
is getting removed is it is unmaintained, so it's "recommendations" are way
out of date. I would suggest configuring CMake with a "compatible compiler"
as closely as possible to your real build, and then simply inspect the
flags it passes. Off the top of my head the important compile flags are:

-nostdinc++
-D_LIBCPP_BUILDING_LIBRARY
-DLIBCXX_BUILDING_LIBCXXABI (Assuming your building against libc++abi).

The linker flags are much more complex, so I won't attempt to enumerate the
possibilities here.

/Eric

Hi Eric,

Yes I have incorporated this, and I can happily say that we now have LibC++ building and testing fine. We don’t use ‘libc++abi’ as it happens, though I do pull in elements for RTTI support (‘private_typeinfo’).

You don’t even want to think about our multicore linking without taking a big sedative first :wink:

Thanks again you your help, and sorry about the long delay responding,

MartinO