[Omnetpp-l] [Q] Use of "pure virtual function" in the base class declaration in Ver. 4.0rc1

[Kyeong Soo (Joseph) Kim]

Dear All,

I recently started the migration of my simulation code base to 4.x platform and faced the following errors:
============================================================================
**** Build of configuration gcc-debug for project success ****

make MODE=debug CONFIGNAME=gcc-debug all
g++ -c -gstabs+ -Wall -fno-stack-protector   -I/usr/include  -DHAVE_PCAP -DXMLPARSER=libxml -DWITH_PARSIM -DWITH_NETBUILDER  -I. -Ie:/Tools/omnetpp/include -o out/gcc-debug//scheduler.o scheduler.cc
scheduler.cc: In function 'cObject* __uniquename_22()':
scheduler.cc:22: error: cannot allocate an object of abstract type 'Scheduler'
scheduler.h:29: note:   because the following virtual functions are pure within 'Scheduler':
scheduler.h:94: note:     virtual void Scheduler::handleMessage(cMessage*)
scheduler.h:75: note:     virtual void Scheduler::handleGrant(int, SuccessFrame*)
scheduler.h:76: note:     virtual void Scheduler::initializeSpecific()
scheduler.h:77: note:     virtual void Scheduler::finishSpecific()
scheduler.h:87: note:     virtual void Scheduler::receiveIpPacket(IpPacket*)
make: *** [out/gcc-debug//scheduler.o] Error 1
============================================================================

Here is the relevant snippet of 'Scheduler' class declaration:
============================================================================
   ...
   virtual void handleGrant(int lambda, SuccessFrame *grant) = 0; // pure virtual function
   virtual void initializeSpecific(void) = 0; // "
   virtual void finishSpecific(void) = 0; // "
   ...
   virtual void receiveIpPacket(IpPacket *msg) = 0; // pure virtual function
   ...
   virtual void handleMessage(cMessage *msg) = 0; // pure virtual function
============================================================================

This 'Scheduler' is a base class from which many other scheduler classes are derived (using "Define_Module" and "Define_Module_Like" macros in 3.xx).

The above codes work just fine with 3.xx (till 3.4b2), but with 4.xx release, I couldn't find detailed information on module inheritance mechanism especially in the manual. All I found is the following line in Sec. 4.2.1:
============================================================================
[For completeness, there is also a Define_Module_Like() macro, but its use is discouraged and might even be removed in future OMNeT++ releases.]
============================================================================

Because I heavily depend on the inheritance mechansim to test and compare various algorithms, more details (in addition to a brief sketch provided in "Migrating ... To 4.0") would be highly appreciated.

Regards,
Joseph
--
Dr. Kyeong Soo (Joseph) Kim
Senior Lecturer
Institute of Advanced Telecommunications, Swansea University
Singleton Park, Swansea SA2 8PP, Wales UK
+44 (0)1792 602024 (Office) / 602449 (Fax)
k.s...@swansea.ac.uk / http://iat-hnrl.swan.ac.uk/~kks/

[Kyeong Soo (Joseph) Kim]

Dear All,

A further investigation through the manual and samples with the release gave me the impression either that the documentation is incomplete or that the implementation hasn't been fixed at the time of releasing 4.x series.

For instance, in Sec. 3.10 ("Interfaces, and submodule/channel ...") has the following sentence (one minor correction highlighted):

NED requires some help from you: you have to name an existing module type (say
RoutingNode) and promise NED that all modules you're going you (-> to) specify in the routingNodeType
parameter will have (at least) the same parameters and gates as the RoutingNode
module.

According to the sentence above, the "same parameters and gates" are required for all modules which implement the said module interface. In this regard I searched the samples relevant and found "samples/routing" which has "IApp.ned" under the "node" subdirectory, providing an example for the new "moduleinterface". "App.ned" and "BurstyApp.ned" modules implementing "IApp.ned" moduleinterface, however, have additional parameters. So the term "moduleinterface" is a little bit confusing and I have still no clear understanding on interface and inheritance because the manual as of now doesn't provide complete examples (just a sketch of it) explaining these.

These advanced NED mechanisms (i.e., interface, inheritance, ...) certainly have close relationships with corresponding implementation as simple modules and related C++ OO concepts. As such, they deserve clearer explanation with complete examples to encourage further migration from 3.xx to 4.xx.

Hope that Andras and the development team will have time to refine the documents very soon. Until then, there is no way for the community to contribute back in this regard.

Regards,
Joseph

2009/1/14 Kyeong Soo (Joseph) Kim <kyeong...@gmail.com>

[Rudolf Hornig]

As far as I can see, you have registered your scheduler class with OMNeT++ however you should not do this.
You cannot instatiate an abstract class and the registration tries to do that. Register ONLY the classes that should be instatiated in your model (i.e. the classes you have derived from the scheduler base class)

Rudolf

2009/1/14 Kyeong Soo (Joseph) Kim <kyeong...@gmail.com>

Dear All,

_______________________________________________
Omnetpp-l mailing list
Omne...@omnetpp.org
http://lists.omnetpp.org/mailman/listinfo/omnetpp-l

[Rudolf Hornig]

2009/1/14 Kyeong Soo (Joseph) Kim <kyeong...@gmail.com>

Dear All,

A further investigation through the manual and samples with the release gave me the impression either that the documentation is incomplete or that the implementation hasn't been fixed at the time of releasing 4.x series.

:) The documentation is incomplete as the release note states :), but the issue you have mentioned has nothing to do with the new NED features or inheritance between modules (see my previous mail). In fact inheritance between NED modules and inheritance between C++ classes has nothing to do with each other. You can use inheriance in C++ but still have totally separate NED modules or the other way around: Have NED modules to inherit from each other and still use a single C++ class implementation for all of them.
 

For instance, in Sec. 3.10 ("Interfaces, and submodule/channel ...") has the following sentence (one minor correction highlighted):

NED requires some help from you: you have to name an existing module type (say
RoutingNode) and promise NED that all modules you're going you (-> to) specify in the routingNodeType
parameter will have (at least) the same parameters and gates as the RoutingNode
module.

According to the sentence above, the "same parameters and gates" are required for all modules which implement the said module interface. In this regard I searched the samples relevant and found "samples/routing" which has "IApp.ned" under the "node" subdirectory, providing an example for the new "moduleinterface". "App.ned" and "BurstyApp.ned" modules implementing "IApp.ned" moduleinterface, however, have additional parameters. So the term "moduleinterface" is a little bit confusing and I have still no clear understanding on interface and inheritance because the manual as of now doesn't provide complete examples (just a sketch of it) explaining these.

well acually the sentece is: routingNodeType parameter will have (at least) the same parameters and gates as the RoutingNode
 
This means. You MUST have those gates and parameters, BUT you can have additional ones. This is exctly like interfaces work in java or abstract classes in C++. You must have the methods from the interface, BUT of course you can have additional ones.

BUT this does not change the fact, that the documentation in RC1 is still lacking...

These advanced NED mechanisms (i.e., interface, inheritance, ...) certainly have close relationships with corresponding implementation as simple modules and related C++ OO concepts. As such, they deserve clearer explanation with complete examples to encourage further migration from 3.xx to 4.xx.

Hope that Andras and the development team will have time to refine the documents very soon. Until then, there is no way for the community to contribute back in this regard.

We are in documentation write mode since beginning of december :)  But, the bigger part of the manual must be revised or totally rewritten. We are working on it, and this is the last step before going final.
 

Rudolf

[Kyeong Soo (Joseph) Kim]

Dear Rudolf,

Great thanks for your detailed comments and taking the time for them.

Thanks to your clear explanations, now I have a much clearer picture on the said issues.
As you said, it seems that my problems reported in the initial post result from my misunderstanding & misuse of the new NED mechanisms.

By the way, your comments combined with the use of Eclipse and Mingw environment on Windows platform in the 4.x release make me think that it's (or will soon be) time to start a new initiative of migrating OMNeT++ itself into Java (or any VM-based) platform.

Although the platform differences (mainly between Windows and Linux) have been successfully hidden from end users so far due to the hard work of Andras for providing multiple sets of tools (e.g., opp_* vs. opp_n*), we have observed issues arising from the use of not only different OSes/compilers but also different architectures (i.e., 32bit vs. 64 bit) with the same OS/compilers. Until I recently reviewed the Berkley Ptolemy project (now completely based on Java), I hadn't bought the idea of using Java for any serious simulation work. Of course, I was aware of J-Sim, Swan, and the like, but it was always unclear to me the real benefit of using VMs. Now, however, I think we have many reasons to go for a VM-based approach.

Anyhow, once the work on 4.x release is completed, I will raise the above issue again.

Regards,
Joseph

2009/1/15 Rudolf Hornig <rudolf...@gmail.com>