[Ns-developers] [ns3] trace path documentation

[Gustavo Carneiro]

On 10/04/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
> hi,
>
> I have pushed in http://code.nsnam.org/mathieu/ns-3-doc a bunch of
> patches which add trace source documentation to the generated doxygen.
> This code also adds documentation about the set of 'config paths' which
> can be used with Config::Connect and Config::Set for each type of object
> so, to figure out the trace path, all you have to do now is read the
> doxygen and copy/paste.
>
> There are a couple of issues to consider:
>   - I had to make one API change to the attribute system: if you want to
> set or get a pointer of the form Ptr<T> as an attribute, you must now
> wrap that pointer in an instance of the Pointer class.
> Ptr<Queue> queue;
> queue = csma->GetAttribute ("TxQueue");
> is now:
> Ptr<Queue> queue;
> Pointer q = csma->GetAttribute ("TxQueue");
> queue = q.Get ();


Ugh!..

Can you at least rename it to PointerAttribute or something.  Having both
Pointer and Ptr is rather confusing.

Moreover, generally I think all classes that only wrap attribute values and
which have a Get() method should be renamed to FooAttribute (replace
Attribute with a suffix of choice).  That would make it clear when a class
is only a wrapper to an actual value.


  The upside here is that this did simplify a _lot_ the implementation
> of the Attribute code in src/core/attribute.cc
>
>   - the utils/print-introspected-doxygen.cc file contains a hardcoded
> list of possible object aggregations: it records that a MobilityModel
> will most likely be aggregated to a Node. This information is impossible
> to derive from the class information so, I had to get it from somewhere.
> If you create a new type of object which will be aggregated and if you
> want that its doxygen doc is accurate, you will have to update that file
> to include your aggregation option
>
>   - while working on this code, it occured to me that there are some
> ways to somewhat "simplify" the config paths to make them more
> consistent. For example, the following would be (I think) much more
> consistent:
> /NodeList/*/$MobilityModel
> to:
> /ns3::NodeListPriv::NodeList/*/ns3::MobilityModel
>
> Basically, we could request the user to specify explicitely each
> attribute with a typeid.
>
> Another thing which would probably make the parsing simpler:
> /NodeList/*
> to:
> /NodeList[*]
>
>
>
> regards,
>
> Mathieu
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert