I'm trying to use boost::multiprecision::float128 (boost 1.55.0) under C++11 (gcc 4.8.1), but get the following compiler error:
/cm/shared/apps/boost/gcc/1.55.0/include/boost/multiprecision/float128.hpp: In static member function ‘static std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::float128_backend, ET> >::number_type std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::float128_backend, ET> >::min()’:
/cm/shared/apps/boost/gcc/1.55.0/include/boost/multiprecision/float128.hpp:533:55: error: unable to find numeric literal operator ‘operator"" Q’
static number_type (min)() BOOST_NOEXCEPT { return 3.36210314311209350626267781732175260e-4932Q; }
Can't I use boost::multiprecision::float128 in C++11? Or how else do I get it working?
edit
Just to clarify. This error is generated by
#include <boost/multiprecision/float128.hpp>
The compiler is not happy with the statement
return 3.36210314311209350626267781732175260e-4932Q;
in particular the Q is confusing it. I used the compiler flags -std=c++11 -fabi-version=0 -march=native -mfpmath=sse
It looks like a known issue. Try compiling with -fext-numeric-literals.
Related
We just got burnt by a typo: "constexpr bool maxDistance=10000;"
Both gcc and clang compile this with no warning.
The real error here is that the variable shouldn't have been of type bool, but should have been an integer type instead.
How can we ensure we get a compiler warning in future?
#include <iostream>
constexpr bool number = 1234;
int main(int argc, char* argv[])
{
std::cout << number + 10000 << std::endl; // prints 10001.
return number;
}
The error here is that the variable is declared with the wrong type, however neither clang nor gcc give a warning.
gcc -Wall -std=c++14 test.cpp -lstdc++
clang -Wall -std=c++14 test.cpp -lstdc++
(using gcc 5.4.0 and clang 3.8.0)
Note: I've since learnt about a possible compile flag: -Wint-in-bool-context however this doesn't appear to be implemented in the version I'm using (5.4.0) nor in clang (3.8.0).
Is this the right way to go?
You should use direct list initialization syntax, it prohibits narrowing:
constexpr bool number{1234}; // error: narrowing conversion of '1234' from 'int' to 'bool' [-Wnarrowing]
I've discovered that gcc has a flag '-Wint-in-bool-context' however this doesn't appear to be implemented in the version I'm using (5.4.0) nor in clang (3.8.0).
Is this the right way to go?
I have this code which compiles fine on Ubuntu, but when I try to compile it on MacOS I get this error:
Constexpr variable 'HeuristicNames' must be initialized by a constant expression
#define LSHPair std::pair<const char *, LISTSCHED_HEURISTIC>
static constexpr LSHPair HeuristicNames[] = {
LSHPair("CP", LSH_CP), LSHPair("LUC", LSH_LUC),
LSHPair("UC", LSH_UC), LSHPair("NID", LSH_NID),
LSHPair("CPR", LSH_CPR), LSHPair("ISO", LSH_ISO),
LSHPair("SC", LSH_SC), LSHPair("LS", LSH_LS),
LSHPair("LLVM", LSH_LLVM)};
LISTSCHED_HEURISTIC is an enum.
I take this error to mean that some part of the right hand side of the assignment is not a constexpr, so the resulting variable can't be a constexpr. However I don't have a firm enough grasp of the rules around constexpr to understand why, or how to fix it.
I also don't get why this is different on MacOS than on Ubuntu. Can anyone shed some light on this?
First of all you do not need macro.
You could define type
using LSHPair = std::pair<const char *, LISTSCHED_HEURISTIC>;
Or just use brace initialization, what is much more clean:
using LSHPair = std::pair<const char *, LISTSCHED_HEURISTIC>;
static constexpr LSHPair HeuristicNames[] = {
{"CP", LSH_CP},
{"LUC", LSH_LUC},
{"UC", LSH_UC},
{"NID", LSH_NID},
{"CPR", LSH_CPR},
{"ISO", LSH_ISO},
{"SC", LSH_SC},
{"LS", LSH_LS},
{"LLVM", LSH_LLVM}
};
As #CuriouslyRecurringThoughts point out constructor of std::pair is a constexpr since c++14.
I've test this on my Mac OS and apparently clang there works a bit differently then on Linux (as shown on compiler explorer):
Marek R$ g++ main.cpp -std=c++11
main.cpp:17:26: error: constexpr variable 'HeuristicNames' must be initialized by a constant expression
static constexpr LSHPair HeuristicNames[] = {
^ ~
main.cpp:18:5: note: non-constexpr constructor 'pair<char const (&)[3], LISTSCHED_HEURISTIC, false>' cannot be used in a constant expression
{"CP", LSH_CP},
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/utility:446:5: note: declared here
pair(_U1&& __u1, _U2&& __u2)
^
1 error generated.
Marek R$ g++ main.cpp -std=c++14
Marek R$
So MacOS clang is right.
Problem must be on header files and versioning them depending on C++ standard.
Most probably same header files of standard library are used for clang and gcc are used on Linux. On Mac std::pair constructor is prefixed by macro _LIBCPP_CONSTEXPR_AFTER_CXX11 which definition changes deeding on C++ standard enabled. On Linux you have to check by yourself how it is done.
I get an error when compile code containing <experimental/any>.
Code in main.cpp:
#include <experimental/any>
int main() { }
Compile this (clang version is 3.9):
clang++ main.cpp -o main -std=c++1z
Error after the compiling:
In file included from main.cpp:2:
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/experimental/any:364:34: error:
no template named '__any_caster'; did you mean 'any_cast'?
return static_cast<_ValueType*>(__any_caster<_ValueType>(__any));
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/experimental/any:361:30: note:
'any_cast' declared here
inline const _ValueType* any_cast(const any* __any) noexcept
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/experimental/any:372:34: error:
no template named '__any_caster'; did you mean 'any_cast'?
return static_cast<_ValueType*>(__any_caster<_ValueType>(__any));
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/experimental/any:369:24: note:
'any_cast' declared here
inline _ValueType* any_cast(any* __any) noexcept
^
2 errors generated.
As #chris mentioned in the comments:
You could try with libc++. Perhaps there's an incompatibility with Clang in libstdc++'s new header.
This turns out to be true. Clang 3.9 is still experimental, and so it uses experimental headers, including a experimental C++ standard library. By default, it is provided by GCC, and so an incompatibility occurs between the GCC implementation and the Clang implementation.
I have a header, core/types.hh, used by several different build targets. It has the following declaration:
core/types.hh
typedef std::size_t Size;
static const Size SZ_MAX = std::numeric_limits<Size>::max();
...
Some of the targets use this constant, some don't. So I get:
error: 'core::SZ_MAX' defined but not used"
I use scons with GCC 4.7.3 on Linux. I have -Wall set and want to keep it that way.
As far as I understand from the GCC documentation, this shouldn't give a warning:
-Wunused-variable
Warn whenever a local variable or non-constant static variable is unused aside from its declaration. This warning is enabled by -Wall.
So I don't see why I get a warning (which turns into an error).
On other answers, people were advised to make the declaration extern and to do the assignment in the file that uses the constant. This file is used by many other files, so it would loose its constant-ness if I do that. Furthermore, this file has header guards, so I think this should mean that the constant is actually created only once.
I'd appreciate any help!
Yuval
Possible duplicates:
How to use typed constants with “unused variable” warnings?
c++ static array declared in h file gives warning 'defined but not used'
It seems that this was not the error that halted compilation.
Rather, if GCC find another error, it would still report on this too.
I actually had another unused variable, and that's what caused this error in the first place.
For example, when creating the following files:
file1.cc
#include "head1.hh"
int main() {
int bad_unused_variable;
return my_ns::JUST_ANOTHER_CONST;
}
head1.hh
#ifndef HEAD1
#define HEAD1
#include <stdint.h>
#include <cstddef>
#include <limits>
namespace my_ns {
typedef std::size_t Size;
static const Size SZ_MAX = std::numeric_limits<Size>::max();
static const Size JUST_ANOTHER_CONST = 8;
}
#endif
You get:
> g++ -Wall -Werror file1.cc -O2 -std=c++98 -o file1
file1.cc: In function 'int main()':
file1.cc:4:6: error: unused variable 'bad_unused_variable' [-Werror=unused-variable]
In file included from file1.cc:1:0:
head1.hh: At global scope:
head1.hh:10:20: error: 'my_ns::SZ_MAX' defined but not used [-Werror=unused-variable]
cc1plus: all warnings being treated as errors
EDIT
This also seems to have been answered here: gcc warnings: defined but not used vs unused variable - there they mention the subtle differences between the two warning messages (unused variable vs defined but not used). Still, it doesn't really answer as to why GCC behaves this way...
I try to compile the simple code
#include <atomic>
int bar = 0;
void foo(std::atomic<int>&flag)
{ bar = flag; }
with clang++ 3.2 (downloaded as llvm 3.2 from llvm.org; on mac os.x 10.8.3 this fails with the error
/> clang++ -std=c++11 -stdlib=libc++ -O3 -march=native -c test.cc
In file included from test.cc:1:
/usr/include/c++/v1/atomic:576:17: error: first argument to atomic operation must be a pointer to non-const _Atomic type ('const _Atomic(int) *' invalid)
{return __c11_atomic_load(&__a_, __m);}
^ ~~~~~
/usr/include/c++/v1/atomic:580:53: note: in instantiation of member function
'std::_1::_atomic_base::load' requested here
operator _Tp() const _NOEXCEPT {return load();}
^
test.cc:5:9: note: in instantiation of member function 'std::_1::_atomic_base::operator int' requested here
bar = done;
When I use /usr/bin/clang++ instead (which comes with the OS or Xcode) it compiles just fine. The libc++ is that at /usr/lib/c++/v1 in both cases.
What am I missing? Is there another libc++ that comes with llvm 3.2 but which I'm missing? (I cannot find anything in the clang3.2 tree).
Xcode now bundles libc++ within the Xcode.app directory. You can inspect this directory by control-clicking Xcode.app and choose "Show Package Contents".