I have defined a class Executer splited in Executer.hpp and Executer.cpp.
In Executer.hpp there is the code:
static std::unique_ptr<Executer> mInstance;
static std::once_flag mOnceFlag;
In Executer.cpp there is the code:
std::unique_ptr<Executer> Executer::mInstance;
std::once_flag Executer::mOnceFlag; // without this apparently
// useless line of code, the program using this shared lib
// claims: undefined reference to `Executer::mOnceFlag'
After that I try to let eclipse organize my imports.
What I get is:
//------------------------------- Executer.hpp
#include <memory>
#include <stdexcept>
#include <string>
namespace std {
struct once_flag;
} /* namespace std */
//------------------------------- Executer.cpp
#include "Executer.hpp"
#include <mutex>
What I expect (and also is compiled correctly):
//------------------------------- Executer.hpp
#include <memory>
#include <mutex>
#include <stdexcept>
#include <string>
//------------------------------- Executer.cpp
#include "Executer.hpp"
Why is Eclipse behaving in that way?
Can I configure Eclipse in such a way that I get my way of organizing the includes (I have seen the many options, but I got things worst)
Why is Eclipse behaving in that way?
The type of a static data member is not required to be complete at the point of the data member's declaration. That is, the declaration will compile with the type having been just forward-declared, not defined.
The default settings for "Organize Includes" try to minimize the number of headers that are included in other headers, to speed up compile times, so when a forward declaration of a type is sufficient, it prefers to create one rather than to include the header than defines the type.
Can I configure Eclipse in such a way that I get my way of organizing the includes (I have seen the many options, but I got things worst)
Unchecking Forward declare classes, structs and unions in Preferences | C/C++ | Code Style | Organize Includes should give you the behaviour you desire.
Related
This question is pretty weird.
Say I have a file, called idiot.cpp, and it begins with:
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>
#include <string>
#include <set>
#include <exception>
#include <iostream>
#include "idiot.h"
and I have a header file, idiot.h. First of all, in idiot.h, do I also have to insert
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>
#include <string>
#include <set>
#include <exception>
#include <iostream>
or do I not?
Second, if I have another source file, say, "bonito.cpp," that uses idiot.h, should I just #include "idiot.h", or should I paste in the code snippet again?
If not, is there any way to shorten this so I don't end up including around 20 headers per file? (hypothetically)
Sorry if this is a pretty dumb question, but I don't use many headers too often.
idiot.cpp does not need to include anything included indirectly by idiot.h to be able to compile.
The more interesting case: bonito.cpp #includes idiot.h and idiot.h includes x.h. If idiot.h only uses the content of x.h for private or anonymous namespace code - and bonito.cpp wants to use something from x.h too, then bonito.cpp should include x.h directly (redundantly).
The justification is simple: idiot.h can't remove something from the public/protected interface without risking breaking client code, so if that happens then the clients have to expect to deal with it - possibly including an extra header too. BUT, the maintainer of idiot.h and idiot.cpp should be free to change private or anonymous namespace content within idiot.h without risking breaking client code, including which headers are included to support that private code.
So, the inclusion is redundant at the time it's done, but that's done in the expectation that it might stop being redundant as idiot.h evolves.
This best-practice model is not automatically enforced - you have to understand the way this should work and actively code to that model.
Example
If idiot.h contains...
#include <string>
#include <vector>
...
class X {
void add(const std::string&);
private:
std::vector<std::string> v_;
};
...then bonito.cpp can reasonably use std::string without including <string>, but should include <vector> itself if it needs std::vector<>.
I am trying to move a few tests into the XCTest target of my application in Xcode. The library I am testing functionalities for is large, and I include its header files inside my tests.mm file (my Obj-C++ testing file where all unit test cases are).
For one specific "Size" type, Compiler reports a series of ambiguous clashes with the Size type already defined as part of the SDK for MacOS10.13 (in /usr/include). Here is how the #include set for my testing file looks like:
#import <XCTest/XCTest.h>
#include <ql/quantlib.hpp>. <---- defines Size, which clashes with MacTypes.h definition
#include <Analytics/all.hpp>
#include <boost/timer.hpp>
#include <utility>
#include <typeinfo>
#include <thread>
#include <atomic>
#include <mutex>
#include <random>
#include <condition_variable>
#include <future>
using namespace src::Utilities;
using namespace src::Simulation;
using namespace src::MarketData;
using namespace src::detail;
using namespace std::placeholders;
//...More code down here, but not problematic
is the file which contains the definition for Size. Can someone please help spot where I may have gone wrong, especially that when I run the tests as part of a giant Main() function, it all works fine.
Thanks,
Amine
Update: After some research, I think I found what was going on with this issue: "using namespace xxxx" inside Objective-C++ testing framework instead of fully qualifying the data types with xxxx:: clashes with native Apple API types (Size, Handle, ptr, etc...). Full namespace qualification of C++ data types is required in this case to avoid ambiguity.
Sorry if this question's title was phrased poorly, but I have a class with a member function that in turn calls a couple of OpenGL functions:
class StateSet
{
public:
StateSet();
// ...
inline void SetVertexAttributeEnabled(GLuint location,bool enabled)
{
if(m_GL_VERTEX_ATTRIB_ARRAY_ENABLED[location] == enabled) {
return;
}
m_GL_VERTEX_ATTRIB_ARRAY_ENABLED[location] = enabled;
if(enabled) {
glEnableVertexAttribArray(location);
}
else {
glDisableVertexAttribArray(location);
}
}
// ...
When trying to compile this, I get
'glEnableVertexAttribArray' was not declared in this scope
'glDisableVertexAttribArray' was not declared in this scope
If I don't make the function inline (take out the 'inline' keyword) and define the function in the corresponding source file, it works fine. The source file doesn't have any additional includes, it just includes the header file, which in turn includes:
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
So why would inlining make the compiler unable to 'see' the OpenGL function calls?
This doesn't happen for all OpenGL functions either -- I can compile if I try calling glDrawArrays, glGet[], etc.
More information:
All the includes for the header and source file in question are:
#include <vector>
#include <cassert>
#include <sstream>
#include <iostream>
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
OpenGL and its context and everything should be set up by Qt; this class is being used in a Qt application where I can already call the functions (glEnable/DisableVertexAttribArray) and everything seems to be set up ok.
This also might be a namespace issue, the things that are working might be #defines in the header which wouldn't be affected by the namespace, while in one of the files an #include statement might be inside of a namespace which is affecting normal function definitions. Sorry, just kind of guessing, I am absolutely positive there is something weird going on though.
I was able to get around this by passing a define option to the compiler instead of relying on the following define macro:
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
I don't really know why that ended up working. I think it implies that when the compiler first reads in GL/glext.h, GL_GLEXT_PROTOTYPES isn't defined.
I'm not sure in what order preprocessor #defines take effect but I guess its possible that GL/glext.h got included somewhere else first?
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.
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 ...