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.
Related
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.
The Filesystem Technical Specification (TS) has recently been merged into the C++17 standard.
The same TS is also available for C++14, but in this case it's technically only "experimental". However the fact that it's been approved for C++17 makes me think it's mature enough and that it can be used safely.
When working on a C++14 project that will most likely be upgraded to C++ 17 in the future, and assuming the compiler I use supports it on both versions, would you advise against using the "experimental" TS, considering that it will officially be part of the next standard?
My question of course extends to any TS that has been accepted in a future C++ version and that is available for earlier standards.
The real question is whether or not somebody's implemented it, not whether or not it's been approved/merged/whatever of some arbitrary document. Features can be excised, added or modified at any point in time of the standardization process. We've seen things get cut from C++14 right before release and also things that couldn't make it that were later amended. Vendors rely on specific versions of documents when implementing features and so the only surefire way is to consult the documentation of whatever compiler you're using.
Actual implementations can contains features that are not in the current standard, and can have flaws in other features that are defined in the standard or even can fail to implement specific parts - Microsoft was know to let parts of the standard unimplemented.
But if a compiler supports a feature, and if that feature is part of next standard, there is little risk if any that it will disappear in a future version of that particular compiler.
Simply, some other compiler may not implement it as soon as it is approved in standard, but you know whether it is a problem in you specific use case.
Is it safe to use a C++ Technical Specifications approved for a future standard in a earlier standard?
It depends on what you mean by "safe"
Is it portable?
No.
Does it work?
You need to check the release notes of your toolset's version, and the release notes of your standard library's version (they may be different).
Will it work tomorrow?
Who knows?
Should I invest time in code that assumes it works?
probably not.
In summary, the answer is "no".
Use the boost version until the standard is published and your compiler and standard library conforms to it.
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.
Very easy question but I've got so used to finding boost functionality as part of STL in C++11 that I was surprised when I couldn't see a join function.
Just to double check - it's definitely not present in C++11? Is it part of any newer versions of the C++ standard?
There is no std::join in C++11 or C++14 so you will still have to use the boost version. There is an open proposal for it N3954
Accorging to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/sd-1.htm The papper has been mailed out and is in the "Library Evolution" sub group.
Is anyone using the GCC 4.4.0 C++0x support in production? I'm thinking about using it with the latest MinGW, but I'm not sure if it's mature enough.
I'm interested in:
TR1 support
auto
initializer lists
IMHO, TR1 support and auto are safe to use. In the case of auto it was one of the first features to be included into the standard and is a relatively small change to the language. I would therefore have no problem using it.
I would be a bit more hesitant about using initializer lists. On some other forums (eg. comp.lang.c++.moderated) there are questions about their behaviour and its possible that they may change closer to the release of the standard.
I'm not using GCC 4.4.0 C++0x support in production but I'm using the TR1 features with the help of the Boost Library http://www.boost.org/.
The Boost Library is well tested and often used in production environments. If you convert to the C++0x standard later the only thing you have to do is changing your include Directives http://www.boost.org/doc/libs/1_40_0/doc/html/boost_tr1.html.
In my opinion it's currently better to use the Boost Library until the standard is finished. It's a much more compiler independent way.
MinGW simply won't compile with '-std=c++0x'. Strange enough, '-std=gnu++0x' works. Anyway it seems buggy and I won't count on it.