I am trying to compile this code, and g++ keeps telling me that 'TimeFinder' has not been declared
Header File
#ifndef _TIMEFINDER_H
#define _TIMEFINDER_H
#include <vector>
#include "timefinder.cpp"
using namespace std;
class TimeFinder
{
public:
static vector<int> time_from_name(string filename);
static int calc_seconds (vector <int> time);
};
#endif
CPP File
#include "timefinder.h"
using namespace std;
vector<int> TimeFinder::time_from_name(string filename)//Line 14
{
//Method Body
}
int TimeFinder::calc_seconds (vector <int> time1)//Line 37
{
//Method Body
}
Why is this going on? I looked at other examples online, and my code seems to match what works for other people...
Edit: The exact error messages are
timefinder.cpp:14: error: ‘TimeFinder’ has not been declared
timefinder.cpp:37: error: ‘TimeFinder’ has not been declared
Edit2: I'm sorry I'm not very good at this yet, but I would like to thank everyone for their suggestions. Hopefully my code quality will begin to improve because of them.
Do not do this:
#include "timefinder.cpp"
You are pulling your definitions into your header so they appear before their declarations.
There is a lot of other stuff wrong with your code - the use of static members in the first place, passing vectors and strings by value when they should be references, and placing using directives in header files, but removing that #include should fix the immediate problem.
#include "timefinder.cpp"
Header files usually don't include their .cpp implementation file but only whatever other .h file is required to satisfy the definitions required. Usually it's the other way around where .cpp files include the required .h files necessary to fulfill the dependencies.
using namespace std;
This can also cause a lot of havoc and should be avoided in header files. In header files you should always fully qualify your names with their namespace. The reason is if you import this header file into another one that defines the same symbol locally in their namespace like "cout" then both the std::cout and user::cout would clash and cause a compile error or even worse possibly pick the wrong definition and cause a linking error later.
Related
I'm working on a C++ project.
I had a class with its function, then I realized some of those functions weren't related to that class but were just math functions so I decided to move them on to a namespace.
My first question is, what is the appropriate file extension for a c++ namespace?
I have a constants.h file where I plan on saving global constants, for example PI.
Right now:
#include <math.h>
const double PI = M_PI;
I have the namespace I talked about before, right now is called: specificMath.h
#include <stdlib.h>
#include "constants.h"
... more code
I have a gaussian.cpp:
#include "gaussian.h"
#include "specificMath.h"
#include <iostream>
... more code
This file includes a main function that right now does nothing, I just can't get the whole project to compile without a main...
I have a gaussian.h where I'm not including anything, is that wrong?
A third class, which has no attributes, just methods (again, is this wrong? or not pretty?). truncatedFunctions.cpp
#include "specificMath.h"
#include <stdlib.h>
#include "truncatedFunctions.h"
#include "gaussian.h"
using namespace specificMath;
And its truncatedFunctions.h where, again, I'm not including anything.
And a fourth class where I include
#include "margin.h" //Its header, where I'm not including anything
#include "gaussian.h"
#include "specificMath.h"
using namespace specificMath;
When I "make" it, it seems to compile fine, but when it gets to the linking part I get A LOT of errors saying that things on my margin.cpp class were first defined in truncatedFunctions.cpp
I am going crazy. I have no idea why this is happening, or how to solve it. I would really appreciate if somebody could help me out, and please, any extra piece of advice would be great since I am really trying to learn as much as I can with this project. Thanks!
When I "make" it, it seems to compile fine, but when it gets to the linking part I get A LOT of errors saying that things on my margin.cpp class were first defined in truncatedFunctions.cpp
Did you define your functions in your specificMath.h? You should only declare those functions.
For example, if your specificMath.h contains function definitions like
#ifndef COOL_STUFF_NSPC
#define COOL_STUFF_NSPC
#include <iostream>
namespace coolstuff{
void print(void){std::cout << "I'm declared in a header file." << std::endl;
}
#endif
and you are using including this file in several others, the linker is going crazy. Including means copying. And so you've got yourself coolstuff::print defined several times. The better way (and the only possible way when using self-written functions in many files) is splitting your code into a header and implementation as you did in gaussian.
// coolstuff.namepace.h
#ifndef COOL_STUFF_NSPC
#define COOL_STUFF_NSPC
namespace coolstuff{
void print(void);
}
#endif
When you include coolstuff.namespace.h it will only declare functions. And you can declare the same function several times.
// coolstuff.namespace.cpp
#include <iostream>
#include "cs.h"
void coolstuff::print(void){
std::cout << "Hello world!" << std::endl;
}
The .cpp file contains the implementation of your functions. Now your linker won't get irritated because there is only one implementation of coolstuff::print and not n (where n is the number of #include "cs.namespace.h" you used) ones.
My first question is, what is the appropriate file extension for a c++ namespace?
There is no standard namespace extension. Use .h/.cpp for header/implementation and a self-defined prefix, something like 'nmspc' or 'nsc'. It's up to you.
It's hard to tell whether you've done anything wrong in your code (because you didn't show any of it), but the first thing to try is to "clean" your build and rebuild all your code. If the compiler (don't know what you're using) for some reason didn't compile all your modified modules, then it's not surprising that the linker is having trouble.
My first question is, what is the appropriate file extension for a c++ namespace?
In C++, header files are usually .h or .hpp. It doesn't matter to the compiler.
#include "gaussian.h"
#include "specificMath.h"
#include <iostream>
In general, it's a good idea to #include stuff from the standard library first, followed by your own things.
I have a gaussian.h where I'm not including anything, is that wrong?
No. If you don't need to include anything, don't include anything.
First, use include guards for the headers.
#ifndef MYHEADER_H
#define MYHEADER_H
//header contents
#endif
This will prevent the same header from being included twice in the same translation unit.
Second, don't define uncosnt stuff in the headers:
double x = 0;
this will cause all translation units to export that symbol.
Declare the variable extern in your header and provide a definition for it in an implementation file.
Sample.h
namespace Testing
{
enum Type
{
DATA = 0,
MORE_DATA
};
}
Now in Sample2.h, using the same namespace, can I access the DataType defined in Sample.h, without including it?
namespace Testing
{
Type test;
}
The question has come up, because I have files that implement this, and seem to build with no problem.
Another user is trying to build, but reports that he has to #include "Sample.h" in Sample2.h in order to build.
Most likely the files build because some earlier include file is including Sample.h for you. When the earlier include file is omitted (or moved after Sample2.h) the files will no longer compile.
Forward enum declarations are not supported in most current compilers. It is a planned feature of up coming C++0x. You can create pointers to Type probably, but cannot instantiate, this is compatible with other types (structs and classes) as well.
Ow, my bad, I saw it wrong i guess. Anyway, read the others and read this as well. Headers are not compiled stand alone. Therefore, if you don't include a required heading in your header and included that in the cpp file you will not run into any errors. As long as all the cpp files contain both headers with the required order there will be no problems at all. However, this is not a good idea, it is best to include any necessary files within your header and use header guards to ensure they are not added twice. I hope this makes sense.
Yes, you will need to include Sample.h within Sample2.h. The definition of Type is not visible to the compiler within Sample2.h simply because the namespace name is the same within the 2 files.
The only thing you gain by having the same namespace names in the 2 files is that Type does not need to have its namespace stated explicitly in Sample2.h. For instance, if the 2 namespaces were not the same:
Sample.h
namespace Testing
{
enum Type
{
DATA = 0,
MORE_DATA
};
}
Sample2.h
#include "Sample.h"
namespace Testing1
{
Testing::Type test;
}
I'm porting some open source code so that it can build on another c++ compiler. One of the difficulties and themes that seem to keep cropping up are implementation differences of the provided standard library by the compiler.
For example, one of the source files that I'm compiling includes <sys/types.h>. However, it gives me the following errors:
Error E2316 g:\Borland\BCC593\Include\sys/types.h 45: 'time_t' is not a member of 'std'
Error E2272 g:\Borland\BCC593\Include\sys/types.h 45: Identifier expected
After looking at the root cause of this I found that one of the main include headers of the project is including <sys/types.h> in this pattern:
project_source1.cpp:
#include "../TargetPlatform.h"
#include "project_config.h"
#include <windows.h>
namespace project_namespace {
#include "project_component/all.h"
// more project includes down here
// ...
}
project_component/all.h:
#ifndef INCLUDE_GUARDS
#define INCLUDE_GUARDS
#include <sys/types.h>
#include "project_header1.h"
#include "project_header2.h"
// and other headers etc..
// followed with class definitions and what not.
#endif
This is all well and good except for one problem, the <sys/types.h> is implemented something like this for the compiler I'm porting to:
<sys/types.h> trimmed to the essence:
namespace std {
typedef long time_t;
typedef short dev_t;
typedef short ino_t;
typedef short mode_t;
typedef short nlink_t;
typedef int uid_t;
typedef int gid_t;
typedef long off_t;
} // std
using std::time_t;
using std::dev_t;
using std::ino_t;
using std::mode_t;
using std::nlink_t;
using std::uid_t;
using std::gid_t;
using std::off_t;
And this is the cause of the compile error I'm seeing. Because the project is including <sys/types.h> inside its own namespace, things like time_t, off_t, dev_t etc get put into the scope project_namespace::std:: which is obviously not what's intended.
What's the best way to handle this? Keep in mind there could be other standard library headers defined in a similar fashion and not just sys/types.h. Are there any C++ idioms that's relevant or semi-related to this issue(or possibly even at odds with it due to the way this is implemented)? If so, how can it be reconciled?
Thanks
This is a bad idea. Do not do things this way. Put the namespace declarations inside each header file. Never have a #include directive inside the scope of a namespace.
Never is a strong word, and there are very rare cases in which you might want to do this. If the file you're #includeing also has #include directives, you almost certainly do not want to be doing this, even more so than if they didn't.
If you need to be able to easily rename your namespace or use the same header to declare the same symbols in several different namespaces depending on context, use the preprocessor to change the namespace name instead. That's extremely ugly to do, but much better than what you're currently doing.
One thing you can do as a quick and dirty solution to this is #include <sys/types.h> and any other system header that's included before the namespace declaration. This will cause the double-inclusion guards in the system header files to kick in and avoid declaring stuff inside the namespace.
I would say you need to change the offending code so that the standard types are no longer defined within project_namespace.
It seems to me you have two major issues: [1] you have a catch-all header in project_all.h and [2] it's #included inside namespace project_namespace. I'll address the latter first. If your project has things it wants to put in its own namespace, that's fine, but it should be done as follows:
// Foo.h
// includes go here
namespace project_namespace {
class Foo { ... }
}
// Foo.cpp
// includes go here
namespace project_namespace {
// Foo implementation goes here
}
... in other words, your classes' header and implementation files need to say what namespace the classes belong in, "self-namespacing" as it were. All your #includes are outside a namespace because the header file for each class declares the namespaces the class belongs to. This is the convention used by the standard library.
Now if you still want to use a project_all.h you can do so. Without the namespace -- because each header file will place its declarations in the namespace it wants to (or not).
But it would be better to dispense with project_all.h; instead, #include the header files individually and make the dependencies explicit. And if the response is "there are too many header files", that's probably a sign of a high degree of coupling between your components.
I realize this is probably not the answer you wanted, sorry ...
Say I have created two classes: Tires, and Car.
So I have four files: Tires.cpp, Tires.h, Car.cpp, Car.h.
The Car constructor takes Tires as its parameter. But I am not sure how to modify Car.h to
include Tires.h.
Here's what I've done so far (note: they are in separate files)
Tires.h
#include <iostream>
using namespace std;
class Tires
{
private:
int numTires;
public:
Tires();
};
Tires.cpp
#include <iostream>
#include "Tires.h"
using namespace std;
Tires::Tires()
{
numTires = 4;
}
Car.h
#include <iostream>
#include "Tires.h"
using namespace std;
class Tires; // Tried taking out forward declaration but still didn't work
class Car
{
private:
Tires tires;
public:
Car(Tires); // Edited. Thanks to Noah for pointing out.
};
Car.cpp
#include <iostream>
#include "Car.h"
#include "Tires.h"
using namespace std;
Car::Car(Tires _tires)
{
tires = _tires;
}
Thanks
Your approach seems fine here.
One thing to keep in mind when headers include other headers is that you may find you need to include an include guard:
// At the start of Tires.h:
//
// Only delcare this stuff if this is the first time including Tires.h:
//
#ifndef __myproject_Tires_h__
#define __myproject_Tires_h__
class Tires
{
// [snip]
};
// Close the #ifdef above...
//
#endif
This prevents you from declaring "class Tire {" et al. multiple times, should Tires.h happen to be included twice.
Another is that this line in Car.h is not needed:
class Tires;
This may be useful if you want to have declarations of Tires* or Tires&, but to do what you did next:
class Car
{
private:
Tires tires;
... requires Tires to be a "complete type", for its size to be known, etc. You're already covered by that by having #include "Tires.h" anyway.
Lastly, some consider it bad form to have a using statement inside a header as you have done. This kind of breaks namespaces by bringing in std as a global namespace for all files that use this header. Imagine if every header did this, and did so for multiple namespaces. Eventually this becomes the same as there being no such thing as namespaces, and collisions are more likely.
One thing you need is "include guards" so that you don't get a bunch of compiler errors due to redefinition.
Put something like the following in each of you header files:
#ifndef TIRES_H
#define TIRES_H
// contents of the header file...
#endif
Of course, change the name used for the macro guard (TIRES_H) as appropriate for each file. The macro name needs to be unique - basing it on the header file name is usually good enough. Also, many (most?) compilers support a #pragma once preprocessed directive that prevents headers from being processed more than once, but I still generally use the standard include guards.
This allows headers to be included more than once, since the guards cause subsequent includes of the file to essentially skip the entire contents.
Almost all C/C++ headers should have include guards so users don't need to worry about whether or not a necessary header was already included (the exceptions are headers which need to redefine things differently when included at different times - this is a pretty rare technique). Include guards also enable you to have header files (like cars.h in your example) include the headers they need without regard to what else might also include the headers, so your headers can be self-contained and can be included in any order.
You have already included Tires.h in Car.h. You also have a forward declaration of class Tires in Car.h. You should eliminate either the include or the forward declaration. As you don't handle Tires as reference or pointer and you thus need the "behavior" of class Tires, you should eliminate the forward declaration.
You've basically already answered your own question except that your Car(Tires) constructor has yet to be declared in your Car interface.
But I'd actually not do it that way. Your constructor should be Car(Tires const&) so that you can simply use the forward declaration you've already got in Car.h and not include Tires.h until in Car.cpp. The rest of your code could stay the same, but I'd still make a further change and use initialization rather than assignment in the constructor:
Car::Car(Tires const& _tires) : tires(_tires) {}
Even further, I recommend not EVER using '_' as the first character in any name. There's no need to and too often people get confused about when it is OK and when it is not.
From all files delete line containing "using namespace std;"
From Car.h delete line containing "class Tires;" as it's included from #include "Tires.h"
Now wrap all your header file in header guards.
I have two source files, one named main.cpp (where the namespace M is defined) and the file engines.h (where several names are defined).
main.cpp includes engines.h.
engines.h need to use the stuff inside M, and M needs to use the stuff inside engines.h.
I get an error doing using namespace M; in engines.h.
Don't use using namespace inside header files. This will get all the symbols from the namespace inside each translation unit that includes that header file, so you'll have a symbol mess (name conflict, which is probably what you're facing in your situation). Use full qualification inside the header files, or at least use the using namespace statement locally (inside a function or method where you what to improve readability).
For your situation, what is the error you get? What is the content of the headers?
You cannot do using namespace M before the namespace was defined. If there is a cyclic dependency, you need to solve it by using one or more techniques
Forward declare if your uses don't need to know the members or size of classes, but just handle with pointers or references to them:
namespace M { class MyCow; }
Define stuff in engines.cc
// engines.h
void f();
// engines.cpp
#include "main.h"
void f() { MyCow muuh; }
Use of the pimpl idiom reduces dependencies even more, as it keeps headers free of headers that are only used by implementations..
Split the part in .h files for the interface and .cpp files for the implementation to handle such dependencies. That way, headers are less dependent on other headers, and implementation files can include the headers.