I'm trying to build the source code provided for the book Mathematics for 3D Game Programming and Computer Graphics. I've linked the OpenGL.Framework in "Build Phases" and included (not sure which one I need)
#include <OpenGL/OpenGL.h>
#include <OpenGL/gl.h>
Now I get
Use of undeclared identifier 'Sqrt'
Use of undeclared identifier 'InverseSqrt'
Use of undeclared identifier 'fabs'
I'm guessing these have to do with not setting up OpenGL properly?
The author mentions using GLSL in the book but doesn't go into the details. I'm new to OpenGL.
not a xcode coder but in C++ fabs,sqrt are in math.h and if InverseSqrt means sqr so you can try to do a fix like this:
#include <math.h>
#define Sqrt sqrt
#define InverseSqrt(x) (x*x)
some environments want this instead:
#include <math>
#define Sqrt sqrt
#define InverseSqrt(x) (x*x)
However as mentioned in the comment those functions have nothing to do with OpenGL so they are most likely used in some lib you have included/linked whatever ... and forgot to include some header you should ...
[Edit1]
If InverseSqrt means 1/sqrt(x) as derhass suggested (english terminology feels sometimes weird) then use
#define InverseSqrt(x) (1/sqrt(x))
inversesqrt (no caps) is a built in function in GLSL, while fabs is a function in C, and sqrt exists in both languages. Xcode can compile C/C++, but you must write code to compile GLSL.
Related
I was working on a C/C++ project for an embedded system that uses gcc-arm-none-eabi-8-2019-q3-update as a compiler.
I added the use of the strptime function of time.h but initially it was undefined and I found in the compiler inclusions:
#if __XSI_VISIBLE
...strptime...
#endif
So, I solved the problem with:
#undef __XSI_VISIBLE
#define __XSI_VISIBLE 1
#include <time.h>
#undef __XSI_VISIBLE
#define __XSI_VISIBLE 0
Now it works BUT:
What have I done?
What is __XSI_VISIBLE?
What is it for?
Why does this compiler keep it by default at 0?
From https://pubs.opengroup.org/onlinepubs/9699919799/:
The X/Open System Interfaces (XSI) option is the core application programming interface for C and sh programming for systems conforming to the Single UNIX Specification. This is a superset of the mandatory requirements for conformance to POSIX.1-2017.
The __XSI_VISIBLE macro makes visible extensions to "vanilla" POSIX interfaces, which otherwise would be forbidden to be in the name space. Remember that C language standards like ISO C and POSIX permit the application to define all non-standard identifiers (in ISO C and "vanilla" POSIX, strptime is not reserved, you can write a function with that name and have it not interfere). By defining so-called feature test macros you extend the set of standard identifiers and reduce those available to define by the application programmer.
Your compiler keeps it at 0 because the implementation vendor chose that it is the application programmer's job to enable XSI when s/he wants it. Application programmers do this by defining the desired feature test macros before header inclusion, e.g. with
#define _POSIX_SOURCE
#define __XSI_VISIBLE 1
#include <time.h>
or pass -D__XSI_VISIBLE=1 to the compiler.
The correct defs to use are -D_XOPEN_SOURCE=1 and -D_GNU_SOURCE=1. These are used to conditionally define __XSI_VISIBLE and __GNU_VISIBLE respectively in <sys/features.h>. Defining __XSI_VISIBLE and __GNU_VISIBLE will not always work because they are overridden in <sys/features.h>.
Working on a Qt app on Windows. I include QVboxLayout in my source file only and this causes errors because its macro overwrites my method name.
foo.hpp
class foo
{
ChangeMenu();
}
foo.cpp
#include "foo.hpp"
#include "QVBoxLayout" // <--- this includes winuser.h
foo::ChangeMenu(){};
Now what happens is winuser.h has a macro
#ifdef UNICODE
#define ChangeMenu ChangeMenuW
#else
#define ChangeMenu ChangeMenuA
#endif // !UNICODE
This changes my function definition to ChangeMenuW but my declaration is still ChangeMenu.
How should I solve this? How can winuser.h define such a "normal" name as a macro?
Version of winuser.h is "windows kits\10\include\10.0.16299.0"
Pretty much any Windows API that deals with strings is actually a macro that resolves to a A or W version. There's no way around, you can either:
avoid including windows.h, but as you noticed, it creeps through;
brutally #undef the macro before defining/using your function; this is a fit punishment for hoarding such normal and non-macro-looking identifiers, but is tedious and some other code may actually need the Win32 function;
just accept it as a sad fact of life and avoid all the relevant Win32 APIs names; if you use Qt and follow its naming convention, it should be easy, as Qt functions use lowerCamelCase (as opposed to Win32 UpperCamelCase);
include windows.h explicitly straight in your header (possibly under an #ifdef _WIN32); this will make sure that your identifier will get replaced by the macro in all instances, so everything will work fine even if the compiler will actually compile a function with a different name; suitable for standalone projects, not suitable for libraries. (Thanks #Jonathan Potter for suggesting this)
You could take no care about this issue, Although your method name will be the same as the windows API, but the system will not mix them(just unify Unicode on both the place to define/call). If you call the ChangeMenu() directly, you will call the winapi, and if
foo f;
f.ChangeMenu();
or
foo::ChangeMenu();(static)
You will call your method.
And if you want to disable the winapi:
#ifdef ChangeMenu
#undef ChangeMenu
//code place that you define/call your own ChangeMenu().
#ifdef UNICODE
#define ChangeMenu ChangeMenuW
#else
#define ChangeMenu ChangeMenuA
#endif // !UNICODE
#endif
(It looks very tedious.)
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.
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.
I'm trying to use an open source library http://arma.sourceforge.net for linear algebra calculations. Some of the functions in Armadillo like pinv use LAPACK. I've written a very simple piece of code to use Armadillo to calculate pinv, but it produces a runtime error. This is probably because I do not have LAPACK linker flags in the sln file.
#include <iostream>
#include "armadillo"
using namespace arma;
using namespace std;
int main(int argc, char** argv)
{
mat A = rand<mat>(4,5);
mat pinverse = pinv(A);
A.print("A=");
return 0;
}
First things first, do you have LAPACK library? If not, get one (there's a number of implementations to choose). Otherwise, check that library's documentation or readme. There's nothing specific to Visual C++ here.
Usually all that's needed is:
add "lapack.lib" to linker input (in project settings).
In order to use LAPACK, assuming you are linking the libs to your project, you also need to uncomment #define ARMA_USE_LAPACK in Armadillo's config.hpp. Same thing goes for BLAS.