How to use lemon graph library on Omnet++ projects? - omnet++

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")

Related

How to write my own application derived from UdpBasicApp in Omnet++ (inet)?

I want to derive a class from UdpBasicApp of inet in Oment++. Indeed, I want to write my own application. I wrote the following code, but when I compile the project, I have an error. For compiling this project without any error, what should I do?
Creating executable: out/clang-release//Manet_1.1.exe
out/clang-release//MyApp.o:(.rdata[_ZTIN4inet11UdpBasicAppE]+0x10): undefined reference to `typeinfo for inet::ApplicationBase'
out/clang-release//MyApp.o:(.rdata[_ZTV5MyApp]+0x640): undefined reference to `non-virtual thunk to inet::OperationalBase::handleOperationStage(inet::LifecycleOperation*, int, inet::IDoneCallback*)'
clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:101: out/clang-release//Manet_1.1.exe] Error 1
MyApp.h
#include "../../inet/src/inet/applications/udpapp/UdpBasicApp.h"
using namespace inet;
class MyApp : public UdpBasicApp
{
public:
};
MyApp.c
#include "MyApp.h"
Define_Module(MyApp);
MyApp.net
import inet.applications.udpapp.UdpBasicApp;
simple MyApp extends UdpBasicApp
{
#class(MyApp);
}
Clearly you are working in your own project which does NOT properly link with the INET model. You MUST select INET as a project reference in your own project's project properties dialog. That will add INET's include folder to the include path, so you would need to (properly) write only
#include "inet/applications/udpapp/UdpBasicApp.h"
instead of
#include "../../inet/src/inet/applications/udpapp/UdpBasicApp.h"
And the linker command line would be also modified to link with the INET shared library properly.

How to use LEDA graph library on Omnet++ projects?

I am trying to use LEDA-6.3 library in Omnet++ 4.2.2. I installed LEDA and ran a simple program using it without problem from Ubuntu terminal. However, when I port the code to Omnet++, it fails. Below is my simple code.
#include <LEDA/graph/graph.h>
#include <omnetpp.h>
class cLeda : public cSimpleModule
{
protected:
virtual void initialize();
};
Define_Module(cLeda);
void cLeda::initialize()
{
EV << "TestLEDA";
graph g;
g.read("nsfnet.txt");
EV << "No. nodes = " <<g.number_of_nodes() << endl;
}
I configured for LEDA paths for compiler and linker as follows: Project -> Properties --> Choose C/C++ General -> Path and Symbols and added:
For Library Paths: /home/grsst/LEDA-6.3/incl
For Libraries: /home/grsst/LEDA-6.3/libleda.a (I didn't add libleda.o
since it doesn't work even with Ubuntu command line)
For Library Paths: /home/grsst/LEDA-6.3
When I compile, the I got errors as follows:
Description Resource Path Location Type
make: *** [all] Error 2 TestLeda C/C++ Problem
make[1]: *** [../out/gcc-debug/src/TestLeda] Error 1 TestLeda C/C++ Problem
undefined reference to `leda::graph::~graph()' cLeda.cc /TestLeda/src line 26 C/C++ Problem
undefined reference to `leda::graph::graph()' cLeda.cc /TestLeda/src line 24 C/C++ Problem
undefined reference to `leda::graph::read(leda::string)' cLeda.cc /TestLeda/src line 25 C/C++ Problem
undefined reference to `leda::memory_manager_init::~memory_manager_init()' TestLeda line 145, external location: /home/grsst/LEDA-6.3/incl/LEDA/system/memory_std.h C/C++ Problem
undefined reference to `leda::memory_manager_init::memory_manager_init()' TestLeda line 145, external location: /home/grsst/LEDA-6.3/incl/LEDA/system/memory_std.h C/C++ Problem
undefined reference to `leda::memory_manager::deallocate_bytes(void*, unsigned int)' TestLeda line 52, external location: /home/grsst/LEDA-6.3/incl/LEDA/internal/handle_types.h C/C++ Problem
undefined reference to `leda::std_memory_mgr' TestLeda line 52, external location: /home/grsst/LEDA-6.3/incl/LEDA/internal/handle_types.h C/C++ Problem
undefined reference to `leda::string::string(char const*)' cLeda.cc /TestLeda/src line 25 C/C++ Problem
I appreciate any idea to help me to make it work. Thanks a million.
OMNeT++ project usually uses Makefile. Try to add LEDA libraries as a Makefrag.
Go to Project Properties, choose OMNeT++ | Makemake | select src | Options | Custom | Makefrag and write:
INCLUDE_PATH += -I/home/grsst/LEDA-6.3/incl
LIBS += -L/home/grsst/LEDA-6.3 -lleda

Veins file can't find other Veins file - no such file or directory

I want to use TraCIMobility.h from Veins to change some SUMO variables for visualization.
I receive an error, when building my project. TraCIMobility.h can't find BaseMobility.h, which is also part of Veins. Are there some problems inside the Veins project? I built it one more time, but it can't find its own modules. I added Veins to my project with Project->Properties->Project References.
This is the error:
10:12:16 **** Incremental Build of configuration gcc-debug for project CloudBasedCSW ****
make MODE=debug CONFIGNAME=gcc-debug all
cd src && make
make[1]: Entering directory `/c/work/Cloud_Curve_Speed_Warning/trunk/src/CloudBasedCSW/src'
visualization/Visualization.cc
In file included from ./visualization/Visualization.h:19:0,
from visualization/Visualization.cc:16:
C:/Tools/veins/src/veins-3.0/src/modules/mobility/traci /TraCIMobility.h:31:26: fatal error: BaseMobility.h: No such file or directory
make[1]: Leaving directory `/c/work/Cloud_Curve_Speed_Warning/trunk/src/CloudBasedCSW/src'
compilation terminated.
make[1]: *** [../out/gcc-debug/src/visualization/Visualization.o] Error 1
make: *** [all] Error 2
10:12:17 Build Finished (took 726ms)
This is the header, which includes TraCiMobility.h
#ifndef VISUALIZATION_H_
#define VISUALIZATION_H_
#include <omnetpp.h>
#include "modules/mobility/traci/TraCIMobility.h"
class Visualization: public cSimpleModule{
public:
Visualization();
virtual ~Visualization();
void initialize();
void handleMessage(cMessage *msg);
void setIce(std::string laneId);
void removeIce(std::string laneId);
};
#endif /* VISUALIZATION_H_ */
You didn't say which Veins version you are using, so I am assuming the newest, Veins 4a2. Here, you will need to specify the include path like so
#include "veins/modules/mobility/traci/TraCIMobility.h"
To clarify: the --meta:auto-include-path option to opp_makemake will always generate a -I include path that includes all of the missing components to make the include work (that is, writing as little as #include "traci/TraCIMobility.h" would yield a compiler flag of -I..../veins/src/veins/modules/mobility), but without adding a -I include path to the root of Veins, none of the includes within work. By specifying the full path to the file (relative to the source root of Veins), you are forcing opp_makemake to generate a -I include path of -I..../veins/src, which is what is needed to build Veins.

Unknown error when compiling Clang 3.3 with Mingw

I'm not able to compile clang(3.3) using MinGW 4.8.1. The following error always pops-up when 70% build is complete:
clang/lib/Basic/FileManager.cpp includes sys/stat.h, which defines #define stat _stat64i32 (actually there are a few other defines in between, but you get the idea ;)
clang/include/clang/Basic/FileManager.h does not include sys/stat.h; instead only has a forward-declaration.
Hence, while parsing the header, the forward declaration is used (struct stat)
But when it finally arrives at the implementation, the preprocessor will kick in and replace struct stat with struct stat64i32. Hence the mismatch.
The best solution would be to change the forward declaration in the header to instead include sys/stat.h. (I didn't actually test if it will compile then)
The current trunk does not contain the code anymore.
Update: regarding off64_t. This is defined in _mingw_off_t.h these days as:
#ifndef _OFF64_T_DEFINED
#define _OFF64_T_DEFINED
__MINGW_EXTENSION typedef long long _off64_t;
#if !defined(NO_OLDNAMES) || defined(_POSIX)
__MINGW_EXTENSION typedef long long off64_t;
#endif
#endif /*_OFF64_T_DEFINED */
So you probably want to define _POSIX before including io.h (or stdio.h)

Does gcc 4.3.4 support unique_ptr?

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>.

Resources