[Ns-bugs] [Bug 1170] Formulate best practices for dealing with unused debug variables

[code@nsnam.ece.gatech.edu]

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1170

--- Comment #24 from Mathieu Lacage <mathieu.lacage at gmail.com> 2012-02-05 14:09:24 EST ---
(In reply to comment #19)
> (In reply to comment #17)
> > > > Ipv4Address ToIpv4 (const Address &addr)
> > > > {
> > > > InetSocketAddress iaddr = InetSocketAddress::ConvertFrom (addr);
> > > > return iaddr.GetIpv4 ();
> > > > }
> > > > 
> > > > Same for ToPort
> > > > 
> > > > and finally:
> > > > NS_LOG_DEBUG ("Received one packet!  Socket: " << ToIpv4(addr) << " port: " <<
> > > > ToPort (addr));
> > > > 
> 
> > This is indeed a good point and it is true in C (although, really, from a
> > simplicity point of view, I would be willing to live with non-static functions
> > for that in C), but this is C++ so, there are a couple of classic tricks around
> > this issue:
> > 
> > 1) make the static function a member static method: no warnings anymore, even
> > with recent gccs.
> 
> Considering the above ToIpv4() example, which class should we make the static
> method member of?
> I see two options:
> 1.1) Make ToIpv4() method a member of Ipv4Address class
> 1.2) Make ToIpv4() method a member of the class that uses it (like PacketSink
> in this example)
> 
> Option 1.1) requires someone to modify the core class whenever he needs a new
> NS_LOG_*()/NS_ASSER() statement.
> Also this will be impossible when the app store idea gets implemented.
> Addition of helper functions to the core class will also introduce additional
> dependencies and will end up with everything depending on everything.
> 
> Both options make the whole ns-3 API bloated with a bunch of (duplicated)
> helper functions, occupying more space in dynamic symbol table, which adds more
> work to both the linker and the dynamic loader and even adds slight runtime
> overhead.
> Primarily, these functions are just simple one-time helper functions but we
> will have to apply general API stabilizing rules to them (like restrict
> changing behavior of a function without renaming it or so).
> Although, this is not going to be completely killing us because we do not
> provide API backward-compatibility across major releases.
> Besides that, the bloated API can confuse new users of ns-3.

1) I would never expect anyone to try to share the code of this two-line
function. i.e., copy/paste has its uses.

2) If this function was deemed really useful, then, yes, we should add it as a
member method of the relevant class or as some utils function. We have an
ipv4-utils.h somewhere, I believe ?

> 
> > 2) move the static function to an anonymous namespace. again, no warnings with
> > any compiler I am aware of.
> Intel C++ Compiler (e.g., 11.1) produces the following warning:
> 'remark #177: function "<unnamed>::qqq" was declared but never referenced'
> 
> icpc -x c++ - -Wall -o /dev/null <<EOFF
>  namespace {
>  int qqq ()
>    {
>      return 0;
>    }
>  }
>  int main ()
>    {
>      return 0;
>    }
> EOFF
> 
> So there is no guarantee, that, GCC will not warn in the same case in the near
> future.


Sure. Use a non-static global function. As I said before, this is a common
trick in C.

-- 
Configure bugmail: https://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.