35.2 Scaffolding

Let’s say that you are ready to start implementing; you have a fairly clear picture of what you want to build, and you may have solicited some initial review or suggestions from the list. One way to approach the next step (implementation) is to create scaffolding and fill in the details as the design matures.

This section walks through many of the steps you should consider to define scaffolding, or a non-functional skeleton of what your model will eventually implement. It is usually good practice to not wait to get these details integrated at the end, but instead to plumb a skeleton of your model into the system early and then add functions later once the API and integration seems about right.

Note that you will want to modify a few things in the below presentation for your model since if you follow the error model verbatim, the code you produce will collide with the existing error model. The below is just an outline of how ErrorModel was built that you can adapt to other models.

35.2.1 Review the ns-3 coding style document

At this point, you may want to pause and read the ns-3 coding style document, especially if you are considering to contribute your code back to the project. The coding style document is linked off the main project page: ns-3 coding style.

35.2.2 Decide where in the source tree the model will reside in

All of the ns-3 model source code is in the directory src/. You will need to choose which subdirectory it resides in. If it is new model code of some sort, it makes sense to put it into the src/ directory somewhere, particularly for ease of integrating with the build system.

In the case of the error model, it is very related to the packet class, so it makes sense to implement this in the src/common/ directory where ns-3 packets are implemented.

35.2.3 waf and wscript

ns-3 uses the Waf build system. You will want to integrate your new ns-3 uses the Waf build system. You will want to integrate your new source files into this system. This requires that you add your files to the wscript file found in each directory.

Let’s start with empty files error-model.h and error-model.cc, and add this to src/common/wscript. It is really just a matter of adding the .cc file to the rest of the source files, and the .h file to the list of the header files.

Now, pop up to the top level directory and type "./waf –check". You shouldn’t have broken anything by this operation.

35.2.4 include guards

Next, let’s add some include guards in our header file.

#ifndef ERROR_MODEL_H
#define ERROR_MODEL_H
...
#endif

35.2.5 namespace ns3

ns-3 uses the ns3 namespace to isolate its symbols from other namespaces. Typically, a user will next put an ns-3 namespace block in both the cc and h file.

namespace ns3 {
...
}

At this point, we have some skeletal files in which we can start defining our new classes. The header file looks like this:

#ifndef ERROR_MODEL_H
#define ERROR_MODEL_H

namespace ns3 {

} // namespace ns3
#endif

while the error-model.cc file simply looks like this:

#include "error-model.h"

namespace ns3 {

} // namespace ns3

These files should compile since they don’t really have any contents. We’re now ready to start adding classes.

This document was generated on August 20, 2010 using texi2html 1.82.