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
Related
NOTE: this does not fail to #include <filesystem>. It fails afterward.
I’m on a macOS 10.15, using clang 11. Output of clang --version:
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
When I try to compile something simple like:
#include <filesystem>
using namespace std;
filesystem::path dev_dir;
int main() {
dev_dir = "/dev/";
return 0;
}
The compiler does find the filesystem library, but doesn’t recognize the namespace:
$clang trigger_controller.cpp -o trigger_controller
trigger_controller.cpp:##:##: error: use of undeclared identifier 'filesystem'
filesystem::path dev_dir;
This is the file I believe I’m trying to include (which I’ve confirmed exists):
// /usr/local/include/c++/9.2.0/filesystem
#ifndef _GLIBCXX_FILESYSTEM
#define _GLIBCXX_FILESYSTEM 1
#pragma GCC system_header
#if __cplusplus >= 201703L
#include <bits/fs_fwd.h>
#include <bits/fs_path.h>
#include <bits/fs_dir.h>
#include <bits/fs_ops.h>
#define __cpp_lib_filesystem 201703
#endif // C++17
#endif // _GLIBCXX_FILESYSTEM
What am I doing wrong? Are there specific compiler options I need? Is the namespace wrong?
Yes, there are specific compiler options you need. Notice that the entire contents of this header, apart from boilerplate, are wrapped in an #if __cplusplus >= 201703L ... #endif block. That means the header is effectively empty unless the compiler declares conformance with the 2017 revision of the C++ standard (or later).
For clang and gcc, standards conformance level is controlled with the command line option -std. GCC's documentation for this option is here; I don't know where to find clang's documentation, but clang generally tries to be command-line compatible with gcc, so the same options should work.
In this case, the exact option you should use is -std=gnu++17 for C++ 2017. As of this writing, support for newer revisions of the C++ standard is still "experimental" and "will almost certainly change in incompatible ways", so I would avoid it. I also recommend you avoid the hyperconformant variant of this mode, -std=c++17, because it has a good chance of exposing bugs in MacOS system headers.
Having this error using c++17 on Mac OS.
As far as I can tell, code is correct and should work fine (compiles without issue w/ g++ and clang++ on linux).
Also, as far as I can tell, the current default mac version of clang [10.0.1] should support c++17 (full version info printout below).
So, my question is: is this actually a bug in my code, but it works by fluke on linux? Or is it an issue with MacOS clang e.g., not full c++17 implementation?
From cppref:
Defined in header (since C++17):
int abs( int n );
Other c++17 features seem to work completely fine.
#include <cmath>
// #include <cstdlib> //works if included
int main() {
int i = 1;
// return std::abs(1); // Works fine
return std::abs(i); // Fails
}
Compile with:
clang++ -std=c++17 test.cpp
Get this error:
test.cpp:7:10: error: call to 'abs' is ambiguous
return std::abs(i);
^~~~~~~~
/Library/Developer/CommandLineTools/usr/include/c++/v1/math.h:761:1: note:
candidate function
abs(float __lcpp_x) _NOEXCEPT {return ::fabsf(__lcpp_x);}
^
(... etc.)
1 error generated.
If you #include <cstdlib>, it works without error.
using -std=gnu++17 or -std=c++1z doesn't remove the problem either.
In the actual code (which is obviously more complex than the above, and actually uses c++17 features), the error happens depending on the order of my include files.
I can't replicate that in the simple example, but I assume it boils down to calling the cstdlib version instead of the cmath version.
Currently, my 'workaround' is to just put the header includes into the order that works..but this is hardly a long-term solution.
Does anyone know the cause?
Version info (error not specific to this MacOS version, also happens on my students' laptops):
Bens-iMac:test ben$ clang++ -v
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
See LWG Issue 2912
This has been fixed in libc++ trunk. I don't know if Apple has shipped this fix yet. As you found, including <cstdlib> is a workaround.
This question already has answers here:
to_string is not a member of std, says g++ (mingw)
(13 answers)
Closed 8 years ago.
I am trying to use std::to_string(), of course with #include <string>, but the compiler gives me the error that it was not declared in the scope, after lots of searching I have tried the fixes of going to compiler settings and have g++ follow... -std=c++11,
downloading 4.7 patch header files for wchar.h, stdio.h, os_defines.h
and re downloading the latest codeblocks version.
but nothing makes it seem to work.
what settings do I need to change to make this work.
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s=to_string(10);
cout <<s<<endl;
return 0;
}
update: I have re-installed codeblocks,version 13.12 tmd gcc, with gcc version 4.81(tmd-2), I have both -std=c++0 and -std=c++11 flags on in compiler settings, in Toolchain executables i have c++ compiiler:mingw32-gcc-4.8.1.exe, and it Still does not recognize to_string();
I suppose you are using the Code::Blocks MinGW distribution which includes GCC 4.7.1. The MinGW implementation of libstdc++ does not support to_string, this is a known bug which cannot be fixed by simply patching the header files. Upgrade to the latest Code::Blocks version with GCC 4.8.1.
The following simple code can't be compiled by g++ 4.3:
#include <array>
using namespace std;
int main()
{
std::array<int, 8> myarray;
return 0;
}
array: No such file or directory
Also, the compiler doesn't seen to understand option '-std=c++11' as is recommended to provide to the compiler. Is there another option?
Thanks.
GCC 4.3 and presumably also your C++ library are too old for the support you're looking for. You need a newer version. Here's a link to the GCC C++11 support page, and another link to the libstdc++ C++11 support page.
Alternatively, clang supports all of C++11 with libc++.
For me the problem was that it was a cross compiler that needed to be told where the sysroot was, and supplying --sysroot=<path to sysroot> allowed GCC to find the headers
I have a project that correctly compiles and runs under g++ 4.8.1 and clang >= 3.3 in c++11 mode. However, when I switch to the experimental -std=c++1y mode, clang 3.3 (but not g++) chokes on the <cstdio> header that is indirectly included by way of Boost.Test (so I cannot easily change it myself)
// /usr/include/c++/4.8/cstdio
#include <stdio.h>
// Get rid of those macros defined in <stdio.h> in lieu of real functions.
// ...
#undef gets
// ...
namespace std
{
// ...
using ::gets; // <-- error with clang++ -std=c++1y
// ...
}
with the following error message:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:119:11:
error: no member named 'gets' in the global namespace
On this tutorial on how to set up a modern C++ environment, a similar lookup problem with max_align_t is encountered. The recommendation there is to use a sed script to surround the unknown symbols with #ifdef __clang__ macros, but that seems a fragile approach.
Setup: plain 64-bit Linux Mint 15 with
g++ (Ubuntu 4.8.1-2ubuntu1~13.04) 4.8.1
Ubuntu clang version 3.3-3~raring1 (branches/release_33) (based on
LLVM 3.3)
Questions:
what is causing this erorr? There is no __clang__ macro anywhere near the code in question, and clang in c++11 mode has no trouble at all.
Is it a language problem (does C++14 say something else than C++11 about importing C compatible symbols from the global into the std namespace)?
Do I need to change something with my include paths? (I use CMake to automatically select the header paths, and switch modes inside CMakeLists.txt)
Does clang have a switch to resolve this?
This note in the gets manpage looks relevant:
ISO C11 removes the specification of gets() from the C language, and since version 2.16, glibc header files don't expose the function declaration if the _ISOC11_SOURCE feature test macro is defined.
Probably should be
#if !_ISOC11_SOURCE
using ::gets;
#endif