I'm usual to build with consider warning as error. I'm using Boost C++ 1.54.0 with MinGW 4.8.1, in particular I'm using ptree.
#include <iostream>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>
using namespace std;
int main() {
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
return 0;
}
This simple program cause the following errors:
typedef 'cons_element' locally defined but not used [-Wunused-local-typedefs] line 228, external location: \boost\tuple\detail\tuple_basic.hpp
typedef 'Str' locally defined but not used [-Wunused-local-typedefs] line 38, external location: \boost\property_tree\detail\xml_parser_write.hpp
typedef 'Str' locally defined but not used [-Wunused-local-typedefs] line 72, external location: \boost\property_tree\detail\xml_parser_write.hpp
typedef 'T_must_be_placeholder' locally defined but not used [-Wunused-local-typedefs] line 37, external location: \boost\bind\arg.hpp
Is a way to ignore this warnings?
gcc allows ignoring specific warnings since 4.6
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-local-typedefs"
...
...
#pragma GCC diagnostic pop
there are still some warnings that cannot be turend off this way, but it works for most
or do it like the other mentioned and add -Wno-unused-local-typedefs to the commandline
Related
I am trying to make the following code work on both Linux and FreeBSD based system, Is it a valid usage of macros __GLIBC__ and __USE_XOPEN2K8?
#include <stdio.h>
#include <langinfo.h>
#include <locale.h>
#include <xlocale.h>
int main(void) {
//#if defined(__GLIBC__) && defined (__USE_XOPEN2K8)
locale_t loc;
char *locale_messages = "en-US.utf-8";
loc = newlocale(LC_ALL_MASK, locale_messages, (locale_t)0);
if (loc != NULL)
{
char result[256];
sprintf(result, "%s_%s.%s",
nl_langinfo_l(_NL_IDENTIFICATION_LANGUAGE, loc),
nl_langinfo_l(_NL_IDENTIFICATION_TERRITORY, loc),
nl_langinfo_l(CODESET, loc));
}
//#endif
}
If I don't use those directives, I get the following error on mac OS. I want to disable that code to avoid the following errors.
error: use of undeclared identifier '_NL_IDENTIFICATION_LANGUAGE'
nl_langinfo_l(_NL_IDENTIFICATION_LANGUAGE, loc),
^
error: use of undeclared identifier '_NL_IDENTIFICATION_TERRITORY'
nl_langinfo_l(_NL_IDENTIFICATION_TERRITORY, loc),
I have found one thread recommending use _GNU_SOURCE and _XOPEN_SOURCE, but as result above code is disabled on my linux system too. It seems I need to define _GNU_SOURCE before using it, but before proceding with this idea, can we work with __GLIBC__ and __USE_XOPEN2K8.
You can use
#indef __FreeBSD__
#endif
preprocessor directives to ignore the code that shouldn't be built on FreeBSD. However man nl_langinfo_l on FreeBSD says that this function is present on FreeBSD, so you shouldn't have any problems with it.
The best way is to use a build system to detect if that option is available and then conditionally enable that part of code depending of the detection result. This is how autotools project came to be - to detect differences between operating systems.
In cmake you could:
include(CheckCSourceCompiles)
check_c_source_compiles("
#define _GNU_SOURCE
#define _SOMETHING_READ_FEATURE_TEST_MACROS
#include <something something that is needed.h>
int main() { return _NL_IDENTIFICATION_TERRITORY; }
" WE_HAVE_NL_IDENTIFICATION_TERRITORY)
if(WE_HAVE_NL_IDENTIFICATION_TERRITORY)
target_add_definitions(your_target PUBLIC LIB_HAS_NL_IDENTIFICATION_TERRITORY)
endif()
and then use your own LIB_HAS_NL_IDENTIFICATION_TERRITORY macro that detect if that option is available or not. Such solution is stable, easy to port and dynamically reacts to environment changes.
I am trying to design a network(Random Graph) in omnet++ where I want to parse the network nodes using Lemon Graph Library. I have installed the library and it works fine if I try to compile any normal c++ file with nodes and edges in any graph using command line g++ -o file file.cpp/cc -lemon. But when i tried it with one of my omnet++ project(which has nothing in it now) the code is as below
#include <omnetpp.h>
#include <iostream>
#include <lemon/list_graph.h>
using namespace lemon;
using namespace std;
class Facility : public cSimpleModule
{
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Facility);
void Facility :: initialize(){
}
void Facility :: handleMessage(cMessage *msg){
}`
the include headers are in angle brackets(not to be confused with double quotes). So when i build the code I get the following errors:
Description Resource Path Location Type
‘class cEnvir’ has no member named ‘push_back’ PSUC line 686, external location: /usr/local/include/lemon/bits/graph_extender.h C/C++ Problem
‘class cEnvir’ has no member named ‘push_back’ PSUC line 687, external location: /usr/local/include/lemon/bits/graph_extender.h C/C++ Problem
‘test’ does not name a type test.cc /ztest line 9 C/C++ Problem
invalid use of qualified-name ‘cSimulation::getActiveEnvir’ PSUC line 69, external location: /home/vijay/omnetpp-4.6/include/cenvir.h C/C++ Problem
make: *** [out/gcc-debug//psuc.o] Error 1 PSUC C/C++ Problem
make: *** [out/gcc-debug//test.o] Error 1 ztest C/C++ Problem
no matching function for call to ‘lemon::AlterationNotifier<lemon::GraphExtender<lemon::ListGraphBase>, lemon::ListGraphBase::Arc>::add(cEnvir&)’ PSUC line 688, external location: /usr/local/include/lemon/bits/graph_extender.h C/C++ Problem
Why doesn't the Omnet++ code get compatible with Lemon graph Library?
OMNeT++ includes a macro definition for ev in cEnvir.h (which is included from omnetpp.h)
#define ev (*cSimulation::getActiveEnvir())
Because you include omnetpp.h before graph_extender.h, this macro is expanded in the library's header file, which conflicts with its use as a variable name in
ev.push_back(Parent::direct(edge, true));
A simple solution would be to include graph_extender.h before omnetpp.h, so the macro is not yet defined when graph_extender.h is read. If this is not possible, you might have some luck with manually undefining the macro before (and possibly restoring the definition after), as follows.
#pragma push_macro("ev")
#undef ev
#include "graph_extender.h"
#pragma pop_macro("ev")
I'm experiencing some sort of issue trying to compile a perfectly (windows+linux tested) mpi+openmp software I wrote my own.
I've managed to install and set to work the omp-adapted version of clang, and it works flawlessly in a simple omp "hello world" I've prepared.
As well I've installed open-mpi via homebrew, and the mpi "hello world" is working as well.
Now there come the issue.
Firstly, not so much confident in clang and openmp working together, I've created a version of my software without openmp calls. This version (MPI-only) of the code has been compiled with no issue.
Now comes my real dilemma.
I've reverted back the omp sections of my code, and tried to compile it with both MPI and openMP flags (mpic++ wrapper with ompclang forced in and -fopenmp flag added). The output of the compiler verbose mode is here below.
[...]
/usr/local/Cellar/open-mpi/1.8.4/include/openmpi/ompi/mpi/cxx/mpicxx.h:39:10:
fatal error: 'utility' file not found
#include <utility>
^
[...]
/usr/local/Cellar/open-mpi/1.8.4/include/openmpi/ompi/mpi/cxx/mpicxx.h:39:10:
fatal error: 'utility' file not found
#include <map>
^
[...]
After this output I tried to compile something like this:
#include <iostream>
#include <map>
#include <utility>
int main(int argc,char* argv[]){
std::cout<<"Hello World!!!!"<<std::endl;
return 0;
}
And the output keeps me saying the compiler can't find map, utility AND iostream as well.
It appears to me the problem is the compiler doesn't know where to find the standard c++ libraries.
Can anyone of you tell me how to solve this? Thanks in advance
Have fun,
gf
EDIT:
I've found a good suggestion from this site:
http://lists.cs.uiuc.edu/pipermail/cfe-users/2013-November/000293.html
That helped me to solve the issue.
I post the OMP+MPI hello world if anyone ever needs to test them together.
#include <mpi.h>
#include "omp.h"
int main(int argc, char** argv) {
// Initialize the MPI environment
MPI_Init(NULL, NULL);
// Get the number of processes
int world_size;
MPI_Comm_size(MPI_COMM_WORLD, &world_size);
// Get the rank of the process
int world_rank;
MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
// Get the name of the processor
char processor_name[MPI_MAX_PROCESSOR_NAME];
int name_len;
MPI_Get_processor_name(processor_name, &name_len);
// Print off a hello world message
#pragma omp parallel
printf("Hello from thread %d, nthreads %d,from processor %s, rank %d out of %d processors\n", omp_get_thread_num(), omp_get_num_threads(),processor_name, world_rank, world_size);
// Finalize the MPI environment.
MPI_Finalize();
}
Have fun
gf
I've been trying to implement PIMPL using the g++ compiler on my local CygWin install and I'm beginning to think it may be the fact that I'm running g++ 4.3.4, inasmuch as its C++11 support is less than perfect.
With the very baseline code (from MSDN here):
my_class.h:
#include <memory>
class my_class {
public:
my_class();
private:
class impl; unique_ptr<impl> pimpl(new impl);
};
my_class.cpp:
#include "my_class.h"
class my_class::impl { int my_int; };
my_class::my_class(): pimpl( new impl ) {};
I try to compile with g++ -std=c++0x -o my_class.o my_class.cpp and end up with:
In file included from my_class.cpp:1:
my_class.h:8: error: ISO C++ forbids declaration of 'unique_ptr' with no type
my_class.h:8: error: invalid use of '::'
my_class.h:8: error: expected ';' before '<' token
my_class.cpp: In constructor 'my_class::my_class()':
my_class.cpp:5: error: class 'my_class' does not have any field named 'pimpl'
I also get that if I substitute -std=gnu++0x.
In fact, when I try to compile even the simplest file, lifted from another SO answer:
#include <iostream>
#include <memory>
int main() {
std::unique_ptr<int> up( new int( 30 ) );
}
it complains that unique_ptr is not in the std namespace.
The gcc c++11 support page has no entry for unique_ptr but, from looking at the net, it's been around for quite a while, at least since 4.4.
So my question is, firstly, at what version of gcc was support for unique_ptr added?
And, secondly, am I just making some bonehead mistake in my code, using it the wrong way?
In your first example, the std:: qualifier is missing on unique_ptr. The second example is correct C++11.
According to the GCC 4.4 release notes, unique_ptr was not in GCC's standard C++ library before 4.4:
Improved experimental support for the upcoming ISO C++ standard, C++0x, including:
...
unique_ptr, <algorithm> additions, exception propagation, and support for the new character types in <string> and <limits>.
I'm trying to write and compile some C code which I would use frm MATLAB with VS 2012
Here is my header file:
#ifndef _DLLTEST_H_
#define _DLLTEST_H_
#include <iostream>
#include <stdio.h>
#include <windows.h>
extern "C" __declspec(dllexport) int Add(int a, int b);
#endif
And here is implementation:
#include "stdafx.h"
#include "nureader.h"
extern "C" __declspec(dllexport) int Add(int a, int b)
{
return (a + b);
}
Compilation goes fine, but when I try to load DLL to MATLAB, I getting a strange error:
>> [a,b] = loadlibrary('nureader.dll', 'nureader.h')
Error using loadlibrary (line 419)
Failed to preprocess the input file.
Output from preprocessor is:nureader.h
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\eh.h(27) : fatal error C1189: #error : "eh.h
is only for C++!"
Take a look at VS output
fatal error C1189: #error : "eh.h is only for C++!"
You want to write a C library, right? so don't include C++ in it. or compile with G++ but since you're using windows I don't think you have that option...
In any case, track down what includes "eh.h" and try without it. If it builds without it - great, if not - you will need to only isolate the C portion of your program. By looking at the code, you don't seem to need anything more than
#include <stdio.h>
#include <windows.h>
So try that.