I'm using clang 13.0.0 in a CMAKE-based project, CMAKE_CXX_STANDARD is defined as 20. The following code causes a compilation error (no type named 'u8string' in namespace 'std'):
#include <iostream>
#include <string>
int main() {
#ifdef __cpp_char8_t
std::u8string sss = u8"a"; // <---- this branch is picked up
#else
std::string sss = "b"
#endif
return 0;
}
Below is the CMakeLists.txt:
cmake_minimum_required(VERSION 3.20)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_C_COMPILER clang)
set(CMAKE_CXX_COMPILER clang++)
project(clang_test)
add_executable(clang_test main.cpp)
Am I missing something or is it a clang bug? I mean, if std::u8string is not yet there, the macro shouldn't be defined, right? By the way, if you know the way to undefine it somehow with the CMake, please, share your experience. Here the topic starter faces the same problem, I think, but there is no solution proposed yet.
Update: the platform is RHEL 8.4
Update 2: moved the 'project' call below the compiler settings in the CMakeLists.txt
Frank's suggestion was correct - the problem is in that Clang was using an older version of libstdc++ and not libc++;
target_compile_options(clang_test PRIVATE -stdlib=libc++)
fixes the issue for me. Though I don't entirely understand why it doesn't work with libstdc++, if you have any idea, please, share it here - I assume that this is a separate question.
Also, Tsyvarev's point is indeed a very important one, and the compiler should be set before the project call. I've corrected the example in my question.
Update: Finally I understand the reason why it fails: __cpp_char8_t is not sufficient for std::u8string, __cpp_lib_char8_t should be used instead.
Thanks everyone for your help!
Related
These days I was fiddling with a project study for a data model with a kind of reflection suitable to my needs.
While I got my first study running with the recent stable version of g++, I failed in Visual Studio 19. Too bad, because the latter is my primary platform…
Effectively, I try to store a pointer to member variable into another static member variable. Thereby, it's really desirable for me to do this inline (to fit into my bigger concept).
I reduced the failing detail to the following MCVE:
struct Field { };
struct Class {
template <typename CLASS>
struct BuiltInInfoT {
Field CLASS::*const pField; // member pointer
};
};
struct Object: Class {
Field field1;
static inline BuiltInInfoT<Object> field1BuiltInfo = { &Object::field1 };
};
int main()
{
Object obj;
}
Puzzled that this seems to work in g++ but not in MSVC, I had a look on Compiler Explorer what other compilers say about this. So, I found that recent clang and even the recent ICC (I never used before) accept this.
Live Demo on Compiler Explorer
I tried the same with an even simpler previous example where I didn't use any templates:
#include <iostream>
struct Test {
struct Info { int Test::*p; };
int a;
static inline Info infoA = { &Test::a };
int b;
static inline Info infoB = { &Test::b };
Test(int a, int b): a(a), b(b) { }
};
#define DEBUG(...) std::cout << #__VA_ARGS__ << ";\n"; __VA_ARGS__
int main()
{
DEBUG(Test test(123, 456));
DEBUG(std::cout << (test.*(test.infoA.p)) << '\n');
DEBUG(std::cout << (test.*(test.infoB.p)) << '\n');
}
The result is the same: g++, clang, and ICC compile this fine but MSVC complains.
Live Demo on Compiler Explorer
So, now I'm a bit uncertain.
Is it a bug of MSVC that might be worth to be reported? Or am I expecting something I should not rely on?
Disclaimer:
Of course, I googled this topic the last 3 days and found zillions of tutorials about how to use a member pointer – including the answer to SO: What is the meaning of this star (*) symbol in C++? — Pointer to member I've written myself. Maybe, I was missing the essential keyword but I promise I really tried hard.
In case, you're wondering what I'm trying to do…
The actual project study as Live Demo on coliru from which I made my above MCVE.
Update:
After a long discussion, #doug helped me to find out that this seems to be subject of the Visual Studio property settings. With a clean started project, I got all the above mentioned samples running in my local VS 2019. (Before, I used CMake-generated projects as usual.) I will compare the options of two resp. VS projects to find out the significant difference and post an update if I found something…
#doug gave me the hint that he got my code running in VS 2019 without any complaints.
After a long chat, he gave me the hint to test my above samples in a new created VS solution. All I had to do, was to enable C++17 (/std:c++17) and then MSCV compiled all the samples without complaints.
I must admit that I usually use CMake to prepare the VS solutions:
project (OFM)
cmake_minimum_required(VERSION 3.10.0)
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
include_directories("${CMAKE_SOURCE_DIR}")
file(GLOB sources *.cc)
file(GLOB headers *.h)
add_executable(testOFM
${sources} ${headers})
So, I had to find the relevant difference in the VS project settings.
Finally, I found it:
the VS created project contains /permissive-
the CMake created project doesn't.
In the projects settings, it is
- C/C++
- Language
- Standards conformance: Yes (/permissive)
The MS online doc.:
/permissive- (Standards conformance)
Specify standards conformance mode to the compiler. Use this option to help you identify and fix conformance issues in your code, to make it both more correct and more portable.
That's exactly what I want: to be standard conform and portable.
Adjusting this option in my CMake generated project, I got it compiled and running as well.
The demos on Compiler Explorer compiled properly (with the sufficient command line arguments):
Live Demo on Compiler Explorer
Live Demo on Compiler Explorer
and even the initial study (where my trouble started from):
Live Demo on Compiler Explorer
What I wonder: When I wrote my CMake script I already used
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
with the exact intention to be standard conform and portable.
So, there seems to be something else I have to setup in CMake.
(The last resort could be a platform-specific setting but I will investigate to find something else if possible.)
Concerning my problem, I found
CMake Issue #17068:MSVC toolset 14.1+: Set /permissive- when CXX_EXTENSIONS==OFF?
After I have fixed my CMake script with a compiler specific option:
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
if (MSVC)
add_compile_options(/permissive-)
endif()
and generated my VS solution / projects again the code compiled without any complaints as well.
#Scheff has identified a problem likely to affect others re inline static member initialization. It's particularly problematic as it differently affects compiler explorer c++17 defaults v MSVC IDE c++17 defaults. See his answer and analysis:
Using the default c++ settings (c++14) for MSVC which doesn't allow inline static members.
Change the setting to c++17 or higher. This is the usual cause of inline static initialization on the same line.
However, after chat, it turns out c++17 is being used but the difference is that it's being used with CMake. Apparently there is a difference between CMake and an MSBuild solution/project file. The latter works, the former doesn't. Under investigation and will update with results.
I am new to CMake projects and I want to use the file system library in my project. I am running Ubuntu 18.04 with GCC 8.2 and CMake 3.13. In order to achieve this I tried two options:
Option 1
cmake_minimum_required(VERSION 3.13)
project(TheFsProject)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_FLAGS "-std=c++17 -lstdc++fs")
This does not help as the compiler still cannot find the file system
library during compile time.
Option 2 (copied from:
https://www.scivision.co/cmake-cpp-17-filesystem/)
make_minimum_required(VERSION 3.13)
project(TheFsProject)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_REQUIRED_FLAGS -std=c++17)
include(CheckCXXSymbolExists)
CHECK_CXX_SYMBOL_EXISTS(std::filesystem::path::preferred_separator cxx17fs)
if(cxx17fs)
add_executable(TheFsProject main.cpp)
set_property(TARGET TheFsProject PROPERTY CXX_STANDARD 17)
endif()
This does not help either as I get a CMake error which I don't
understand.
(CHECK_CXX_SYMBOL_EXISTS):
CHECK_CXX_SYMBOL_EXISTS Macro invoked with incorrect arguments for macro named: CHECK_CXX_SYMBOL_EXISTS
I feel out of my depth on this topic which is why I came here. I don't mind putting extra work into finding out more but I don't know anymore where to look. Any help would be appreciated!
EDIT 1
Thanks for the replies so far! I made Option 3 based on your feedback:
cmake_minimum_required(VERSION 3.13)
project(TheFsProject)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(TheFsProject main.cpp)
target_link_libraries(TheFsProject stdc++fs)
Sadly it doesn't fix my problem. It still issues an error during compilation that it can't find the compilation header.
EDIT 2
Thanks for all the replies so far. All of these help. I tried Ashkan his answer last (because it seemed intimidating). This one returns
Compiler is missing file system capabilities.
so I'm guessing something is wrong on that end. This is useful in the sense that I now know it's probably not due to my CMake file. I now have to find out why the compiler does support the file system header though...
EDIT 3
Strictly speaking this question is answered because my question is about the CMake file. I am going to mark Ashkan his answer as the solution simply because it produced the next step in my troubleshooting search. If I could I would also mark lubgr his answer because I think that's a really good answer as well. Thanks everyone!
Gcc 8.2. comes with <filesystem>, so there is no need to investigate with regard to the availability. Next, option 1 is sufficient, but needs a fix:
set(CMAKE_CXX_STANDARD 17) # no need to manually adjust the CXXFLAGS
add_executable(yourExecutable yourSourceFile.cpp)
target_link_libraries(yourExecutable stdc++fs)
This should result in compiling the sources with -std=c++17 or -std=gnu++17 and adding -lstdc++fs when linking.
Edit: Note that as #Ashkan has pointed out in the comments, setting CMAKE_CXX_STANDARD_REQUIRED to true results in an immediate error at configure time if C++17 isn't supported by the compiler, instead of a compilation error (due to the missing <filesystem> header) or at link time (due to the missing shared library). This might be desirable.
Besides from #lubgr's answer. I think a more complete way is to also do try_compile to see that you can actually use the filesystem header. This in my opinion is better because some compilers are not supporting std::filesystem yet. Also in gcc 7.x you have the filesystem under experimental namespace. This way you can have a separate try_compile in the else clause and detect that.
Here is the related cmake for it
# set everything up for c++ 17 features
set(CMAKE_CXX_STANDARD 17)
# Don't add this line if you will try_compile with boost.
set(CMAKE_CXX_STANDARD_REQUIRED ON)
# test that filesystem header actually is there and works
try_compile(HAS_FS "${CMAKE_BINARY_DIR}/temp"
"${CMAKE_SOURCE_DIR}/tests/has_filesystem.cc"
CMAKE_FLAGS -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_STANDARD_REQUIRED=ON
LINK_LIBRARIES stdc++fs)
if(HAS_FS)
message(STATUS "Compiler has filesystem support")
else()
# .... You could also try searching for boost::filesystem here.
message(FATAL_ERROR "Compiler is missing filesystem capabilities")
endif(HAS_FS)
The file tests/has_filesystem.cc is very simple
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
fs::path aPath {"../"};
return 0;
}
You could in your else clause try_compile for boost::filesystem and pass a directive that can be used in your source file where you decide if you want to use c++17 filesystem or boost.
CHECK_CXX_SYMBOL_EXISTS takes three arguments, not two:
include(CheckCXXSymbolExists)
check_cxx_symbol_exists(std::filesystem::path::preferred_separator filesystem cxx17fs)
You forgot to tell CMake where to look for the symbols (the header that declares them).
I have found a case when try_compile was not enough: when using the Intel C++ compiler (icpc (ICC) 19.1.1.216 20200306) in C++17 mode running on MacOS "Mojave" 10.14.6. The test program recommended by #Ashkan compiled without errors, and it even ran. However, my code uses fs::path::filename() at one point and that resulted in a runtime linker error (dyld: lazy symbol binding failed: Symbol not found:). In other words: the header is there, the implementation apparently isn't (?). I didn't investigate this any further.
The solution is to use try_run instead of try_compile and (in my case) fall back to boost::filesystem if std::filesystem is not yet supported.
Here is the relevant CMake code section:
try_run(RUNS_WITH_STDFS COMPILES_WITH_STDFS
"${CMAKE_BINARY_DIR}/try"
"${CMAKE_SOURCE_DIR}/cmake/has_stdfs.cc"
CMAKE_FLAGS CMAKE_CXX_STANDARD=17 CMAKE_CXX_STANDARD_REQUIRED=ON
)
if (RUNS_WITH_STDFS STREQUAL "FAILED_TO_RUN")
message(STATUS "Using boost::filesystem instead of std::filesystem")
set(_boost_components ${_boost_components} filesystem system)
add_definitions(-DUSE_BOOST_FILESYSTEM)
else()
message(STATUS "std::filesystem supported")
endif()
Note that the variable RUNS_WITH_STDFS is not set to NO in case of failure but to "FAILED_TO_RUN" which is not interpreted as a FALSE Boolean (see CMake if() docs:
if() True if the constant is 1, ON, YES, TRUE, Y, or a
non-zero number. False if the constant is 0, OFF, NO, FALSE, N,
IGNORE, NOTFOUND, the empty string, or ends in the suffix -NOTFOUND.
so I had to string-compare its value.
The little test program also changed a bit compared to #Ashkan's solution:
// == PROGRAM has_stdfs.cc ==
// Check if std::filesystem is available
// Source: https://stackoverflow.com/a/54290906
// with modifications
#include <filesystem>
namespace fs = std::filesystem;
int main(int argc, char* argv[]) {
fs::path somepath{ "dir1/dir2/filename.txt" };
auto fname = somepath.filename();
return 0;
}
I'm trying to launch the example code from aligned alloc:
#include <cstdio>
#include <cstdlib>
int main()
{
int* p1 = static_cast<int*>(std::malloc(10*sizeof *p1));
std::printf("default-aligned address: %p\n", static_cast<void*>(p1));
std::free(p1);
int* p2 = static_cast<int*>(std::aligned_alloc(1024, 1024));
std::printf("1024-byte aligned address: %p\n", static_cast<void*>(p2));
std::free(p2);
}
My compilers give me this error:
$ g++-mp-8 main.cpp -std=c++17
main.cpp:10:38: error: no member named 'aligned_alloc' in namespace 'std'
int* p2 = static_cast<int*>(std::aligned_alloc(1024, 1024));
I am working with macOS High Sierra 10.13.6 and tried to compile this code with Macport's GCC 7.3.0, 8.2.0 and CLang (Apple LLVM version 10.0.0), they all produce the same error.
Edit: It doesn't work with either std:: present or not.
Edit2: I installed macOS Mojave and that did not fix the problem. I hoped it'll reinstall macOS's toolchain but it didn't. So I guess I cannot accept provided answers until I get a more specific one.
I am not using macOS but I have similar problems on linux using a custom g++. If you look at the cstdlib header, there is something like
#if __cplusplus >= 201703L && defined(_GLIBCXX_HAVE_ALIGNED_ALLOC)
using ::aligned_alloc;
#endif
So aligned_alloc is only pulled into the std namespace if C++17 is available and glibcxx supports it. You can check x86_64-linux-gnu/bits/c++config.h (or something similar on macOS) if _GLIBCXX_HAVE_ALIGNED_ALLOCis defined. If not your glibc version is too old.
For clang and the libc++ implementation aligned_alloc is available if _LIBCPP_HAS_C11_FEATURES is defined which again depends on a recent version of glibc.
As an alternative you can use boost.
As the accepted answer mentions it, using boost::align::aligned_alloc solves the problem.
To fix the error without source modification, just add the following on top of the file:
#ifdef __APPLE__
#include <boost/align/aligned_alloc.hpp>
using boost::alignment::aligned_alloc;
#endif
I'm trying to port our build system from make to CMake, and I encountered a problem that surprisingly not "Googleable"
Our code is C++ 11/14, compiles fine with GCC6.2, the make applies zillion switches when invoking GCC, mostly pedantic warnings. I built a CMake system that compiles (GCC 6.3) most of the code without a problem but some modules failed to build because of the following
flexible array member ‘blahblah’ not at end of ‘struct‘
Aside why it appears in the C++ code. Why did it compile in the make based system? AFAIK, flexible array is not a part of C++ standard. GCC specific extension? What command line switch controls FAM behavior? How do I make it compile as it did in the original make system?
In case someone needs a snippet of compiled code
struct Foo
{
int _10;
double _20;
int a[];
};
struct Bar
{
Foo foo;
double _1;
int _2;
}
To add more context, the cmake file
cmake_minimum_required(VERSION 3.9)
project(foo VERSION ${FOO_VERSION} DESCRIPTION "foo")
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_C_STANDARD 99)
add_executable(foo foo.cpp foo_backup.cpp main.cpp)
set_target_properties(foo PROPERTIES VERSION ${PROJECT_VERSION})
target_include_directories(foo PUBLIC ${CMAKE_SOURCE_DIR}/lib/include ${CMAKE_SOURCE_DIR}/lib/include/bar)
How do I make it compile as it did in the original make system
Revert to GCC 6.2. This -pedantic error was introduced for C++ in GCC 6.3.
See compilation with 6.2 and compilation with 6.3
Disabling pedantic compilation will remove the error but entail other relaxations.
I've just "upgraded" MSVC2015 to Update 2 and encountered boost::asio issue 12115...
I'm glad to say that the workaround described in boost issue 12115 i.e. removing service_has_move from line 43 of basic_io_object.hpp works fine to change:
#if defined(BOOST_ASIO_HAS_MOVE)
...
static const bool value =
sizeof(service_has_move::eval(
static_cast<service_type*>(0),
static_cast<implementation_type*>(0))) == 1;
...
#endif // defined(BOOST_ASIO_HAS_MOVE)
to
#if defined(BOOST_ASIO_HAS_MOVE)
...
static const bool value =
sizeof(eval(
static_cast<service_type*>(0),
static_cast<implementation_type*>(0))) == 1;
...
#endif // defined(BOOST_ASIO_HAS_MOVE)
I'm not a great fan of editing libraries, especially not boost!
So can someone please tell me whether this is actually a boost issue or whether the issue is MSVC2015 changing it's move behaviour in Update 2?
FYI, the original code compiled and worked fine under MSVC2015 Update 1 and MinGW 4.9.2 (on Windows 10) and GCC 5.3.1 (on Fedora) using both boost 1.60.0 and 1.61.0.
I'm currently using boost 1.61.0 but boost issue 12115 was raised on boost 1.60.0.
I think it's pretty obvious who is at fault. If you had to delete something in boost to fix this, then boost is at fault, no? The macro BOOST_ASIO_HAS_MOVE is defined based on compiler detection in the boost config header(s). Obviously when you updated, the compiler version and other info that these headers relies on was not a match, so the namespace you had to delete was not defined.