I am trying to use tgamma() from the standard library. When I try to compile, I get the error message:
Call to undefined function tgamma
I have the directive #include <cmath>. I use Embarcadero C++ Builder XE3, which claims to support C++11 standards. What could be my problem, and how to fix it?
Boost contains a tgamma function.
#include <boost/math/special_functions/gamma.hpp>
...
double rootPi = boost::math::tgamma<double>(0.5);
Of course, you can always switch to a different compiler, like gcc.
Related
I am writing a class that inherits from std::vector (*) and I want to be able to construct it in all the ways that are available for its base, so I use
#include <vector>
struct B : public std::vector<double>
{
using std::vector<double>::vector;
};
This compiles fine with the g++ and clang, but the Intel compiler gives me (with flag -std=c++11)
error: function template "B::B(_ForwardIterator, _ForwardIterator, const std::__1::allocator<double> &)" already inherited from "std::__1::vector<double, std::__1::allocator<double>>"
at the using directive.
Any ideas why this is happening and/or how to solve it?
Update: it would seem this is OS dependent, works fine on Linux and Windows platforms but fails on OS X. A discussion is ongoing on the Intel forums.
(*) I don't want to use polymorphism, please avoid "this is bad practice" answers if not directly relevant - there are in fact numerous posts that agree this is acceptable.
I'm using a GCC extension rope to store pairs of objects in my program and am running into some C++11 related trouble. The following compiles under C++98
#include <ext/rope>
typedef std::pair<int, int> std_pair;
int main()
{
__gnu_cxx::rope<std_pair> r;
}
but not with C++11 under G++ 4.8.2 or 4.8.3.
What happens is that the uninitialised_copy_n algorithm is pulled in from two places, the ext/memory and the C++11 version of the memory header. The gnu_cxx namespace is pulled in by rope and the std namespace is pulled in by pair and there are now two identically defined methods in scope leading to a compile error.
I assume this is a bug in a weird use case for a rarely used library but what would be the correct fix? You can't remove the function from ext/memory to avoid breaking existing code and it now required to be in std. I've worked around it using my own pair class but how should this be fixed properly?
If changing the libstdc++ headers is an option (and I asked in the comments whether you were looking for a way to fix it in libstdc++, or work around it in your program), then the simple solution, to me, seems to be to make sure there is only one uninitialized_copy_n function. ext/memory already includes <memory>, which provides std::uninitialized_copy_n. So instead of defining __gnu_cxx::uninitialized_copy_n, it can have using std::uninitialized_copy_n; inside the __gnu_cxx namespace. It can even conditionalize this on C++11 support, so that pre-C++11 code gets the custom implementation of those functions, and C++11 code gets the std implementation of those functions.
This way, code that attempts to use __gnu_cxx::uninitialized_copy_n, whether directly or through ADL, will continue to work, but there is no ambiguity between std::uninitialized_copy_n and __gnu_cxx::uninitialized_copy_n, because they are the very same function.
I want to use my school custom library in a C++ project but the library linking seems not working... When I create my program in C and I try to compile it, it work...
See by yourself:
I think that the X11 and/or Xext libraries dependencies of the Mlx are in cause, there can be some
#if __cplusplus
void *x11_mlx_function_wanted(void);
#endif
I had already check if the mlx contains some check like that and I saw nothing.
Thank you in advance
EDIT
And I succeed in objective-c.
The problem is C++ name-mangling. If you declare a function in C11, it ends up with a "mangled" name, which encodes the namespace and the types of the arguments. That's necessary because in C++, various overloads can exist for the same function name. The overloads are independent functions; they do not even have to be in the same object library.
In the object library itself, the functions will have ordinary C names. But since the header file is processed with a C++ compiler, the declared functions will be named as though they were C++ functions.
One possible solution might be to declare all the included functions to be C functions:
extern "C" {
#include "/usr/X11/include/mlx.h"
}
I installed gcc4.9 using the steps mentioned in the SO post here. I was using the latest feature std::exchange() utility function which is introduced in C++14.
#include<list>
#include<utility>
int main() {
std::list<int> lin{5,6,7,8,9};
auto lout = std::exchange(lin, {1,2,3,4});
return 0;
}
I performed following steps to compile the above sample program and got the following compilation error. After sometime I realized that (as there is no warning/hint by compiler message) this feature has been added in the C++14 standard so I need to use -std=c++1y here.
$g++ -std=c++11 main.cpp
main.cpp: In function ‘int main()’:
main.cpp:5:14: error: ‘exchange’ is not a member of ‘std’
auto lout = std::exchange(lin, {1,2,3,4});
^
If we use the C++11 standard feature and does not provide -std=c++11, then GCC gives warning message/hint that your program is using the feature which is introduced in the C++11 as below:
main.cpp:4:21: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11
std::list<int> lin{5,6,7,8,9};
This message is great and lets the user distinguish between the actual compilation error message and not including -std=c++11 option.
However while using gcc4.9 for C++1y feature under -std=c++11, there is no such warning message/hint? I wanted to know what could be the possible reason for this?.
The error/warning about "extended initializer lists" is emitted by the C++ parser. The C++
parser apparently knows how to parse that syntactic construct, understands it and can
provide a sensible error/warning message.
With the function, the situation is a little bit different. The GCC proper does not
contain knowledge about each and every standard function. For some functions it does, but
for most functions it doesn't.
From the compiler proper point of view, std::exchange is just an unknown identifier, the compiler does not contain special knowledge about the standard function std::exchange, and, hence, treats it as any other unknown identifier.
Hey guys,
This could be a noob question, but I really can't find any useful solution through Google.
I'm testing a hello world with boost.asio, the program is quite simple:
#include <iostream>
#include <boost/asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
int main()
{
boost::asio::io_service io;
boost::asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.wait();
std::cout << "Hello, world!\n";
return 0;
}
I passed the compilation and run well on my Intel Pentium PC (Ubuntu 10.10, gcc 4.4.5, Boost 1.46.0). The command line I used was
g++ -o a a.cpp -I /Boost-Include-Path/ -L /Boost-lib-Path/ -lboost_system
But when I compile the same code on another machine(which is a big one, I'll explain it later), it can't pass the compilation and gives such errors:
/tmp/ccOZxZBX.o: In function boost::asio::detail::gcc_sync_fenced_block::gcc_sync_fenced_block()': a.cpp:(.text._ZN5boost4asio6detail21gcc_sync_fenced_blockC1Ev[boost::asio::detail::gcc_sync_fenced_block::gcc_sync_fenced_block()]+0x4c): undefined reference to__sync_lock_test_and_set_4' /tmp/ccOZxZBX.o: In function boost::detail::atomic_count::operator++()': a.cpp:(.text._ZN5boost6detail12atomic_countppEv[boost::detail::atomic_count::operator++()]+0x30): undefined reference to__sync_add_and_fetch_8' /tmp/ccOZxZBX.o: In function boost::detail::atomic_count::operator--()': a.cpp:(.text._ZN5boost6detail12atomic_countmmEv[boost::detail::atomic_count::operator--()]+0x30): undefined reference to__sync_add_and_fetch_8' /tmp/ccOZxZBX.o: In function boost::detail::atomic_count::operator long() const': a.cpp:(.text._ZNK5boost6detail12atomic_countcvlEv[boost::detail::atomic_count::operator long() const]+0x30): undefined reference to__sync_fetch_and_add_8'
The machine I used was a SiCortex SC5832,which use MIPS64 instruction set processors, OS is changed CentoOS. Gcc 4.2.3, Boost1.46.0. Is it possible that there are problems about the compatibility of the MIPS? I added -mips64 option, but it still give the same errors.
I know this environment could not be very usual, but I think some people who are using similar big machines may face the same problem.
Any help would be appreciated. By the way, I don't have sudo permission.
Thanks,
Tony
This function is a GCC built-in function, and it was introduced around GCC 4.2 (iirc) see documentation.
According to the documentation it's not available on all target processors.
If you look at boost/smart_ptr/detail/atomic_count.hpp it looks like it would fall into the #elif defined(BOOST_SP_HAS_SYNC) block. i.e. boost/smart_ptr/detail/atomic_count_sync.hpp.
Support for this is determined in boost/smart_ptr/detail/sp_has_sync.hpp. This header essentially assumes that GCC supports this on all platforms except for a few exceptions. You might want to insert MIPS as another exception here and submit a patch to boost.
You'll also see that one workaround is to define BOOST_AC_USE_PTHREADS. This will use a mutex around the atomic count, which probably is significantly less efficient, but at least it will work until you can figure out what atomic operations are supported on MIPS64.