I've written a small program that utilizes the Fast Light Toolkit and for some reason a compiler error is generated when trying to access the functions in the cmath header.
Such as error ::acos has not been declared.
This goes on for pretty much every function it tries to use in the header. What could I be missing?
The header files I have included are
Simple_window.h
Graph.h
both of which are part of the FLTK.
The code is this:
#include "Simple_window.h" // get access to our windows library
#include "Graph.h" // get access to graphics library facilities
int main()
{
using namespace Graph_lib; // our graphics facilities are in Graph_lib
Point tl(100,100); // to become top left corner of window
Simple_window win(tl,600,400,"Canvas"); // make a simple window
Polygon poly; // make a shape (a polygon)
poly.add(Point(300,200)); // add a point
poly.add(Point(350,100)); // add another point
poly.add(Point(400,200)); // add a third point
poly.set_color(Color::red); // adjust properties of poly
win.attach(poly); // connect poly to the window
win.wait_for_button(); // give control to display engine
}
Edit: Here is example code of when the compiler error is generated. This is inside the cmath header.
namespace std
{
// Forward declaration of a helper function. This really should be
// an `exported' forward declaration.
template<typename _Tp> _Tp __cmath_power(_Tp, unsigned int);
inline double
abs(double __x)
{ return __builtin_fabs(__x); }
inline float
abs(float __x)
{ return __builtin_fabsf(__x); }
inline long double
abs(long double __x)
{ return __builtin_fabsl(__x); }
using ::acos; //ERROR HERE
inline float
acos(float __x)
{ return __builtin_acosf(__x); }
inline long double
acos(long double __x)
{ return __builtin_acosl(__x); }
template<typename _Tp>
inline typename __enable_if<double, __is_integer<_Tp>::_M_type>::_M_type
acos(_Tp __x)
{
return __builtin_acos(__x);
}
Edit: Code::blocks is saving files as C files....
When you include the C++ version (<cXXXX>) of standard C libraries all the symbols are defined within the std namespace. In C++ you do not need to link against the math library (-lm is not required)
#include <cmath>
#include <iostream>
int main()
{
std::cout << std::fabs( -10.5 ) << std::endl;
}
I had this problem - it was driving me crazy but I tracked down the cause, and it was a little different than what I've seen reported on this issue.
In this case, the general cmath header (or math.h - the error and solution occur in C++ or C) had architectural environment switches to include architecture specific math subheaders. The architecture switch (environment variable) hadn't been defined, so it was punting and not actually including the headers that truly defined the math functions.
So there was indeed a single math.h or cmath.h, and it was included, but that wasn't enough to get the math functions. In my case, rather than define the architectural variable, I instead found the location of the correct sub math headers and added them to my compile path. Then the project worked!
This seems to be an issue that comes up a lot when porting Linux projects to OS-X. I'd imagine it might occur anytime a project was moved betwee platforms such that the standard library headers are arranged differently.
Jeff
Since your code as shown above does not directly call acos(), there is arguably a bug in one of the headers that you do use. It appears there is some (inline) code in one of the headers that invokes the acos() function without ensuring that the function is properly declared. This might be a macro or an inline function.
The best fix is to ensure that the headers are self-contained - change the headers.
If that is not possible, the hackaround is to include the appropriate header (#include <cmath>, probably) in the source code.
The program is able to access the cmath header, the error is in the cmath header itself.
In that case, you will probably need to provide a global acos() function (declaration at least, possibly definition too) that calls onto std::acos():
double acos(double x) { return std::acos(x); }
Just make sure this is not inside any namespace - not even the anonymous one. (Check compiled with G++ 4.0.1 on MacOS X, with '#include <cmath>' preceding it. Given that you have a problematic <cmath> header, you might need to get fancy:
extern double std::acos(double);
double acos(double x) { return std::acos(x); }
#include <cmath>
This is pretty nasty - are you sure there isn't a bug-fixed version of your compiler?
Is there any chance that you've got '#include <cmath>' inside a namespace?
It also happens in Visual C++, in programs that do not sapuse to use cmath.
I found that the problem is that I used main.c file instead of main.cpp file.
The error is most likely to be in your code and not in cmath... unless you changed something in cmath. Could you copy the errors and tell us what is the application you are using to program?
Related
I have been recently practicing managing multiple objects and drawing them in C++ using SFML library. I wanted my textures and future resources to be more reusable so I decided to make use of Thor library which suits my needs really well.
So I've written first few lines of code based on what you can find in this tutorial and the compiler always says:
main.cpp|12|error: 'textures_holder' does not name a type
This line gives an error :
textures_holder.acquire("Dirt", thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png"));
I'm using Code::Blocks IDE with MinGW compiler and SFML 2.5.0.
Here's my main.cpp and the header file which contains extern object :
//...
#include <Thor/Resources.hpp>
#include "Dirt_Block.h"
using namespace std;
//Adding textures to the texture library
//THIS LINE GIVES AN ERROR
textures_holder.acquire("Dirt", thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png"));
//Rest of code...
Dirt_Block.h (only the upper part) :
#ifndef DIRT_BLOCK_H
#define DIRT_BLOCK_H
#include <SFML\Graphics.hpp>
#include <vector>
#include <Thor/Resources.hpp>
#include <Thor/Resources/SfmlLoaders.hpp>
extern sf::Vector2u screenRes;
extern thor::ResourceHolder<sf::Texture, std::string> textures_holder;
//Rest of the code
I'd like to know what is causing this error and maybe help others who may experience similiar frustrating problems. Thanks for help.
EDIT :
As suggested in the comment I've declared a few extern int variables in the Dirt_Block.h so now it looks like this :
//...
extern int test_int_up;
extern sf::Vector2u screenRes;
extern thor::ResourceHolder<sf::Texture, std::string> textures_holder;
extern int test_int_d;
//...
And then assinged to them some value in main.cpp :
//...
test_int_up = 55;
test_int_d = 55;
//Adding textures to the texture library
textures_holder.acquire("Dirt", thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png"));
//...
But the compiler gives error :
main.cpp|9|error: 'test_int_up' does not name a type
main.cpp|10|error: 'test_int_d' does not name a type
main.cpp|12|error: 'textures_holder' does not name a type
Much less distracting to see what your problem is without all the extraneous code!
C++ programs don't start from the top of the file and run code down to the bottom. They start at the main(), and control flow proceeds from there, with one thing triggering another.
(Note: That doesn't take into account global constructor ordering, which does go in order of declaration--but you have no guarantee of the order declarations from "different files" might run in.)
Point being, you can't just make random function or method calls in the middle of a file. That's where you put declarations. You have to be inside of a function or method to make calls, e.g.
int main() {
textures_holder.acquire(
"Dirt",
thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png")
);
...
}
I am trying to compile a large C++ code (there are a few C files too) on a Linux cluster, having run it for some time on a Mac compiled with g++. On the cluster, I have to use either gcc/4.7.2 or intel/icpc (there is other software on the cluster that only works with those two compilers). I'm a newbie in dealing with compiling/linking problems, so no advice/tips is too simple.
I posted a question here a couple of days ago about a problem with using gcc/4.7.2. I haven't been able to resolve the problem, so now I'm trying icpc. Things have gone surprisingly well, but there is one problem I can't get past.
The problem is that I am getting errors related to "multiple definitions." These are associated with what seems to be a virtual function in a class that is inherited. I didn't write this code. There is a base class (Solver3), a derived class (Solver2), and another derived class (Solver1). The classes solve matrix equations. I can't tell which function is the problem because the error output is quite cryptic (see below; I have no function called "_fileno" and I can't find any generic definition of this term online). But the problem function is probably SolveWithSolver2 because it is the only function in the Solver1 class. I have no clue what could be wrong with it.
This is a bit over my head in terms of C++ knowledge and it is likely I'm making some beginner's mistake. For the past couple of days, I have used Google to search old forum posts. I have tried renaming what seems to be the problem function, I have tried inlining it. I get the same error. The code is very large and only a small part of it was written by me, so I can't post much of it. I will post what seems relevant and can add things if that would be helpful.
Here are the kinds of the errors I'm getting, starting from the first one (I have not posted all of the output):
/code/libraries/libsolver.a(Solver1.o): In
function _fileno(_IO_FILE*)': Solver1.cpp:(.text+0x0): multiple
definition of_fileno(_IO_FILE*)' main.o:main.cpp:(.text+0x1bc0):
first defined here
/code/libraries/libsolver.a(Solver2.o): In
function _fileno(_IO_FILE*)': Solver2.cpp:(.text+0x0): multiple
definition of_fileno(_IO_FILE*)' main.o:main.cpp:(.text+0x1bc0):
first defined here
/code/libraries/libsolver.a(Solver3.o):
In function _fileno(_IO_FILE*)':
Solver3.cpp:(.text+0x0): multiple definition of_fileno(_IO_FILE*)'
main.o:main.cpp:(.text+0x1bc0): first defined here
... And so on
Here is the Solver1 header code:
#ifndef SOLVER1
#define SOLVER1
#include "Solver2.h"
#include "ErrorHandler.h"
#ifdef SOLVER2
namespace code {
class Solver1 : public Solver2 {
public:
Solver1( );
//protected:
virtual void SolveWithSolver2( Matrix& A,
std::vector<double>& b,
std::vector<double>& x,
double tolerance );
private:
double pivot;
};
}
#endif
#endif
Here is the Solver2 header code:
#ifndef SOLVER2_H
#define SOLVER2_H
#include "Solver3.h"
#include "helper.h"
#ifdef SOLVER2
namespace code {
class Solver2: public Solver3 {
public:
Solver2 ();
//protected:
virtual void SolveWithSolver2(Matrix& A,
std::vector<double>& b,
std::vector<double>& x,
double tolerance) = 0;
private:
virtual void SolveEquation(Matrix& A,
std::vector<double>& b,
std::vector<double>& x,
stl_index unknowns);
double Residual(const Matrix& A,
const std::vector<double>& b,
std::vector< double >& x);
double Calculate(const SparseMatrix& A,
const std::vector<double >& b,
const std::vector< double >& x);
double residual;
};
}
#endif
#endif
Reply to Jakob:
Output of:
"grep _fileno" /usr/include/* -R
/usr/include/bits/dirent.h:#define d_fileno d_ino /* Backwards
compatibility. */ grep: warning:
/usr/include/c++/4.3/x86_64-suse-linux/32: recursive directory loop
/usr/include/dirent.h:#if (defined __USE_BSD || defined __USE_MISC) &&
!defined d_fileno /usr/include/dirent.h:# define d_ino d_fileno /*
Backward compatibility. */ /usr/include/lcms.h:# define fileno
_fileno /usr/include/libdwarf/libdwarf.h: Dwarf_Unsigned * /*ret_fileno*/, /usr/include/libio.h:#define _IO_DELETE_DONT_CLOSE
0x40 /* Don't call close(_fileno) on cleanup. */ /usr/include/libio.h:
int _fileno; /usr/include/linux/coda.h: u_int32_t d_fileno; /*
file number of entry */ /usr/include/linux/mtio.h: __kernel_daddr_t
mt_fileno; /* number of current file on tape */
/usr/include/sys/mtio.h: __daddr_t mt_fileno; /* Number of current
file on tape. */ /usr/include/X11/Xw32defs.h:#define fileno _fileno
Edit:
Using Jakob's suggestion about compiler flags (adding -Wl and -z) to my OPTIONS, my error output became much more clear; I got file names, line numbers, and particular errors.
I have now dealt with the problem, in the sense that I can compile that library. But to be honest, I don't really know why the compiler complained to begin with or why my solution worked. The problem involved preprocessor directives, which I confess I know little about. If anyone cares to speculate on what the issue was, it would be interesting to know. I have never run into needing ";" in preprocessor directives before.
This is what "fixed" things (sorry about the bold, large text; can't seem to turn that off):
define SOLVER_C_CONVERSION;
void __cdecl;
endif
This is what it looked like when it was a problem:
define SOLVER_C_CONVERSION void __cdecl
endif
So now that I've fixed that problem, I have one more library to deal with. It is throwing up all kinds of errors that g++ previously ignored. I may bother you all once more later on today if I can't solve them. I'm pretty sure the problem is with my makefile.
To solve the problem with the multiple definitions, the first step would probably be
tracking down the include dependencies,
using the '-M' or the '-H' compiler flag,
e.g. :
gcc -H {use correct include flags here: -I$( include path) } -c Solver1.cpp
This will show you a dependency tree (read top-down )
Then you could figure out, which of the files defines the _fileno symbol.
(e.g by using the grep command)
and finally you could try to understand, why _fileno is defined multiple times.
If you want a nicer dependency output, you could in general try to generate the include dependencies with doxygen.
Alternatively as a workaround you could use following link flags which will prevent the compilation process from failing in case of multiple definitions:
-Wl,-z,multiple
I am working in restructuring a former program which relies heavily on a external library
ChronoEngine.lib
I created a new project which holds the same additional include directories, linkers etc... than the former one
I have the following piece of code in a header file
#ifndef DRAW
#define DRAW
#include "physics/CHsystem.h"
class draw
{
public:
// Change size
static void changeSize(int w, int h);
// World definition
static void drawSky(double halfSize, double red, double green, double blue);
static void drawChair() ;
static void drawCDG() ;
static void drawPlane();
// Geometrical definition
static void drawSphere(ChBody* body);
static void drawBox(ChBody* body);
};
#endif
this is the same header file as in the previous project, but here visual studio does not find the definition of ChBody (which is included in the "physics/CHsystem.h" header file definition - this file includes physics/ChBody.h -)
when i right click on ChBody to find the reference, visual studio finds 5 references (1 is the real definition (from ChBody.h), 4 others are forward references in others files from the library)
how can I tell my program to find the real definition of the class ? Apparently, it is not a problem of being linked to the library, but more like a referencing problem
my main.cpp is only printing something to the screen for the time being, and draw.cpp is empty (i haven't defined the function i am declaring in draw.h for the time being)
Thanks
Best
Vincent
Thanks a lot
Actually that was a fairly easy problem to solve
The problem was coming from the fact that the other classes (such as ChBody) were defined in a namespace
therefore, adding
using namespace <the name of the namespace>;
before the definition of the class and after the #include solves this kind of issues.
Thanks
Best
Vincent
On page 172, Stroustrup is doing something like so:
namespace Parser { //interface for users
double expr(bool);
}
namespace Parser { //interface for implementers
double prim(bool);
double term(bool);
double expr(bool);
using Lexer::get_token;
<SNIP>
}
Q1. does this imply that the first namespace is being inserted into (as an example) user.h and included from main.cpp - the driver; the second namespace into implementer.h and included from parse.cpp? Is this why he says:
"compiler doesn't have sufficient information to check the consistency
of the two definitions of the namespace"
because both implementer.h and user.h can't be included into "Parser implementation"(parse.cpp)?
172.png
173.png
On page 174, he has:
namespace Parser { //interface for implementers
// ...
double expr(bool);
// ...
}
namespace Parser_interface { //interface for users
using Parser::expr;
}
Is upper namespace going into implementer.h and lower one into user.h
In his "dependency graph" is he restating the obvious: that when Make is run, any change to "Parser"(parser.cpp/implementer.h) will result in driver/main.cpp being rebuilt - unnecessarily?
174.png
http://groups.google.com/group/alt.comp.lang.learn.c-c++/browse_thread/thread/3be9f35f2969f311/0d418ec6138a7e58#0d418ec6138a7e58
(the part about compiler consistency is wrong and the above thread states why:
Yes, the implementation can and should do that, but the checking of
consistency only works to a certain extent. If user.h uses things that are
not declared there, you will get a diagnostic. If you have "double
expr(bool);" declared in one place and "float expr(bool);" in another, the
compiler should also give you a diagnostic. However, if you change the
second one to "float expr(int);", then this is just an overload which is
perfectly legal C++. - Ulrich Eckhardt)
I believe the answers to all three your questions are "yes"
I'm trying to write a header-only library of helper functions for myself. (I'm using boost and SDL, and boost is much easier to use, so I want to emulate that for my own helper library.)
I'm getting the error "Does not name a type" for one of my classes, and it's confusing me. I know I can get this problem with a misspelling or circular include, but can't find either of those problems in my code. Forward declaration in SdlWindow.cpp doesn't help. Including the header again (so I /do/ have a circular include) doesn't help either (I get "previously defined" errors).
Main.cpp:
#include <WBS/SdlWindow.hpp>
int main(int argc, char **argv) {
WBS::SdlWindow myWindow("Test window", 640, 480);
return 0;
}
SdlWindow.hpp:
#ifndef SDLWINDOW_HPP_
#define SDLWINDOW_HPP_
#include <string>
#include <SDL/SDL.h>
namespace WBS {
class SdlWindow {
public:
//Member Variables
SDL_Surface *screen;
int xSize;
int ySize;
//Constructor and Destructor
SdlWindow(std::string title, int xSize, int ySize);
virtual ~SdlWindow();
//Member Functions
};
}
#include "SdlWindow.cpp"
#endif /* SDLWINDOW_HPP_ */
And SdlWindow.cpp:
#include <string>
namespace WBS {
SdlWindow::SdlWindow(std::string title, int xSize, int ySize) {
this->xSize = xSize;
this->ySize = ySize;
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(xSize, ySize, 32, SDL_ANYFORMAT);
SDL_WM_SetCaption("Simple Window", "Simple Window");
}
SdlWindow::~SdlWindow() {
SDL_FreeSurface(screen);
SDL_Quit();
}
}
The error I get is "SdlWindow' does not name a type", in SdlWindow.cpp, where I declare the two SdlWindow functions. What's causing this and how can I fix it?
I'm compiling with mingw32's gcc in Eclipse on Windows Vista.
I see what you are trying to do: a header-only library implies that .cpp file is included into .h file and not the other way around (this is, of course, confusing for many people). But if you are doing it that way, then you should not attempt to compile your .cpp files as ordinary source files. In fact, it might be a better idea to give your .cpp file a different extension: a .hpp maybe, for one example.
I suspect that you somehow managed to make SdlWindow.cpp a part of your project, i.e. you are trying to compile your SdlWindow.cpp by itself, as an ordinary source file. This will not work for obvious reasons. If your are trying to implement a header-only library, then no files from that library should be compiled as ordinary source files.
Of course, on an additional note, this whole thing will not work the way it looks now. A header-only library cannot contain non-inline non-template functions. It works for Boost because in Boost the functions are templates. Your functions are not templates. You have to declare them inline then, or otherwise you'll end up with multiple-definition errors for each of your functions.
You need to #include <WBS/SdlWindow.hpp> from SdlWindow.cpp.
You need to include WBS/SdlWindow.hpp from SdlWindow.cpp, as Sam said, but also you do not need to include SdlWindow.cpp from its header (that's a Bad Thing waiting to happen).