I've been trying to use the std::format function included in C++20. As far as I can tell, clang 14 is supposed to support this feature, but for some reason I am receiving the following error: no member named 'format' in namespace 'std'. According to cppreference's compiler support chart, text formatting should be supported by clang, but I'm still receiving this error. I'm at a loss for what the issue is.
std::format is not complete in libc++ 14 so is disabled by default. You need to pass the LIBCXX_ENABLE_INCOMPLETE_FEATURES parameter when building llvm to enable the feature.
You are probably better off using https://github.com/fmtlib/fmt until the libc++ implementation is complete (this'll also make your code more portable as MSVC is currently the only compiler with a complete implementation).
According to this, text formatting should be supported by clang
If you look closely, there is an asterisk in that cell:
14*
Below, it says:
* - hover over the version number to see notes
And when you hover, it says:
The paper is implemented but still marked as an incomplete feature. Not yet implemented LWG-issues will cause API and ABI breakage.
What's unsaid is that incomplete features are not enabled by default. But that makes sense since they wouldn't want users to depend on an API/ABI that will break. In my opinion, as also evidenced by this question, using green for this cell is misleading.
In conclusion, it's best to use the third party formatting library until the standard implementation of text formatting is complete, stable and non-experimental in major language implementations.
Other caveats:
You must include the header that defines std::format.
Clang doesn't use C++20 by default, so you must specify it explicitly.
Clang uses libstdc++ standard library on Linux by default (for compatibility with shared libraries), so in such case you won't be using the Clang's standard library by default, and libstdc++ hasn't implemented text formatting yet.
Related
Multiple talks have taught me that we can import <standardheaders>, but this does not seem to work at all in Compiler Explorer. In latest Clang and GCC, I just get errors, and when googling for this, I see some Microsoft documents that say it's doable, but they seem very non-standard in their approach, regrouping the headers in some vendor-specific way.
What gives?
Will we be able to do this? or it is never gonna happen in a standard way? Is it dependent on a build system doing it for us individually even though they are standard headers? Was this a planned feature that was dropped? Or was it always planned to be highly vendor specific and non-standardized, and to require a build system even for standard headers? Is there a plan to standardize at least the division of standard features so that we don't have a bunch of different vendor specific organization schemes that are different than the header scheme?
The proposal to make standard headers importable as synthesized header units is P1502.
STL says in MSVC's issue that it is feature complete for VS 2019 16.10 Preview 2.
Neither GCC documentation nor Clang documentation list their current status for P1502, but support for modules in general is "partial".
Will we be able to do this?
Presumably when the compiler / standard library implementers get to it. Until then, we can safely use #include which doesn't have drawbacks compared to synthesized header units.
I am using C++ in Xcode version 8.1. I need to use the functionality of boost::any but am strongly opposed to pulling any part of Boost into our project (let's not debate it please).
I see that std::any is "merged into C++17" here.
I want to use this in my Xcode 8.1 project. I have tried using -std=c++1z as a custom flag on the project, but I can't seem to find a header for it.
How can I use std::any or std::experimental::any in my Xcode project?
Can I download the appropriate headers from an implementation and throw them into my project's sourcecode? Or, even better, is actually available to now in my version of Xcode/Clang/C++?
You can't say "I want the default Xcode compiler [which has no support for any]" and at the same time request it to support any. You also can't mix standard library headers for different compiler versions.
You can either
use a compiler version that provides std::any or
use any third party library that provides another any-like type.
Your installation setup does not have the c++17 standard. std::any simply is not available to you unless you get a compiler with at least experimental support for what you want.
Clang Cxx Status
You'd have a lot better luck just using boost::any probably.
If you're really set on not bringing a third party library into play, the reality is that creating your own any isn't that difficult. I don't recommend reinventing the wheel but in this case it's not that difficult.
Here's a SO question with an answer showing a way to do 'any'.
It is illegal to inject new types into std via a third party library. You can upgrade your compiler, get a distinct std library your compiler supports, or use a 3rd party library that provides any in another namespace, or write your own.
The first you said no to.
The second is hard, as xcode does not advertise what its compiler actually is. There are generally two common std libraries that work with clang-llvm derived compilers; libc++ and libstdc++. That kind of swap tends to be very expensive even if the other one has the feature you want.
The third is basically "use boost" or equivalent.
The last isn't hard; a few days work (mostly bugs after the fact), based on writing types of similar complexity, assuming "good enough" is good enough (ie, not getting caught up in ideal exception guarantees, or matching standard exactly, etc). An implementation will require hyperbolic effort to approach perfection, naturally.
Xcode 9.0 beta can now be downloaded (https://developer.apple.com/download/). It supports the c++17 flag option.
Edit: Xcode 9.2 is publically available with std::any support.
In llvm's compiler implementation tutorial (e.g. here) llvm::make_unique is used. What is the reason they aren't using std::make_unique? I wasn't able to find any clear documentation on this.
TL;DR;
LLVM is written using C++11 conforming code while std::make_unique is a C++14 feature. So if they want make_unique they need to implement it.
Details
If we go to the LLVM Coding Standards the C++ Standard Versions section says:
LLVM, Clang, and LLD are currently written using C++11 conforming code, although we restrict ourselves to features which are available in the major toolchains supported as host compilers. The LLDB project is even more aggressive in the set of host compilers supported and thus uses still more features. Regardless of the supported features, code is expected to (when reasonable) be standard, portable, and modern C++11 code. We avoid unnecessary vendor-specific extensions, etc.
We can see from cppreference that std::make_unique is a C++14 feature. If they want to use make_unique then they can't use the std version.
We can see from a recent llvm-dev discussion that moving to C++14 is still an open subject.
Compiler vendors have been adopting C++11 features piecemeal, which was predictable, as many of them are not easily implemented.
The standard way for reporting which spec the compiler fully supports is via the __cplusplus predefined macro. However, major vendors are reporting __cplusplus = 199711L, meaning they are only fully supporting C++98 (eg. MSVC14). This (presumably) means that they do not fully support the C++11 spec, even though they may have implemented a lion's share of the functionality.
I would like to start using C++11 features, when they are available (and fallback to existing code when they are not). However, my code must support many compilers, including proprietary compilers which I may not have access to use. Is there any standard way to know which C++11 features are available from a compiler, without knowing specifically which compiler is being used? (if a compiler behaves in a non-standard way, then it is acceptable for the detection behavior to be incorrect).
NOTE: This question is a generalization of my question 'Availability of static_assert c++11', which was not very well received, because I think my motivation was misunderstood.
You might be interested in feature test macros, which enable you to test for specific C++11, C++14 or even C++17 features, such as __cpp_static_assert, __cpp_lib_make_unique or __cpp_variable_templates. Clang and GCC already support this, see a live demo.
g++/clang++ do not have C++11 enabled by default, not even the latest versions. Whenever you compile with g++ using -std=c++11, your macro __cplusplus will have the expected value.
VS seem to have all features enabled by default, thanks #Comic, but it is not updating the macro since it is not yet fully C++11 compliant.
As far as detecting "C++11 availability" for a generic compiler, I am not aware of any portable way of doing it, unless you check for the __cplusplus macro. But, as you observed, the macro may not be implemented for some compilers by default (as is the case for g++/clang++), or not implemented at all (VS). Your only choice at this stage seem to be an external tool like CMake, which can detect the compiler, and conditional on the compiler type CMake can then define some macro which you can check in your code to enable C++11.
I think many of the C++11 features are available on GCC 4.8 also. Compile your program with -std=c++11 option.
I think some of the C++11 features were in GCC 4.6.3 as well. Compile option to enable it -std=c++0x .
I would like to use std::array, std::regex and other things that are new in C++11.
Does clang already support C++11?
Yes but not everything. Check out this status page; it's updated very frequently. It's the current source code (work in progress) state, not the last release state, so check the version in the table to be sure it corresponds to what you have.
For standard library features, checks the links at the end of the page, depending on which context you are in.
Also, the Apache wiki includes this table summarizing C++11 features and their support in popular compilers.
The parts of C++11 that you're looking for are actually part of the standard library. If you're using the clang compiler, you'll want to use the libc++ standard library, which has support for most of C++11 and works really well with clang.