Defining C++ Preprocessor macros with SCons - c++

I'm trying to define a preprocessor macro within Scons for building a larger C/C++ project.
One of the libraries I'm using needs ALIGN defined. To be more specific, if I add
#define ALIGN(x) __attribute((aligned(x)))
to the header file of said library, it compiles fine. However, I should be able to specify this at build time, as this is how the library intends on being used. I know in CMake, I would be able to define the macro using something like
SET(ALIGN_DECL "__attribute__((aligned(x)))")
Defining constants in Scons like this
myEnv.Append(CPPDEFINES = ['IAMADEFINEDCONSTANT'])
works fine, but definine a macro in this way doesn't work.
What gives?
Edit: fixed typo

I was able to do it on Linux with g++ as follows:
SConscript
env = Environment()
env.Append(CPPDEFINES=['MAX(x,y)=(x>y ? x:y)'])
env.Program(target = 'main', source = 'main.cc')
main.cc
#include <iostream>
using namespace std;
int main(int argc, char **argv)
{
int a = 3;
int b = 5;
// MAX() will be defined at compile time
cout << "Max is " << MAX(a, b) << endl;
}
Compilation
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o main.o -c "-DMAX(x,y)=(x>y ? x:y)" main.cc
g++ -o main main.o
scons: done building targets.
Execution
./main
Max is 5

Related

SDL returns no output when I try to print statements using cout

I installed the MinGW version of SDL from their website.
I created a sample piece of code just to test if I could include the library without any errors.
#include <iostream>
#include <SDL.h>
using namespace std;
int main(int argc, char* argv[]) {
if(SDL_Init(SDL_INIT_VIDEO) < 0) {
cout << "SDL INIT FAILED" << endl;
return 1;
}
cout << "SDL INIT SUCCEEDED" << endl;
SDL_Quit();
return 0;
}
I also created a Makefile:
#OBJS specifies which files to compile as part of the project
OBJS = main.cpp
#CC specifies which compiler we're using
CC = g++
#INCLUDE_PATHS specifies the additional include paths we'll need
INCLUDE_PATHS = -Isrc\includes
#LIBRARY_PATHS specifies the additional library paths we'll need
LIBRARY_PATHS = -Lsrc\lib
#COMPILER_FLAGS specifies the additional compilation options we're using
# -w suppresses all warnings
# -Wl,-subsystem,windows gets rid of the console window
COMPILER_FLAGS = -w -Wl,-subsystem,windows
#LINKER_FLAGS specifies the libraries we're linking against
LINKER_FLAGS = -lmingw32 -lSDL2main -lSDL2
#OBJ_NAME specifies the name of our exectuable
OBJ_NAME = main
#This is the target that compiles our executable
all : $(OBJS)
$(CC) $(OBJS) $(INCLUDE_PATHS) $(LIBRARY_PATHS) $(COMPILER_FLAGS) $(LINKER_FLAGS) -o $(OBJ_NAME)
If I don't include the int argc, char* argv[] inside of int main() and try to ming32-make, it throws an error:
C:\Users\username\Documents\Projects\C++\SDL_test> mingw32-make
g++ main.cpp -Isrc\includes -Lsrc\lib -w -Wl,-subsystem,windows -lmingw32 -lSDL2main -lSDL2 -o main
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src\lib/libSDL2main.a(SDL_windows_main.o): in function `main_getcmdline':
/Users/valve/release/SDL2/SDL2-2.26.2-source/foo-x64/../src/main/windows/SDL_windows_main.c:82: undefined reference to `SDL_main'
collect2.exe: error: ld returned 1 exit status
mingw32-make: *** [Makefile:26: all] Error 1
When I include int argc, char* argv[], it doesn't give any errors but doesn't print anything either.
C:\Users\username\Documents\Projects\C++\SDL_test> mingw32-make
g++ main.cpp -Isrc\includes -Lsrc\lib -w -Wl,-subsystem,windows -lmingw32 -lSDL2main -lSDL2 -o main
C:\Users\username\Documents\Projects\C++\SDL_test>
When I use make instead of mingw32-make, the output remains the same.
I am using VSCode and I have included the header files and lib files in an src folder in the same directory as my script and also moved the SDL2.dll file in the root folder:
My C++ Configuration on VSCode:
Compiler Path: C:\MinGW\bin\g++.exe
Compiler Arguments:
IntelliSense mode: gcc-x64 (legacy) // Because using anything else says the the mode is incompatible with the compiler path.
Include path:
${workspaceFolder}/**
${workspaceFolder}/src/includes
I had also recieved SDL.h: file or directory not found errors before this and I fixed them by creating the Makefile.
Is there something I'm missing? Does SDL not output to stdout, because I've seen tutorials online and they are able to get outputs from cout fine on them.
I am expecting cout to work when I run the script.
-Wl,-subsystem,windows (aka -mwindows) hides the console window, and with it all output. Remove it, and use it only in the release builds.
-w suppresses all warnings
This is extremely unwise. Prefer -Wall -Wextra -Wdeprecated to enable most common warnings, plus -std=c++20 -pedantic-errors to enforce standard compliance (replace 20 with the latest version supported by your compiler).
As suggested by #keltar, you might be able to get output even from a program built with -mwindows if you redirect it to a file, using my_program.exe >output.txt.
EDIT: The issue was that I hadn't installed SDL2 the right way. I installed MSYS2 and used it to install MinGW-w64.
I then used the Msys2 command-line interface to install SDL2 using these commands:
pacman -Syu
pacman -Su
pacman -S mingw-w64-x86_64-SDL2
This installed the header and lib files for SDL in their proper locations. I was then able to include those files in my code.
I changed the main function from int main(int argc, char* argv[]) to int WinMain(int argc, char* argv[]) because I'm on Windows and this helps get rid of the undefined reference to WinMain error.
My working code:
#include <iostream>
#include <SDL2/SDL.h>
using namespace std;
int WinMain(int argc, char* argv[]) {
if(SDL_Init(SDL_INIT_VIDEO) < 0) {
cout << "SDL INIT FAILED" << endl;
return 1;
}
cout << "SDL INIT SUCCESSFUL" << endl;
}

Shared libraries and c++20 modules

There is very little documentation online on the proper use of C++20 modules in shared libraries. Many folks are clearly interested, but I haven't been able to find a clear solution.
In MSVC, you need to use dllexport when compiling the library, and dllimport when consuming the symbols. This can be done using macros in "legacy C++", but this does not work with C++20 modules, since the code is only compiled once, regardless of preprocessor directives.
This post suggests that you only need to use dllexport now, and that dllimport will be taken care of automatically by the compiler. However, this comes from a comment which has now been deleted, and I couldn't find any reliable source on the topic.
How is one expected to create a shared library using C++20 modules?
Background
A translation unit which declares a module interface or a module partition will be treated as a module unit and will, when compiled, generate both an object file and a binary module interface (BMI).
The BMI is a binary representation of an abstract syntax tree, that is a data structure representing the syntax and data types of the program. We have the traditional C++ compilation pipeline:
program -> precompiler -> lexer -> parser -> assembler -> linker
With GCC, we should add the compiler flag -c which tells the compiler to compile and assemble but not link.
But shared libraries are built by the linker by reading several compiled object files together and creating a shared object. So that happens after the BMI's have been built. And the BMI's may be built without linking them together as that is two different stages.
Module Visibility
In C# when building a DLL we have visibility attributes on class level, ie. public, private, internal. In C++ we can obtain the same functionality with module partitions.
A module partition, declared with module <module> : <partition>; will be entirely visible inside the compilation unit that declares export module <module>;, but not outside that module. This reminds me of internal mode from C#. But if we however export the partition with export module <module> : <partition>; then its declarations will be publicly visible. Read more on cppreference.
Example
I have solved that problem with GCC (g++-11), see here.
In essence, you don't need DLL import/export since there are (likely) no headers involved. I have tried inserting these visibility attributes but with complaints from my compiler, so I guess we might not need them after all. Other than that, it's standard procedure. I copy/paste my example here as well:
Main
import <iostream>;
import mathlib;
int main()
{
int a = 5;
int b = 6;
std::cout << "a = " << a << ", b = " << b << '\n';
std::cout << "a+b = " << mathlib::add(a, b) << '\n';
std::cout << "a-b = " << mathlib::sub(a, b) << '\n';
std::cout << "a*b = " << mathlib::mul(a, b) << '\n';
std::cout << "a/b = " << mathlib::div(a, b) << '\n';
return 0;
}
Library
export module mathlib;
export namespace mathlib
{
int add(int a, int b)
{
return a + b;
}
int sub(int a, int b)
{
return a - b;
}
int mul(int a, int b)
{
return a * b;
}
int div(int a, int b)
{
return a / b;
}
}
Makefile
GCC=g++-11 -std=c++20 -fmodules-ts
APP=app
build: std_headers mathlib main
std_headers:
$(GCC) -xc++-system-header iostream
mathlib: mathlib.cpp
$(GCC) -c $< -o $#.o
$(GCC) -shared $#.o -o libmathlib.so
main: main.cpp
$(GCC) $< -o $(APP) -Xlinker ./libmathlib.so
clean:
#rm -rf gcm.cache/
#rm -f *.o
#rm -f $(APP)
#rm -f *.so
Running
g++-11 -std=c++20 -fmodules-ts -xc++-system-header iostream
g++-11 -std=c++20 -fmodules-ts -c mathlib.cpp -o mathlib.o
g++-11 -std=c++20 -fmodules-ts -shared mathlib.o -o libmathlib.so
g++-11 -std=c++20 -fmodules-ts main.cpp -o app -Xlinker ./libmathlib.so
./app
a = 5, b = 6
a+b = 11
a-b = -1
a*b = 30
a/b = 0
Now this is clearly platform-specific, but the approach should work on other platforms. I have tested a similar thing with Clang as well (same repo as linked).
C++20 modules have no special relationship with shared libraries. They are primarily a replacement of header files.
This means that you would develop a shared library with C++20 modules in a similar fashion as you would with header files before C++20, at least with my current understanding. You design some API that is exported (unfortunately still using vendor-specific attributes like __declspec(dllexport) or __attribute__((visibility("default")))) and implement it. You build your shared library file (.dll/.so) and an import library for distribution, same way as before. However instead of distributing header files, you would distribute module interface units instead. Module interface units are files containing an export module ABC; declaration at the top.
And executables consuming that shared library would then import that module using import ABC;, instead of #include-ing a header file.
Edit: As was pointed out in the comments, it is seemingly still necessary on Windows to provide a macro switch inside the module interfaces that toggles between dllexport and dllimport attributes, similar to as it is done with headers. However, I have currently not experimented with this and can only defer to what #jeremyong has experimented with in What is the expected relation of C++ modules and dynamic linkage?.

Compiling several source (main and headers) files and linking them in ROOT CINT?

Let me first set the context, it is CERN's ROOT and CINT and ACLiC etc.
Suppose I have a main macro named macro.cpp and two headers h1.cpp (contains the definition of a function) and h1.h containing the declaration of the function defined in h1.cpp similarly I have h2.cpp and h2.h. The main program macro.cpp calls those functions inside h1 and h2. I was successful compiling the source files using:
root [0] .L h1.cpp+
root [1] .L h2.cpp+
root [2] .L macro.cpp+
which generated three .so files macro_cpp.so, h1_cpp.so and h2_cpp.so. I want to know what to do with them ? How do I link them so that I have something like a "macro.out" or something like that (a single executable file of some kind) which I can execute (although I don't know how !) and achieve whatever I wished to achieve with the macro.
Note: If I just load all the files using .L file_name.cpp etc and just execute the main macro using .x macro.cpp then everything works fine and I have results, but this is not what I want ! I want to compile like we do in usual g++ and by the way in every forum everyone keeps advising on compiling using .L file_name.cpp+ or ++ .. I would really like to know the whole story. Because nobody seems to explain beyond .L file_name.cpp+ .. what next ? What to do with the .so etc.
I am a beginner, I will really appreciate a simple and step by step answer and explanation.
Thanks.
Edit-1: I am working with:
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Edit-2: ROOT related information:
ROOT 5.34/36 (v5-34-36#v5-34-36, dic 07 2016, 23:31:51 on linuxx8664gcc)
CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
If you want to compile and link you can use a standard compiler instead of Cint/Aclic.
For example, assuming you are working on a *nix platform, you can use the example files below:
h1.h
int add_one(int a);
h1.cpp
#include "h1.h"
int add_one(int a)
{
return a+1;
}
h2.h
#include <TLorentzVector.h>
TLorentzVector multiply_by_two(const TLorentzVector v);
h2.cpp
#include "h2.h"
TLorentzVector multiply_by_two(const TLorentzVector v)
{
return 2.0*v;
}
macro.cpp
#include "h1.h"
#include "h2.h"
#include <TLorentzVector.h>
#include <iostream>
using std::cout;
using std::endl;
int main()
{
int a = 0;
TLorentzVector v;
v.SetPtEtaPhiM(1.0, 0.0, 0.0, 0.0);
cout<<"calling add_one on "<<a<<": "<<add_one(a)<<endl;
cout<<"calling multiply_by_two on "<<v.Pt()<<": "<<multiply_by_two(v).Pt()<<endl;
return 0;
}
Then you can compile with
g++ -c -g -Wall `root-config --cflags` h1.cpp
g++ -c -g -Wall `root-config --cflags` h2.cpp
g++ -c -g -Wall `root-config --cflags` macro.cpp
and link with
g++ `root-config --glibs` h1.o h2.o macro.o
The executable will be a.out:
$ ./a.out
calling add_one on 0: 1
calling multiply_by_two on 1: 2
You can put these g++ commands in a script or, when you start having several files and directories, you can write your make file (or cmake). For this last step, see for example the tutorial here
http://www-pnp.physics.ox.ac.uk/~brisbane/Teaching/Makefiles/Tutorial_1_Makefiles_and_ROOT.pdf
Note 1: one advantage of using g++ is that you will get clear error messages when something doesn't compile. The error messages from Cint can
be difficult to understand--although this is very much improved in root 6 with Cling.
Note 2: another advantage of using a standard compiler is that you will be able to easily link your main executable against libraries other than root.
This answer is based mostly on the answer by user2148414, but if one follows the answer will notice that there were some issues with the method of linking the source (*.cpp) files. My answer also addresses another important object called a TApplication that will play a crucial role in such applications involving root libraries. The following linking step:
g++ `root-config --glibs` h1.o h2.o macro.o
will likely show a lot of errors complaining about the root objects like TWhatever (in user2148414's answer TLorentzVector will show problems). In the comments to that answer one can find the discussion on including various physics libraries that can solve the problem but without discussing that (and I am not comfortable either :) ) let me write down the command that solves everthing.
This procedure is a one-liner, that is no need to compile individual files, create *.cpp files and *.h files as discussed in that answer then compile and link and create a single executable named "someExecutable" using:
g++ macro.cpp h1.cpp h2.cpp `root-config --libs --cflags` -o someExecutable
or better (and one should do it)
g++ -Wall -Wextra -Werror -pedantic -std=c++14 macro.cpp h1.cpp h2.cpp `root-config --libs --cflags` -o someExecutable
This will solve my original answer but for completeness I would like to add a few more things.
TApplication
My original motivation was to create an application that talks to "ROOT" but I didn't want to work with the ROOT shell, CINT, ACLiC etc and wanted to work entirely with g++. user2148414's and my answer will solve the part of creating an application but the application will not serve any purpose, it will run, create histograms draw them and do all the stuff but all the canvases will close in the end when the code reaches "return 0;". To keep the canvases open we will need "TApplication". So the consider the main of user2148414's answer, I am going include just two more lines and include two arguments to the main:
macro.cpp
#include "h1.h"
#include "h2.h"
#include <TLorentzVector.h>
#include <iostream>
using std::cout;
using std::endl;
int main(int argc, char* argv[]) //introduced arguments to main
{
// here I introduce TApplication
TApplication* SomeApp = new TApplication("SomeApp",&argc, argv);
int a = 0;
TLorentzVector v;
v.SetPtEtaPhiM(1.0, 0.0, 0.0, 0.0);
cout<<"calling add_one on "<<a<<": "<<add_one(a)<<endl;
cout<<"calling multiply_by_two on "<<v.Pt()<<": "<<multiply_by_two(v).Pt()<<endl;
//and just before returning 0
SomeApp->Run();
return 0;
}

Eclipse C++ add shared library to main project

I´m using Eclipse 3.8.1 on Ubuntu 14.02 with 2 projects for the first time. I´m coming from c# world so that can be an Eclipse error or a C++ concept error.
testmonitor: A sample C++ project. Code:
#include <iostream>
using namespace std;
int main() {
cout << "Test program" << endl;
log_access::test();
return 0;
}
log_access is a shared library: log_access.cpp
#include <iostream>
namespace log_access {
void test()
{
std::cout << "It worked!!!" << std::endl;
}
}
I´m trying to build a shared library and link it to the main project. I went to Project -> Properties -> Project References and clicked on the project (shared lib) I want to reference.
Not worked....
Then I went to Project -> Properties -> C/C++ General -> Paths and Symbols -> References Tab and clicked on the project (shared lib) I want to reference.
Not worked...
Currently I´m getting the following error:
Invoking: GCC C++ Compiler
g++ -std:c++0x -I"home/projects/dev/sample/workspace/log_access" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/testproject.d" -MT"src/testmonitor.d" -o "src/testmonitor.o" "../src/testmonitor.cpp"
../src/testmonitor.cpp: In function 'int main()':
../src/testmonitor.cpp:34.3: error: 'log_access' has not been declared
log_access:test();
^
make: *** [src/testmonitor.o] Error 1
13:56:39 Build Finished (took 1s.246ms)
Obs: The log_access compiles fine...
I appreciate very much some help on that...
You'll need to include your definition of log_access::test in your main file via
#include "log_access.h"
Assuming you have a header file named log_access (you shouldn't include .cpp files; use them for implementing methods declared within the header file. See here for why).

c++ program using GMP library

I have installed GMP using the instruction on this website: http://www.cs.nyu.edu/exact/core/gmp/
Then I looked for an example program using the library:
#include <iostream>
#include <gmpxx.h>
using namespace std;
int main (void) {
mpz_class a, b, c;
a = 1234;
b = "-5678";
c = a+b;
cout << "sum is " << c << "\n";
cout << "absolute value is " << abs(c) << "\n";
cin >> a;
return 0;
}
But if I compile this using the command: g++ test.cpp -o test.exe, it says gmpxx.h: no such file or directory.
How can I fix this? I am kind of new to this. And I am using MinGW.
Get the actual version here GNU GMP Library. Make sure you configure it to be installed in /usr/lib (pass --prefix=/usr to configure).
Here you have documentation: GNU GMP Manual.
You are not using the lib correctly. I don't know if you can directly access mpx values
with C++ functions but, here you have a working example of what you wanted to achieve:
#include<iostream>
#include<gmp.h>
using namespace std;
int main (int argc, char **argv) {
mpz_t a,b,c;
mpz_inits(a,b,c,NULL);
mpz_set_str(a, "1234", 10);
mpz_set_str(b,"-5678", 10); //Decimal base
mpz_add(c,a,b);
cout<<"\nThe exact result is:";
mpz_out_str(stdout, 10, c); //Stream, numerical base, var
cout<<endl;
mpz_abs(c, c);
cout<<"The absolute value result is:";
mpz_out_str(stdout, 10, c);
cout<<endl;
cin.get();
return 0;
}
Compile with:
g++ -lgmp file.cpp -o file
Here is the correct procedure for setting up the current (as of 7/2/13) GNU bignum libraries with Eclipse CDT, MinGW, and msys for C++. To get through this, you should have used Unix or Linux before, as well as Windows, and you should have a vague recollection of programming and compiling programs. This is the culmination of over a week of research and hardcore frustration, so if I messed something up note it politely or I will blow you up with the power of my mind!
I assume you have already downloaded and installed Eclipse and MinGW and have installed msys into MinGW. You must install MinGW before msys!
Download the tarball for the GMP libraries from gmplib.org to ${gmp_download}. I downloaded the gmp-5.1.2.tar.xz because I have never used lzip and didn't know if it was available in msys.
Open up an msys window (essentially a bash shell). cd ${gmp_buid} and tar -Jxvf ${gmp_download}/gmp-x.x.x.tar.xz
Those tar options are different from what you may find elsewhere on the web! -Jxvf is right for xz (and I think lzip), but for gzip you use -xzvf.
cd gmp-x.x.x and run ./config.guess. Write down the output. You will need it next.
Run ./configure --prefix=${gmp_build} --build= --enable-cxx --with-gnu-ld
Apparently if you don't explicitly tell GMP to build for your platform it builds everything, which is bad. The cxx option builds the C++ libraries and --with-gnu-ld allows it to work with ld. Pretty straightforward.
make
make install
EX: suppose you installed to C:/gmp. You should have gmp/include/gmp.h and gmpxx.h. You should also have gmp/lib/libgmp.a, libgmp.la, libgmpxx.a, libgmpxx.la. You should also have a share directory with stuff in it.
Set up eclipse:
Go to project --> properties
Under C/C++ build --> Environment edit the PATH variable and add ${gmp_build}/include;${gmp_build}/lib
Under C/C++ build --> settings --> tool settings --> GCC Assembler --> general add ${gmp_build}/include as an include path.
Same place but --> GCC C++ compiler --> Includes add ${gmp_build}/include as an include path.
Same place --> GCC C++ compiler --> Miscellaneous add -lgmp -lgmpxx to the END of the line. THE END OF THE LINE!
Same place --> GCC C compiler Add the same include paths and miscellaneous options as before.
Same place --> MinGW C++ linker --> Libraries Add to the "Libraries (-l)" both gmp and gmpxx IN THAT ORDER! Now add ${gmp_build}/lib to "LIbrary Search Path (-L)"
Under C/C++ General --> Paths & Symbols --> Incudes Tab check that you have ${gmp_build}/include in your include directories for Assembly, C, and C++. If they aren't there you may have messed up an earlier step. They should be auto populated by Eclipse.
Same place --> Libraries Tab check that you have gmp and gmpxx IN THAT ORDER. It should already be populated.
Same Place --> Library Paths Tab Check for ${gmp_build}/lib which should already be there.
Hit "Apply" and make sure you rebuild the index or the changes won't take. Hit OK to close out.
Run this short program to verify your setup:
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <iostream>
#include <gmp.h>
#include <gmpxx.h>
using namespace std;
int main ()
{
mpz_t p;
mpz_init_set_ui (p,3);
return 0;
}
Your compile commands should look similar to this:
g++ "-IC:\gmp\include" -O0 -g3 -Wall -c -fmessage-length=0 -lgmp -lgmpxx -o main.o "..\main.cpp" g++ "-LC:\gmp\lib" -o GMPDebug.exe main.o -lgmp -lgmpxx
Notes:
The order of the options is important. I don't know all of the whys, but if the second command line (which links the program) has the -lgmp -lgmpxx flags before the -o option, the linking will fail miserably.
The -l flag is a tricky one. It actually says "Go look in -L for liblibrary.a". In this case "Go look in C:\gmp\lib for libgmp.a and libgmpxx.a".
I have heard of bugs involving cout and the 64 bit version of eclipse, so I am using the 32 bit version, where I am seeing the same bug. :-)
Since there are very small examples in gmp library docs, I'm including exponentiation example for reference:
Program calculates 2 ^ 20000
#include <iostream>
#include <gmp.h>
using namespace std;
int main(void) {
mpz_t result, base;
mpz_inits(result,base,NULL);
mpz_set_str(base, "2", 10);
mpz_pow_ui(result, base, 20000);
mpz_out_str(stdout, 10, result);
return 0;
}
Compile:g++ -o gmp_pow_test gmp_pow_test.cpp -lgmp
Run :./gmp_pow_test
Install gmp library on Ubuntu with following: sudo apt-get install libgmp-dev libgmpxx4ldbl
You need to tell the compiler what libraries you want to use.
g++ -lgmp -lgmpxx file.cpp -o file
It is probably too late to be useful, but...
First, your program works just fine. As others pointed out, you need to (a) ensure that GMP library is installed (including its gmpxx extension, and all the relevant files), and (b) that you're telling the compiler where to find both the include files, and the libraries to link with.
In my case include files are in /opt/local/include, and the libraries are in /opt/local/lib (where Macports placed them :).
Here's the code:
#include <iostream>
#include <gmpxx.h>
using namespace std;
int main (void) {
mpz_class a, b, c;
a = 1234;
b = "-5678";
c = a+b;
cout << "sum of " << a << " and " << b << " is " << c << "\n";
cout << "absolute value is " << abs(c) << "\n";
// cin >> a;
return 0;
}
Here's the compile/link command:
clang++ -o gmpxx-tst -I/opt/local/include gmpxx-tst.cpp -L/opt/local/lib -lgmpxx -lgmp
Here's what invocation of gmpxx-tst produces:
$ ./gmpxx-tst
sum of 1234 and -5678 is -4444
absolute value is 4444
$
You'll need to tell the compiler where the header file is.
g++ test.cpp -I/path/to/directory/that/contains/the/header -o test.exe
I have tried so many solutions and all of them has some problems
Here is the best way to install GMP and eclipse
Follow this link
http://www.multigesture.net/articles/how-to-install-mingw-msys-and-eclipse-on-windows/
You need to make sure of the following that hasn't been mentioned there:
When installing MinGW choose a path that contains no space like "c:\MinGW"
Once installed, From start open MinGW installation manger
choose all the basics
-then under MinGW, choose all GMP libraries to be installed
Apply changes
After that you will install JDK, then Add "C:\Program Files\Java\jdk1.8.0_121\bin" to PATH system variable
After installing Eclipse go to:
GCC C++ compiler --> Miscellaneous add -lgmp -lgmpxx to the END of the line
MinGW C++ linker --> Libraries Add to the "Libraries (-l)" both gmp and gmpxx IN THAT ORDER
gooooo ahead.